Internet Engineering Task Force (IETF) H. Schulzrinne
Request for Comments: 7826 Columbia University
Obsoletes: 2326 A. Rao
Category: Standards Track Cisco
ISSN: 2070-1721 R. Lanphier
Internet Engineering Task Force (IETF) H. Schulzrinne
Request for Comments: 7826 Columbia University
Obsoletes: 2326 A. Rao
Category: Standards Track Cisco
ISSN: 2070-1721 R. Lanphier
M. Westerlund Ericsson M. Stiemerling, Ed. University of Applied Sciences Darmstadt December 2016
2016年12月，达姆施塔特应用科学大学
Real-Time Streaming Protocol Version 2.0
实时流协议2.0版
Abstract
摘要
This memorandum defines the Real-Time Streaming Protocol (RTSP) version 2.0, which obsoletes RTSP version 1.0 defined in RFC 2326.
本备忘录定义了实时流协议（RTSP）2.0版，该版本淘汰了RFC 2326中定义的RTSP 1.0版。
RTSP is an application-layer protocol for the setup and control of the delivery of data with real-time properties. RTSP provides an extensible framework to enable controlled, on-demand delivery of real-time data, such as audio and video. Sources of data can include both live data feeds and stored clips. This protocol is intended to control multiple data delivery sessions; provide a means for choosing delivery channels such as UDP, multicast UDP, and TCP; and provide a means for choosing delivery mechanisms based upon RTP (RFC 3550).
RTSP是一种应用层协议，用于设置和控制具有实时属性的数据传输。RTSP提供了一个可扩展的框架，以支持实时数据（如音频和视频）的受控按需交付。数据源可以包括实时数据源和存储的剪辑。该协议旨在控制多个数据交付会话；提供一种选择传送通道的方法，如UDP、多播UDP和TCP；并提供了一种基于RTP（RFC3550）选择传送机制的方法。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7826.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7826.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ...................................................10
2. Protocol Overview ..............................................11
2.1. Presentation Description ..................................12
2.2. Session Establishment .....................................12
2.3. Media Delivery Control ....................................14
2.4. Session Parameter Manipulations ...........................15
2.5. Media Delivery ............................................16
2.5.1. Media Delivery Manipulations .......................16
2.6. Session Maintenance and Termination .......................19
2.7. Extending RTSP ............................................20
3. Document Conventions ...........................................21
3.1. Notational Conventions ....................................21
3.2. Terminology ...............................................21
4. Protocol Parameters ............................................25
4.1. RTSP Version ..............................................25
4.2. RTSP IRI and URI ..........................................25
4.3. Session Identifiers .......................................28
1. Introduction ...................................................10
2. Protocol Overview ..............................................11
2.1. Presentation Description ..................................12
2.2. Session Establishment .....................................12
2.3. Media Delivery Control ....................................14
2.4. Session Parameter Manipulations ...........................15
2.5. Media Delivery ............................................16
2.5.1. Media Delivery Manipulations .......................16
2.6. Session Maintenance and Termination .......................19
2.7. Extending RTSP ............................................20
3. Document Conventions ...........................................21
3.1. Notational Conventions ....................................21
3.2. Terminology ...............................................21
4. Protocol Parameters ............................................25
4.1. RTSP Version ..............................................25
4.2. RTSP IRI and URI ..........................................25
4.3. Session Identifiers .......................................28
4.4. Media-Time Formats ........................................28
4.4.1. SMPTE-Relative Timestamps ..........................28
4.4.2. Normal Play Time ...................................29
4.4.3. Absolute Time ......................................30
4.5. Feature Tags ..............................................31
4.6. Message Body Tags .........................................32
4.7. Media Properties ..........................................32
4.7.1. Random Access and Seeking ..........................33
4.7.2. Retention ..........................................34
4.7.3. Content Modifications ..............................34
4.7.4. Supported Scale Factors ............................34
4.7.5. Mapping to the Attributes ..........................35
5. RTSP Message ...................................................35
5.1. Message Types .............................................36
5.2. Message Headers ...........................................36
5.3. Message Body ..............................................37
5.4. Message Length ............................................37
6. General-Header Fields ..........................................37
7. Request ........................................................39
7.1. Request Line ..............................................40
7.2. Request-Header Fields .....................................42
8. Response .......................................................43
8.1. Status-Line ...............................................43
8.1.1. Status Code and Reason Phrase ......................43
8.2. Response Headers ..........................................47
9. Message Body ...................................................47
9.1. Message Body Header Fields ................................48
9.2. Message Body ..............................................49
9.3. Message Body Format Negotiation ...........................49
10. Connections ...................................................50
10.1. Reliability and Acknowledgements .........................50
10.2. Using Connections ........................................51
10.3. Closing Connections ......................................54
10.4. Timing Out Connections and RTSP Messages .................56
10.5. Showing Liveness .........................................57
10.6. Use of IPv6 ..............................................58
10.7. Overload Control .........................................58
11. Capability Handling ...........................................60
11.1. Feature Tag: play.basic ..................................62
12. Pipelining Support ............................................62
13. Method Definitions ............................................63
13.1. OPTIONS ..................................................65
13.2. DESCRIBE .................................................66
13.3. SETUP ....................................................68
13.3.1. Changing Transport Parameters .....................71
13.4. PLAY .....................................................72
13.4.1. General Usage .....................................72
13.4.2. Aggregated Sessions ...............................77
4.4. Media-Time Formats ........................................28
4.4.1. SMPTE-Relative Timestamps ..........................28
4.4.2. Normal Play Time ...................................29
4.4.3. Absolute Time ......................................30
4.5. Feature Tags ..............................................31
4.6. Message Body Tags .........................................32
4.7. Media Properties ..........................................32
4.7.1. Random Access and Seeking ..........................33
4.7.2. Retention ..........................................34
4.7.3. Content Modifications ..............................34
4.7.4. Supported Scale Factors ............................34
4.7.5. Mapping to the Attributes ..........................35
5. RTSP Message ...................................................35
5.1. Message Types .............................................36
5.2. Message Headers ...........................................36
5.3. Message Body ..............................................37
5.4. Message Length ............................................37
6. General-Header Fields ..........................................37
7. Request ........................................................39
7.1. Request Line ..............................................40
7.2. Request-Header Fields .....................................42
8. Response .......................................................43
8.1. Status-Line ...............................................43
8.1.1. Status Code and Reason Phrase ......................43
8.2. Response Headers ..........................................47
9. Message Body ...................................................47
9.1. Message Body Header Fields ................................48
9.2. Message Body ..............................................49
9.3. Message Body Format Negotiation ...........................49
10. Connections ...................................................50
10.1. Reliability and Acknowledgements .........................50
10.2. Using Connections ........................................51
10.3. Closing Connections ......................................54
10.4. Timing Out Connections and RTSP Messages .................56
10.5. Showing Liveness .........................................57
10.6. Use of IPv6 ..............................................58
10.7. Overload Control .........................................58
11. Capability Handling ...........................................60
11.1. Feature Tag: play.basic ..................................62
12. Pipelining Support ............................................62
13. Method Definitions ............................................63
13.1. OPTIONS ..................................................65
13.2. DESCRIBE .................................................66
13.3. SETUP ....................................................68
13.3.1. Changing Transport Parameters .....................71
13.4. PLAY .....................................................72
13.4.1. General Usage .....................................72
13.4.2. Aggregated Sessions ...............................77
13.4.3. Updating Current PLAY Requests ....................78
13.4.4. Playing On-Demand Media ...........................81
13.4.5. Playing Dynamic On-Demand Media ...................81
13.4.6. Playing Live Media ................................81
13.4.7. Playing Live with Recording .......................82
13.4.8. Playing Live with Time-Shift ......................83
13.5. PLAY_NOTIFY ..............................................83
13.5.1. End-of-Stream .....................................84
13.5.2. Media-Properties-Update ...........................86
13.5.3. Scale-Change ......................................87
13.6. PAUSE ....................................................89
13.7. TEARDOWN .................................................92
13.7.1. Client to Server ..................................92
13.7.2. Server to Client ..................................93
13.8. GET_PARAMETER ............................................94
13.9. SET_PARAMETER ............................................96
13.10. REDIRECT ................................................98
14. Embedded (Interleaved) Binary Data ...........................101
15. Proxies ......................................................103
15.1. Proxies and Protocol Extensions .........................104
15.2. Multiplexing and Demultiplexing of Messages .............105
16. Caching ......................................................106
16.1. Validation Model ........................................107
16.1.1. Last-Modified Dates ..............................108
16.1.2. Message Body Tag Cache Validators ................108
16.1.3. Weak and Strong Validators .......................108
16.1.4. Rules for When to Use Message Body Tags
and Last-Modified Dates ..........................110
16.1.5. Non-validating Conditionals ......................112
16.2. Invalidation after Updates or Deletions .................112
17. Status Code Definitions ......................................113
17.1. Informational 1xx .......................................113
17.1.1. 100 Continue .....................................113
17.2. Success 2xx .............................................113
17.2.1. 200 OK ...........................................113
17.3. Redirection 3xx .........................................113
17.3.1. 300 ..............................................114
17.3.2. 301 Moved Permanently ............................114
17.3.3. 302 Found ........................................114
17.3.4. 303 See Other ....................................115
17.3.5. 304 Not Modified .................................115
17.3.6. 305 Use Proxy ....................................115
17.4. Client Error 4xx ........................................116
17.4.1. 400 Bad Request ..................................116
17.4.2. 401 Unauthorized .................................116
17.4.3. 402 Payment Required .............................116
17.4.4. 403 Forbidden ....................................116
17.4.5. 404 Not Found ....................................116
13.4.3. Updating Current PLAY Requests ....................78
13.4.4. Playing On-Demand Media ...........................81
13.4.5. Playing Dynamic On-Demand Media ...................81
13.4.6. Playing Live Media ................................81
13.4.7. Playing Live with Recording .......................82
13.4.8. Playing Live with Time-Shift ......................83
13.5. PLAY_NOTIFY ..............................................83
13.5.1. End-of-Stream .....................................84
13.5.2. Media-Properties-Update ...........................86
13.5.3. Scale-Change ......................................87
13.6. PAUSE ....................................................89
13.7. TEARDOWN .................................................92
13.7.1. Client to Server ..................................92
13.7.2. Server to Client ..................................93
13.8. GET_PARAMETER ............................................94
13.9. SET_PARAMETER ............................................96
13.10. REDIRECT ................................................98
14. Embedded (Interleaved) Binary Data ...........................101
15. Proxies ......................................................103
15.1. Proxies and Protocol Extensions .........................104
15.2. Multiplexing and Demultiplexing of Messages .............105
16. Caching ......................................................106
16.1. Validation Model ........................................107
16.1.1. Last-Modified Dates ..............................108
16.1.2. Message Body Tag Cache Validators ................108
16.1.3. Weak and Strong Validators .......................108
16.1.4. Rules for When to Use Message Body Tags
and Last-Modified Dates ..........................110
16.1.5. Non-validating Conditionals ......................112
16.2. Invalidation after Updates or Deletions .................112
17. Status Code Definitions ......................................113
17.1. Informational 1xx .......................................113
17.1.1. 100 Continue .....................................113
17.2. Success 2xx .............................................113
17.2.1. 200 OK ...........................................113
17.3. Redirection 3xx .........................................113
17.3.1. 300 ..............................................114
17.3.2. 301 Moved Permanently ............................114
17.3.3. 302 Found ........................................114
17.3.4. 303 See Other ....................................115
17.3.5. 304 Not Modified .................................115
17.3.6. 305 Use Proxy ....................................115
17.4. Client Error 4xx ........................................116
17.4.1. 400 Bad Request ..................................116
17.4.2. 401 Unauthorized .................................116
17.4.3. 402 Payment Required .............................116
17.4.4. 403 Forbidden ....................................116
17.4.5. 404 Not Found ....................................116
17.4.6. 405 Method Not Allowed ...........................117
17.4.7. 406 Not Acceptable ...............................117
17.4.8. 407 Proxy Authentication Required ................117
17.4.9. 408 Request Timeout ..............................117
17.4.10. 410 Gone ........................................118
17.4.11. 412 Precondition Failed .........................118
17.4.12. 413 Request Message Body Too Large ..............118
17.4.13. 414 Request-URI Too Long ........................118
17.4.14. 415 Unsupported Media Type ......................119
17.4.15. 451 Parameter Not Understood ....................119
17.4.16. 452 Illegal Conference Identifier ...............119
17.4.17. 453 Not Enough Bandwidth ........................119
17.4.18. 454 Session Not Found ...........................119
17.4.19. 455 Method Not Valid in This State ..............119
17.4.20. 456 Header Field Not Valid for Resource .........119
17.4.21. 457 Invalid Range ...............................120
17.4.22. 458 Parameter Is Read-Only ......................120
17.4.23. 459 Aggregate Operation Not Allowed .............120
17.4.24. 460 Only Aggregate Operation Allowed ............120
17.4.25. 461 Unsupported Transport .......................120
17.4.26. 462 Destination Unreachable .....................120
17.4.27. 463 Destination Prohibited ......................120
17.4.28. 464 Data Transport Not Ready Yet ................121
17.4.29. 465 Notification Reason Unknown .................121
17.4.30. 466 Key Management Error ........................121
17.4.31. 470 Connection Authorization Required ...........121
17.4.32. 471 Connection Credentials Not Accepted .........121
17.4.33. 472 Failure to Establish Secure Connection ......121
17.5. Server Error 5xx ........................................122
17.5.1. 500 Internal Server Error ........................122
17.5.2. 501 Not Implemented ..............................122
17.5.3. 502 Bad Gateway ..................................122
17.5.4. 503 Service Unavailable ..........................122
17.5.5. 504 Gateway Timeout ..............................123
17.5.6. 505 RTSP Version Not Supported ...................123
17.5.7. 551 Option Not Supported .........................123
17.5.8. 553 Proxy Unavailable ............................123
18. Header Field Definitions .....................................124
18.1. Accept ..................................................134
18.2. Accept-Credentials ......................................135
18.3. Accept-Encoding .........................................135
18.4. Accept-Language .........................................136
18.5. Accept-Ranges ...........................................137
18.6. Allow ...................................................138
18.7. Authentication-Info .....................................138
18.8. Authorization ...........................................138
18.9. Bandwidth ...............................................139
18.10. Blocksize ..............................................140
17.4.6. 405 Method Not Allowed ...........................117
17.4.7. 406 Not Acceptable ...............................117
17.4.8. 407 Proxy Authentication Required ................117
17.4.9. 408 Request Timeout ..............................117
17.4.10. 410 Gone ........................................118
17.4.11. 412 Precondition Failed .........................118
17.4.12. 413 Request Message Body Too Large ..............118
17.4.13. 414 Request-URI Too Long ........................118
17.4.14. 415 Unsupported Media Type ......................119
17.4.15. 451 Parameter Not Understood ....................119
17.4.16. 452 Illegal Conference Identifier ...............119
17.4.17. 453 Not Enough Bandwidth ........................119
17.4.18. 454 Session Not Found ...........................119
17.4.19. 455 Method Not Valid in This State ..............119
17.4.20. 456 Header Field Not Valid for Resource .........119
17.4.21. 457 Invalid Range ...............................120
17.4.22. 458 Parameter Is Read-Only ......................120
17.4.23. 459 Aggregate Operation Not Allowed .............120
17.4.24. 460 Only Aggregate Operation Allowed ............120
17.4.25. 461 Unsupported Transport .......................120
17.4.26. 462 Destination Unreachable .....................120
17.4.27. 463 Destination Prohibited ......................120
17.4.28. 464 Data Transport Not Ready Yet ................121
17.4.29. 465 Notification Reason Unknown .................121
17.4.30. 466 Key Management Error ........................121
17.4.31. 470 Connection Authorization Required ...........121
17.4.32. 471 Connection Credentials Not Accepted .........121
17.4.33. 472 Failure to Establish Secure Connection ......121
17.5. Server Error 5xx ........................................122
17.5.1. 500 Internal Server Error ........................122
17.5.2. 501 Not Implemented ..............................122
17.5.3. 502 Bad Gateway ..................................122
17.5.4. 503 Service Unavailable ..........................122
17.5.5. 504 Gateway Timeout ..............................123
17.5.6. 505 RTSP Version Not Supported ...................123
17.5.7. 551 Option Not Supported .........................123
17.5.8. 553 Proxy Unavailable ............................123
18. Header Field Definitions .....................................124
18.1. Accept ..................................................134
18.2. Accept-Credentials ......................................135
18.3. Accept-Encoding .........................................135
18.4. Accept-Language .........................................136
18.5. Accept-Ranges ...........................................137
18.6. Allow ...................................................138
18.7. Authentication-Info .....................................138
18.8. Authorization ...........................................138
18.9. Bandwidth ...............................................139
18.10. Blocksize ..............................................140
18.11. Cache-Control ..........................................140
18.12. Connection .............................................143
18.13. Connection-Credentials .................................143
18.14. Content-Base ...........................................144
18.15. Content-Encoding .......................................145
18.16. Content-Language .......................................145
18.17. Content-Length .........................................146
18.18. Content-Location .......................................146
18.19. Content-Type ...........................................148
18.20. CSeq ...................................................148
18.21. Date ...................................................150
18.22. Expires ................................................151
18.23. From ...................................................151
18.24. If-Match ...............................................152
18.25. If-Modified-Since ......................................152
18.26. If-None-Match ..........................................153
18.27. Last-Modified ..........................................154
18.28. Location ...............................................154
18.29. Media-Properties .......................................154
18.30. Media-Range ............................................156
18.31. MTag ...................................................157
18.32. Notify-Reason ..........................................158
18.33. Pipelined-Requests .....................................158
18.34. Proxy-Authenticate .....................................159
18.35. Proxy-Authentication-Info ..............................159
18.36. Proxy-Authorization ....................................159
18.37. Proxy-Require ..........................................160
18.38. Proxy-Supported ........................................160
18.39. Public .................................................161
18.40. Range ..................................................162
18.41. Referrer ...............................................164
18.42. Request-Status .........................................164
18.43. Require ................................................165
18.44. Retry-After ............................................166
18.45. RTP-Info ...............................................167
18.46. Scale ..................................................169
18.47. Seek-Style .............................................170
18.48. Server .................................................171
18.49. Session ................................................172
18.50. Speed ..................................................173
18.51. Supported ..............................................174
18.52. Terminate-Reason .......................................175
18.53. Timestamp ..............................................175
18.54. Transport ..............................................176
18.55. Unsupported ............................................183
18.56. User-Agent .............................................184
18.57. Via ....................................................184
18.58. WWW-Authenticate .......................................185
18.11. Cache-Control ..........................................140
18.12. Connection .............................................143
18.13. Connection-Credentials .................................143
18.14. Content-Base ...........................................144
18.15. Content-Encoding .......................................145
18.16. Content-Language .......................................145
18.17. Content-Length .........................................146
18.18. Content-Location .......................................146
18.19. Content-Type ...........................................148
18.20. CSeq ...................................................148
18.21. Date ...................................................150
18.22. Expires ................................................151
18.23. From ...................................................151
18.24. If-Match ...............................................152
18.25. If-Modified-Since ......................................152
18.26. If-None-Match ..........................................153
18.27. Last-Modified ..........................................154
18.28. Location ...............................................154
18.29. Media-Properties .......................................154
18.30. Media-Range ............................................156
18.31. MTag ...................................................157
18.32. Notify-Reason ..........................................158
18.33. Pipelined-Requests .....................................158
18.34. Proxy-Authenticate .....................................159
18.35. Proxy-Authentication-Info ..............................159
18.36. Proxy-Authorization ....................................159
18.37. Proxy-Require ..........................................160
18.38. Proxy-Supported ........................................160
18.39. Public .................................................161
18.40. Range ..................................................162
18.41. Referrer ...............................................164
18.42. Request-Status .........................................164
18.43. Require ................................................165
18.44. Retry-After ............................................166
18.45. RTP-Info ...............................................167
18.46. Scale ..................................................169
18.47. Seek-Style .............................................170
18.48. Server .................................................171
18.49. Session ................................................172
18.50. Speed ..................................................173
18.51. Supported ..............................................174
18.52. Terminate-Reason .......................................175
18.53. Timestamp ..............................................175
18.54. Transport ..............................................176
18.55. Unsupported ............................................183
18.56. User-Agent .............................................184
18.57. Via ....................................................184
18.58. WWW-Authenticate .......................................185
19. Security Framework ...........................................185
19.1. RTSP and HTTP Authentication ............................185
19.1.1. Digest Authentication ............................186
19.2. RTSP over TLS ...........................................187
19.3. Security and Proxies ....................................188
19.3.1. Accept-Credentials ...............................189
19.3.2. User-Approved TLS Procedure ......................190
20. Syntax .......................................................192
20.1. Base Syntax .............................................193
20.2. RTSP Protocol Definition ................................195
20.2.1. Generic Protocol Elements ........................195
20.2.2. Message Syntax ...................................198
20.2.3. Header Syntax ....................................201
20.3. SDP Extension Syntax ....................................209
21. Security Considerations ......................................209
21.1. Signaling Protocol Threats ..............................210
21.2. Media Stream Delivery Threats ...........................213
21.2.1. Remote DoS Attack ................................215
21.2.2. RTP Security Analysis ............................216
22. IANA Considerations ..........................................217
22.1. Feature Tags ............................................218
22.1.1. Description ......................................218
22.1.2. Registering New Feature Tags with IANA ...........218
22.1.3. Registered Entries ...............................219
22.2. RTSP Methods ............................................219
22.2.1. Description ......................................219
22.2.2. Registering New Methods with IANA ................219
22.2.3. Registered Entries ...............................220
22.3. RTSP Status Codes .......................................220
22.3.1. Description ......................................220
22.3.2. Registering New Status Codes with IANA ...........220
22.3.3. Registered Entries ...............................221
22.4. RTSP Headers ............................................221
22.4.1. Description ......................................221
22.4.2. Registering New Headers with IANA ................221
22.4.3. Registered Entries ...............................222
22.5. Accept-Credentials ......................................223
22.5.1. Accept-Credentials Policies ......................223
22.5.2. Accept-Credentials Hash Algorithms ...............224
22.6. Cache-Control Cache Directive Extensions ................224
22.7. Media Properties ........................................225
22.7.1. Description ......................................225
22.7.2. Registration Rules ...............................226
22.7.3. Registered Values ................................226
22.8. Notify-Reason Values ....................................226
22.8.1. Description ......................................226
22.8.2. Registration Rules ...............................226
22.8.3. Registered Values ................................227
19. Security Framework ...........................................185
19.1. RTSP and HTTP Authentication ............................185
19.1.1. Digest Authentication ............................186
19.2. RTSP over TLS ...........................................187
19.3. Security and Proxies ....................................188
19.3.1. Accept-Credentials ...............................189
19.3.2. User-Approved TLS Procedure ......................190
20. Syntax .......................................................192
20.1. Base Syntax .............................................193
20.2. RTSP Protocol Definition ................................195
20.2.1. Generic Protocol Elements ........................195
20.2.2. Message Syntax ...................................198
20.2.3. Header Syntax ....................................201
20.3. SDP Extension Syntax ....................................209
21. Security Considerations ......................................209
21.1. Signaling Protocol Threats ..............................210
21.2. Media Stream Delivery Threats ...........................213
21.2.1. Remote DoS Attack ................................215
21.2.2. RTP Security Analysis ............................216
22. IANA Considerations ..........................................217
22.1. Feature Tags ............................................218
22.1.1. Description ......................................218
22.1.2. Registering New Feature Tags with IANA ...........218
22.1.3. Registered Entries ...............................219
22.2. RTSP Methods ............................................219
22.2.1. Description ......................................219
22.2.2. Registering New Methods with IANA ................219
22.2.3. Registered Entries ...............................220
22.3. RTSP Status Codes .......................................220
22.3.1. Description ......................................220
22.3.2. Registering New Status Codes with IANA ...........220
22.3.3. Registered Entries ...............................221
22.4. RTSP Headers ............................................221
22.4.1. Description ......................................221
22.4.2. Registering New Headers with IANA ................221
22.4.3. Registered Entries ...............................222
22.5. Accept-Credentials ......................................223
22.5.1. Accept-Credentials Policies ......................223
22.5.2. Accept-Credentials Hash Algorithms ...............224
22.6. Cache-Control Cache Directive Extensions ................224
22.7. Media Properties ........................................225
22.7.1. Description ......................................225
22.7.2. Registration Rules ...............................226
22.7.3. Registered Values ................................226
22.8. Notify-Reason Values ....................................226
22.8.1. Description ......................................226
22.8.2. Registration Rules ...............................226
22.8.3. Registered Values ................................227
22.9. Range Header Formats ....................................227
22.9.1. Description ......................................227
22.9.2. Registration Rules ...............................227
22.9.3. Registered Values ................................228
22.10. Terminate-Reason Header ................................228
22.10.1. Redirect Reasons ................................228
22.10.2. Terminate-Reason Header Parameters ..............229
22.11. RTP-Info Header Parameters .............................229
22.11.1. Description .....................................229
22.11.2. Registration Rules ..............................229
22.11.3. Registered Values ...............................230
22.12. Seek-Style Policies ....................................230
22.12.1. Description .....................................230
22.12.2. Registration Rules ..............................230
22.12.3. Registered Values ...............................230
22.13. Transport Header Registries ............................231
22.13.1. Transport Protocol Identifier ...................231
22.13.2. Transport Modes .................................233
22.13.3. Transport Parameters ............................233
22.14. URI Schemes ............................................234
22.14.1. The "rtsp" URI Scheme ...........................234
22.14.2. The "rtsps" URI Scheme ..........................235
22.14.3. The "rtspu" URI Scheme ..........................237
22.15. SDP Attributes .........................................238
22.16. Media Type Registration for text/parameters ............238
23. References ...................................................240
23.1. Normative References ....................................240
23.2. Informative References ..................................245
Appendix A. Examples .............................................248
A.1. Media on Demand (Unicast) ................................248
A.2. Media on Demand Using Pipelining .........................251
A.3. Secured Media Session for On-Demand Content ..............254
A.4. Media on Demand (Unicast) ................................257
A.5. Single-Stream Container Files ............................260
A.6. Live Media Presentation Using Multicast ..................263
A.7. Capability Negotiation ...................................264
Appendix B. RTSP Protocol State Machine ..........................265
B.1. States ...................................................266
B.2. State Variables ..........................................266
B.3. Abbreviations ............................................266
B.4. State Tables .............................................267
Appendix C. Media-Transport Alternatives .........................272
C.1. RTP ......................................................272
C.1.1. AVP ..................................................272
C.1.2. AVP/UDP ..............................................273
C.1.3. AVPF/UDP .............................................274
C.1.4. SAVP/UDP .............................................275
C.1.5. SAVPF/UDP ............................................277
22.9. Range Header Formats ....................................227
22.9.1. Description ......................................227
22.9.2. Registration Rules ...............................227
22.9.3. Registered Values ................................228
22.10. Terminate-Reason Header ................................228
22.10.1. Redirect Reasons ................................228
22.10.2. Terminate-Reason Header Parameters ..............229
22.11. RTP-Info Header Parameters .............................229
22.11.1. Description .....................................229
22.11.2. Registration Rules ..............................229
22.11.3. Registered Values ...............................230
22.12. Seek-Style Policies ....................................230
22.12.1. Description .....................................230
22.12.2. Registration Rules ..............................230
22.12.3. Registered Values ...............................230
22.13. Transport Header Registries ............................231
22.13.1. Transport Protocol Identifier ...................231
22.13.2. Transport Modes .................................233
22.13.3. Transport Parameters ............................233
22.14. URI Schemes ............................................234
22.14.1. The "rtsp" URI Scheme ...........................234
22.14.2. The "rtsps" URI Scheme ..........................235
22.14.3. The "rtspu" URI Scheme ..........................237
22.15. SDP Attributes .........................................238
22.16. Media Type Registration for text/parameters ............238
23. References ...................................................240
23.1. Normative References ....................................240
23.2. Informative References ..................................245
Appendix A. Examples .............................................248
A.1. Media on Demand (Unicast) ................................248
A.2. Media on Demand Using Pipelining .........................251
A.3. Secured Media Session for On-Demand Content ..............254
A.4. Media on Demand (Unicast) ................................257
A.5. Single-Stream Container Files ............................260
A.6. Live Media Presentation Using Multicast ..................263
A.7. Capability Negotiation ...................................264
Appendix B. RTSP Protocol State Machine ..........................265
B.1. States ...................................................266
B.2. State Variables ..........................................266
B.3. Abbreviations ............................................266
B.4. State Tables .............................................267
Appendix C. Media-Transport Alternatives .........................272
C.1. RTP ......................................................272
C.1.1. AVP ..................................................272
C.1.2. AVP/UDP ..............................................273
C.1.3. AVPF/UDP .............................................274
C.1.4. SAVP/UDP .............................................275
C.1.5. SAVPF/UDP ............................................277
C.1.6. RTCP Usage with RTSP .................................278
C.2. RTP over TCP .............................................279
C.2.1. Interleaved RTP over TCP .............................280
C.2.2. RTP over Independent TCP .............................280
C.3. Handling Media-Clock Time Jumps in the RTP Media Layer ...284
C.4. Handling RTP Timestamps after PAUSE ......................287
C.5. RTSP/RTP Integration ....................................290
C.6. Scaling with RTP .........................................290
C.7. Maintaining NPT Synchronization with RTP Timestamps ......290
C.8. Continuous Audio .........................................290
C.9. Multiple Sources in an RTP Session .......................290
C.10. Usage of SSRCs and the RTCP BYE Message during an RTSP
Session .................................................290
C.11. Future Additions ........................................291
Appendix D. Use of SDP for RTSP Session Descriptions .............292
D.1. Definitions .............................................292
D.1.1. Control URI ..........................................292
D.1.2. Media Streams ........................................294
D.1.3. Payload Type(s) ......................................294
D.1.4. Format-Specific Parameters ...........................294
D.1.5. Directionality of Media Stream .......................295
D.1.6. Range of Presentation ................................295
D.1.7. Time of Availability .................................296
D.1.8. Connection Information ...............................297
D.1.9. Message Body Tag .....................................297
D.2. Aggregate Control Not Available ..........................298
D.3. Aggregate Control Available ..............................298
D.4. Grouping of Media Lines in SDP ...........................299
D.5. RTSP External SDP Delivery ...............................300
Appendix E. RTSP Use Cases .......................................300
E.1. On-Demand Playback of Stored Content .....................300
E.2. Unicast Distribution of Live Content .....................302
E.3. On-Demand Playback Using Multicast .......................303
E.4. Inviting an RTSP Server into a Conference ................303
E.5. Live Content Using Multicast .............................304
Appendix F. Text Format for Parameters ...........................305
Appendix G. Requirements for Unreliable Transport of RTSP ........305
Appendix H. Backwards-Compatibility Considerations ...............306
H.1. Play Request in Play State ...............................307
H.2. Using Persistent Connections .............................307
Appendix I. Changes ..............................................307
I.1. Brief Overview ...........................................308
I.2. Detailed List of Changes .................................309
Acknowledgements .................................................316
Contributors ....................................................317
Authors' Addresses ...............................................318
C.1.6. RTCP Usage with RTSP .................................278
C.2. RTP over TCP .............................................279
C.2.1. Interleaved RTP over TCP .............................280
C.2.2. RTP over Independent TCP .............................280
C.3. Handling Media-Clock Time Jumps in the RTP Media Layer ...284
C.4. Handling RTP Timestamps after PAUSE ......................287
C.5. RTSP/RTP Integration ....................................290
C.6. Scaling with RTP .........................................290
C.7. Maintaining NPT Synchronization with RTP Timestamps ......290
C.8. Continuous Audio .........................................290
C.9. Multiple Sources in an RTP Session .......................290
C.10. Usage of SSRCs and the RTCP BYE Message during an RTSP
Session .................................................290
C.11. Future Additions ........................................291
Appendix D. Use of SDP for RTSP Session Descriptions .............292
D.1. Definitions .............................................292
D.1.1. Control URI ..........................................292
D.1.2. Media Streams ........................................294
D.1.3. Payload Type(s) ......................................294
D.1.4. Format-Specific Parameters ...........................294
D.1.5. Directionality of Media Stream .......................295
D.1.6. Range of Presentation ................................295
D.1.7. Time of Availability .................................296
D.1.8. Connection Information ...............................297
D.1.9. Message Body Tag .....................................297
D.2. Aggregate Control Not Available ..........................298
D.3. Aggregate Control Available ..............................298
D.4. Grouping of Media Lines in SDP ...........................299
D.5. RTSP External SDP Delivery ...............................300
Appendix E. RTSP Use Cases .......................................300
E.1. On-Demand Playback of Stored Content .....................300
E.2. Unicast Distribution of Live Content .....................302
E.3. On-Demand Playback Using Multicast .......................303
E.4. Inviting an RTSP Server into a Conference ................303
E.5. Live Content Using Multicast .............................304
Appendix F. Text Format for Parameters ...........................305
Appendix G. Requirements for Unreliable Transport of RTSP ........305
Appendix H. Backwards-Compatibility Considerations ...............306
H.1. Play Request in Play State ...............................307
H.2. Using Persistent Connections .............................307
Appendix I. Changes ..............................................307
I.1. Brief Overview ...........................................308
I.2. Detailed List of Changes .................................309
Acknowledgements .................................................316
Contributors ....................................................317
Authors' Addresses ...............................................318
This memo defines version 2.0 of the Real-Time Streaming Protocol (RTSP 2.0). RTSP 2.0 is an application-layer protocol for the setup and control over the delivery of data with real-time properties, typically streaming media. Streaming media is, for instance, video on demand or audio live streaming. Put simply, RTSP acts as a "network remote control" for multimedia servers.
本备忘录定义了实时流协议（RTSP 2.0）的2.0版。RTSP 2.0是一种应用层协议，用于设置和控制具有实时属性的数据（通常为流媒体）的传输。例如，流媒体是视频点播或音频直播。简单地说，RTSP充当多媒体服务器的“网络远程控制”。
The protocol operates between RTSP 2.0 clients and servers, but it also supports the use of proxies placed between clients and servers. Clients can request information about streaming media from servers by asking for a description of the media or use media description provided externally. The media delivery protocol is used to establish the media streams described by the media description. Clients can then request to play out the media, pause it, or stop it completely. The requested media can consist of multiple audio and video streams that are delivered as time-synchronized streams from servers to clients.
该协议在RTSP 2.0客户端和服务器之间运行，但也支持在客户端和服务器之间使用代理。客户端可以通过请求媒体描述或使用外部提供的媒体描述，从服务器请求有关流媒体的信息。媒体交付协议用于建立由媒体描述描述的媒体流。然后，客户端可以请求播放媒体、暂停媒体或完全停止媒体。请求的媒体可以由多个音频和视频流组成，这些音频和视频流作为时间同步流从服务器传送到客户端。
RTSP 2.0 is a replacement of RTSP 1.0 [RFC2326] and this document obsoletes that specification. This protocol is based on RTSP 1.0 but is not backwards compatible other than in the basic version negotiation mechanism. The changes between the two documents are listed in Appendix I. There are many reasons why RTSP 2.0 can't be backwards compatible with RTSP 1.0; some of the main ones are as follows:
RTSP 2.0是RTSP 1.0[RFC2326]的替代品，本文件废除了该规范。此协议基于RTSP 1.0，但除了在基本版本协商机制中之外，不向后兼容。两个文件之间的变化列于附录一。RTSP 2.0不能向后兼容RTSP 1.0的原因有很多；其中一些主要问题如下：
o Most headers that needed to be extensible did not define the allowed syntax, preventing safe deployment of extensions;
o 大多数需要扩展的头没有定义允许的语法，从而妨碍了扩展的安全部署；
o the changed behavior of the PLAY method when received in Play state;
o 在播放状态下接收时播放方法的变化行为；
o the changed behavior of the extensibility model and its mechanism; and
o 可扩展性模型的变化行为及其机制；和
o the change of syntax for some headers.
o 某些标题的语法更改。
There are so many small updates that changing versions became necessary to enable clarification and consistent behavior. Anyone implementing RTSP for a new use case in which they have not installed RTSP 1.0 should only implement RTSP 2.0 to avoid having to deal with RTSP 1.0 inconsistencies.
有如此多的小的更新，改变版本成为必要的，以使澄清和一致的行为。任何为未安装RTSP 1.0的新用例实施RTSP的人都应该只实施RTSP 2.0，以避免必须处理RTSP 1.0的不一致性。
This document is structured as follows. It begins with an overview of the protocol operations and its functions in an informal way. Then, a set of definitions of terms used and document conventions is
本文件的结构如下。首先以非正式的方式概述协议操作及其功能。然后，创建一组术语定义和文档约定
introduced. These are followed by the actual RTSP 2.0 core protocol specification. The appendices describe and define some functionalities that are not part of the core RTSP specification, but which are still important to enable some usages. Among them, the RTP usage is defined in Appendix C, the Session Description Protocol (SDP) usage with RTSP is defined in Appendix D, and the "text/ parameters" file format Appendix F, are three normative specification appendices. Other appendices include a number of informational parts discussing the changes, use cases, different considerations or motivations.
介绍。接下来是实际的RTSP 2.0核心协议规范。附录描述并定义了一些功能，这些功能不是核心RTSP规范的一部分，但对于实现某些用途仍然很重要。其中，RTP使用在附录C中定义，RTSP会话描述协议（SDP）使用在附录D中定义，以及“文本/参数”文件格式附录F是三个规范性附录。其他附录包括许多讨论变更、用例、不同注意事项或动机的信息部分。
This section provides an informative overview of the different mechanisms in the RTSP 2.0 protocol to give the reader a high-level understanding before getting into all the specific details. In case of conflict with this description and the later sections, the later sections take precedence. For more information about use cases considered for RTSP, see Appendix E.
本节提供RTSP 2.0协议中不同机制的信息性概述，以便读者在了解所有具体细节之前有一个高层次的理解。如果与本说明和后面的章节有冲突，以后面的章节为准。有关RTSP考虑的用例的更多信息，请参见附录E。
RTSP 2.0 is a bidirectional request and response protocol that first establishes a context including content resources (the media) and then controls the delivery of these content resources from the provider to the consumer. RTSP has three fundamental parts: Session Establishment, Media Delivery Control, and an extensibility model described below. The protocol is based on some assumptions about existing functionality to provide a complete solution for client-controlled real-time media delivery.
RTSP 2.0是一种双向请求和响应协议，它首先建立一个包含内容资源（媒体）的上下文，然后控制这些内容资源从提供者到消费者的传递。RTSP有三个基本部分：会话建立、媒体交付控制和下面描述的扩展性模型。该协议基于对现有功能的一些假设，为客户端控制的实时媒体交付提供了完整的解决方案。
RTSP uses text-based messages, requests and responses, that may contain a binary message body. An RTSP request starts with a method line that identifies the method, the protocol, and version and the resource on which to act. The resource is identified by a URI and the hostname part of the URI is used by RTSP client to resolve the IPv4 or IPv6 address of the RTSP server. Following the method line are a number of RTSP headers. These lines are ended by two consecutive carriage return line feed (CRLF) character pairs. The message body, if present, follows the two CRLF character pairs, and the body's length is described by a message header. RTSP responses are similar, but they start with a response line with the protocol and version followed by a status code and a reason phrase. RTSP messages are sent over a reliable transport protocol between the client and server. RTSP 2.0 requires clients and servers to implement TCP and TLS over TCP as mandatory transports for RTSP messages.
RTSP使用基于文本的消息、请求和响应，这些消息、请求和响应可能包含二进制消息体。RTSP请求从一个方法行开始，该方法行标识方法、协议、版本和要操作的资源。资源由URI标识，URI的主机名部分由RTSP客户端用于解析RTSP服务器的IPv4或IPv6地址。方法行后面是一些RTSP头。这些行由两个连续的回车换行符（CRLF）字符对结束。消息正文（如果存在）位于两个CRLF字符对之后，正文的长度由消息头描述。RTSP响应类似，但它们以一个带有协议和版本的响应行开始，后跟一个状态代码和一个原因短语。RTSP消息通过客户端和服务器之间的可靠传输协议发送。RTSP 2.0要求客户端和服务器通过TCP实现TCP和TLS，作为RTSP消息的强制传输。
RTSP exists to provide access to multimedia presentations and content but tries to be agnostic about the media type or the actual media delivery protocol that is used. To enable a client to implement a complete system, an RTSP-external mechanism for describing the presentation and the delivery protocol(s) is used. RTSP assumes that this description is either delivered completely out of band or as a data object in the response to a client's request using the DESCRIBE method (Section 13.2).
RTSP的存在是为了提供对多媒体演示文稿和内容的访问，但试图对所使用的媒体类型或实际的媒体交付协议不可知。为了使客户端能够实现一个完整的系统，使用RTSP外部机制来描述表示和交付协议。RTSP假设该描述要么完全带外交付，要么作为响应客户请求的数据对象，使用描述方法（第13.2节）。
Parameters that commonly have to be included in the presentation description are the following:
演示文稿描述中通常必须包含的参数如下：
o The number of media streams;
o 媒体流的数量；
o the resource identifier for each media stream/resource that is to be controlled by RTSP;
o 要由RTSP控制的每个媒体流/资源的资源标识符；
o the protocol that will be used to deliver each media stream;
o 用于传送每个媒体流的协议；
o the transport protocol parameters that are not negotiated or vary with each client;
o 未协商的传输协议参数，或因每个客户端而异；
o the media-encoding information enabling a client to correctly decode the media upon reception; and
o 媒体编码信息，使得客户端能够在接收时正确解码媒体；和
o an aggregate control resource identifier.
o 聚合控制资源标识符。
RTSP uses its own URI schemes ("rtsp" and "rtsps") to reference media resources and aggregates under common control (see Section 4.2).
RTSP使用其自己的URI方案（“RTSP”和“RTSP”）引用共同控制下的媒体资源和聚合（见第4.2节）。
This specification describes in Appendix D how one uses SDP [RFC4566] for describing the presentation.
本规范在附录D中描述了如何使用SDP[RFC4566]来描述演示文稿。
The RTSP client can request the establishment of an RTSP session after having used the presentation description to determine which media streams are available, which media delivery protocol is used, and the resource identifiers of the media streams. The RTSP session is a common context between the client and the server that consists of one or more media resources that are to be under common media delivery control.
RTSP客户端可以在使用表示描述来确定哪些媒体流可用、使用哪个媒体交付协议以及媒体流的资源标识符之后请求建立RTSP会话。RTSP会话是客户端和服务器之间的公共上下文，由一个或多个受公共媒体交付控制的媒体资源组成。
The client creates an RTSP session by sending a request using the SETUP method (Section 13.3) to the server. In the Transport header (Section 18.54) of the SETUP request, the client also includes all
客户端通过使用设置方法（第13.3节）向服务器发送请求来创建RTSP会话。在设置请求的传输标头（第18.54节）中，客户端还包括所有
the transport parameters necessary to enable the media delivery protocol to function. This includes parameters that are preestablished by the presentation description but necessary for any middlebox to correctly handle the media delivery protocols. The Transport header in a request may contain multiple alternatives for media delivery in a prioritized list, which the server can select from. These alternatives are typically based on information in the presentation description.
启用媒体传送协议所需的传输参数。这包括由演示文稿描述预先建立的参数，但这些参数对于任何中间盒都是正确处理媒体交付协议所必需的。请求中的传输头可能包含多个优先级列表中的媒体交付备选方案，服务器可以从中进行选择。这些备选方案通常基于演示文稿描述中的信息。
When receiving a SETUP request, the server determines if the media resource is available and if one or more of the of the transport parameter specifications are acceptable. If that is successful, an RTSP session context is created and the relevant parameters and state is stored. An identifier is created for the RTSP session and included in the response in the Session header (Section 18.49). The SETUP response includes a Transport header that specifies which of the alternatives has been selected and relevant parameters.
当接收到设置请求时，服务器将确定媒体资源是否可用，以及一个或多个传输参数规范是否可接受。如果成功，将创建RTSP会话上下文，并存储相关参数和状态。为RTSP会话创建一个标识符，并包含在会话头中的响应中（第18.49节）。设置响应包括一个传输头，指定选择了哪些备选方案以及相关参数。
A SETUP request that references an existing RTSP session but identifies a new media resource is a request to add that media resource under common control with the already-present media resources in an aggregated session. A client can expect this to work for all media resources under RTSP control within a multimedia content container. However, a server will likely refuse to aggregate resources from different content containers. Even if an RTSP session contains only a single media stream, the RTSP session can be referenced by the aggregate control URI.
引用现有RTSP会话但标识新媒体资源的设置请求是将该媒体资源添加到聚合会话中已存在的媒体资源的共同控制下的请求。客户机可以期望这适用于多媒体内容容器中RTSP控制下的所有媒体资源。但是，服务器可能会拒绝聚合来自不同内容容器的资源。即使RTSP会话仅包含单个媒体流，该RTSP会话也可以被聚合控制URI引用。
To avoid an extra round trip in the session establishment of aggregated RTSP sessions, RTSP 2.0 supports pipelined requests; i.e., the client can send multiple requests back-to-back without waiting first for the completion of any of them. The client uses a client-selected identifier in the Pipelined-Requests header (Section 18.33) to instruct the server to bind multiple requests together as if they included the session identifier.
为了避免在聚合RTSP会话的会话建立过程中出现额外的往返，RTSP 2.0支持流水线请求；i、 例如，客户端可以背靠背发送多个请求，而无需先等待其中任何一个请求的完成。客户端在Pipelined Requests标头（第18.33节）中使用客户端选择的标识符来指示服务器将多个请求绑定在一起，就像它们包含会话标识符一样。
The SETUP response also provides additional information about the established sessions in a couple of different headers. The Media-Properties header (Section 18.29) includes a number of properties that apply for the aggregate that is valuable when doing media delivery control and configuring user interface. The Accept-Ranges header (Section 18.5) informs the client about range formats that the server supports for these media resources. The Media-Range header (Section 18.30) informs the client about the time range of the media currently available.
设置响应还通过几个不同的标题提供有关已建立会话的附加信息。介质属性标题（第18.29节）包括许多适用于聚合的属性，这些属性在执行介质交付控制和配置用户界面时很有价值。Accept Ranges标头（第18.5节）通知客户端服务器支持的这些媒体资源的范围格式。介质范围标题（第18.30节）通知客户当前可用介质的时间范围。
After having established an RTSP session, the client can start controlling the media delivery. The basic operations are "begin playback", using the PLAY method (Section 13.4) and "suspend (pause) playback" by using the PAUSE method (Section 13.6). PLAY also allows for choosing the starting media position from which the server should deliver the media. The positioning is done by using the Range header (Section 18.40) that supports several different time formats: Normal Play Time (NPT) (Section 4.4.2), Society of Motion Picture and Television Engineers (SMPTE) Timestamps (Section 4.4.1), and absolute time (Section 4.4.3). The Range header also allows the client to specify a position where delivery should end, thus allowing a specific interval to be delivered.
建立RTSP会话后，客户机可以开始控制媒体交付。基本操作为使用播放方法（第13.4节）的“开始播放”和使用暂停方法（第13.6节）的“暂停（暂停）播放”。播放还允许选择服务器应从中传送介质的起始介质位置。通过使用支持几种不同时间格式的范围标头（第18.40节）进行定位：正常播放时间（NPT）（第4.4.2节）、电影和电视工程师协会（SMPTE）时间戳（第4.4.1节）和绝对时间（第4.4.3节）。范围标头还允许客户端指定交付结束的位置，从而允许交付特定的间隔。
The support for positioning/searching within media content depends on the content's media properties. Content exists in a number of different types, such as on-demand, live, and live with simultaneous recording. Even within these categories, there are differences in how the content is generated and distributed, which affect how it can be accessed for playback. The properties applicable for the RTSP session are provided by the server in the SETUP response using the Media-Properties header (Section 18.29). These are expressed using one or several independent attributes. A first attribute is Random-Access, which indicates whether positioning is possible, and with what granularity. Another aspect is whether the content will change during the lifetime of the session. While on-demand content will be provided in full from the beginning, a live stream being recorded results in the length of the accessible content growing as the session goes on. There also exists content that is dynamically built by a protocol other than RTSP and, thus, also changes in steps during the session, but maybe not continuously. Furthermore, when content is recorded, there are cases where the complete content is not maintained, but, for example, only the last hour. All of these properties result in the need for mechanisms that will be discussed below.
在媒体内容中定位/搜索的支持取决于内容的媒体属性。内容有多种不同类型，如点播、直播和同步录制直播。即使在这些类别中，内容的生成和分发方式也存在差异，这会影响如何访问内容进行播放。适用于RTSP会话的属性由服务器在设置响应中使用媒体属性标题（第18.29节）提供。这些属性使用一个或多个独立属性表示。第一个属性是随机访问，它指示定位是否可能，以及粒度如何。另一个方面是内容是否会在会话的生存期内更改。虽然点播内容将从一开始就全部提供，但录制的实时流会导致可访问内容的长度随着会话的进行而增加。还存在由RTSP以外的协议动态构建的内容，因此，在会话期间也会发生步骤上的更改，但可能不会连续更改。此外，当记录内容时，存在不维护完整内容的情况，例如，仅维护最后一小时。所有这些特性都需要下面讨论的机制。
When the client accesses on-demand content that allows random access, the client can issue the PLAY request for any point in the content between the start and the end. The server will deliver media from the closest random access point prior to the requested point and indicate that in its PLAY response. If the client issues a PAUSE, the delivery will be halted and the point at which the server stopped will be reported back in the response. The client can later resume by sending a PLAY request without a Range header. When the server is about to complete the PLAY request by delivering the end of the content or the requested range, the server will send a PLAY_NOTIFY request (Section 13.5) indicating this.
当客户端访问允许随机访问的按需内容时，客户端可以对内容中从开始到结束的任何点发出播放请求。服务器将从请求点之前最近的随机访问点传送媒体，并在其播放响应中指示。如果客户端发出暂停，则传递将停止，服务器停止的点将在响应中报告。客户端可以稍后通过发送不带范围标头的播放请求来恢复。当服务器即将通过交付内容或请求范围的结尾来完成播放请求时，服务器将发送一个播放通知请求（第13.5节），表明这一点。
When playing live content with no extra functions, such as recording, the client will receive the live media from the server after having sent a PLAY request. Seeking in such content is not possible as the server does not store it, but only forwards it from the source of the session. Thus, delivery continues until the client sends a PAUSE request, tears down the session, or the content ends.
当播放没有额外功能（如录制）的直播内容时，客户端将在发送播放请求后从服务器接收直播媒体。不可能在此类内容中查找，因为服务器不存储它，而只从会话源转发它。因此，交付将继续，直到客户端发送暂停请求、中断会话或内容结束。
For live sessions that are being recorded, the client will need to keep track of how the recording progresses. Upon session establishment, the client will learn the current duration of the recording from the Media-Range header. Because the recording is ongoing, the content grows in direct relation to the time passed. Therefore, each server's response to a PLAY request will contain the current Media-Range header. The server should also regularly send (approximately every 5 minutes) the current media range in a PLAY_NOTIFY request (Section 13.5.2). If the live transmission ends, the server must send a PLAY_NOTIFY request with the updated Media-Properties indicating that the content stopped being a recorded live session and instead became on-demand content; the request also contains the final media range. While the live delivery continues, the client can request to play the current live point by using the NPT timescale symbol "now", or it can request a specific point in the available content by an explicit range request for that point. If the requested point is outside of the available interval, the server will adjust the position to the closest available point, i.e., either at the beginning or the end.
对于正在录制的实时会话，客户端将需要跟踪录制过程。会话建立后，客户端将从媒体范围标头了解当前录制的持续时间。由于录制正在进行，因此内容的增长与时间的流逝直接相关。因此，每个服务器对播放请求的响应将包含当前媒体范围标头。服务器还应定期（大约每5分钟）发送播放通知请求中的当前媒体范围（第13.5.2节）。如果实时传输结束，服务器必须发送一个PLAY_NOTIFY请求，该请求带有更新的媒体属性，指示内容不再是录制的实时会话，而是按需内容；请求还包含最终媒体范围。当直播继续进行时，客户端可以使用NPT时间刻度符号“now”请求播放当前直播点，也可以通过对该点的显式范围请求来请求可用内容中的特定点。如果请求的点在可用间隔之外，服务器将调整位置到最近的可用点，即在起始点或结束点。
A special case of recording is that where the recording is not retained longer than a specific time period; thus, as the live delivery continues, the client can access any media within a moving window that covers, for example, "now" to "now" minus 1 hour. A client that pauses on a specific point within the content may not be able to retrieve the content anymore. If the client waits too long before resuming the pause point, the content may no longer be available. In this case, the pause point will be adjusted to the closest point in the available media.
记录的一种特殊情况是，记录的保留时间不超过特定的时间段；因此，随着实时交付的继续，客户机可以访问移动窗口内的任何媒体，例如，“现在”到“现在”减去1小时。在内容中的特定点暂停的客户端可能无法再检索内容。如果客户端在恢复暂停点之前等待的时间过长，则内容可能不再可用。在这种情况下，暂停点将调整到可用介质中最近的点。
A session may have additional state or functionality that affects how the server or client treats the session or content, how it functions, or feedback on how well the session works. Such extensions are not defined in this specification, but they may be covered in various extensions. RTSP has two methods for retrieving and setting parameter values on either the client or the server: GET_PARAMETER (Section 13.8) and SET_PARAMETER (Section 13.9). These methods carry the parameters in a message body of the appropriate format. One can also use headers to query state with the GET_PARAMETER method. As an
会话可能具有其他状态或功能，这些状态或功能会影响服务器或客户端处理会话或内容的方式、会话的工作方式或会话工作情况的反馈。本规范中未定义此类扩展，但它们可能包含在各种扩展中。RTSP有两种在客户端或服务器上检索和设置参数值的方法：GET_参数（第13.8节）和SET_参数（第13.9节）。这些方法在适当格式的消息体中携带参数。还可以使用头使用GET_参数方法查询状态。作为
example, clients needing to know the current media range for a time-progressing session can use the GET_PARAMETER method and include the media range. Furthermore, synchronization information can be requested by using a combination of RTP-Info (Section 18.45) and Range (Section 18.40).
例如，需要知道时间进程会话的当前媒体范围的客户端可以使用GET_参数方法并包括媒体范围。此外，可以使用RTP信息（第18.45节）和范围（第18.40节）的组合来请求同步信息。
RTSP 2.0 does not have a strong mechanism for negotiating the headers or parameters and their formats. However, responses will indicate request-headers or parameters that are not supported. A priori determination of what features are available needs to be done through out-of-band mechanisms, like the session description, or through the usage of feature tags (Section 4.5).
RTSP 2.0没有用于协商标头或参数及其格式的强大机制。但是，响应将指示不受支持的请求头或参数。需要通过带外机制（如会话描述）或通过使用功能标签（第4.5节）预先确定可用的功能。
This document specifies how media is delivered with RTP [RFC3550] over UDP [RFC768], TCP [RFC793], or the RTSP connection. Additional protocols may be specified in the future as needed.
本文档指定如何通过UDP[RFC768]、TCP[RFC793]或RTSP连接使用RTP[RFC3550]交付媒体。将来可能会根据需要指定附加协议。
The usage of RTP as a media delivery protocol requires some additional information to function well. The PLAY response contains information to enable reliable and timely delivery of how a client should synchronize different sources in the different RTP sessions. It also provides a mapping between RTP timestamps and the content-time scale. When the server wants to notify the client about the completion of the media delivery, it sends a PLAY_NOTIFY request to the client. The PLAY_NOTIFY request includes information about the stream end, including the last RTP sequence number for each stream, thus enabling the client to empty the buffer smoothly.
将RTP用作媒体交付协议需要一些附加信息才能正常工作。播放响应包含的信息能够可靠、及时地提供客户端应如何在不同RTP会话中同步不同源的信息。它还提供RTP时间戳和内容时间尺度之间的映射。当服务器想要通知客户端媒体交付完成时，它会向客户端发送PLAY_notify请求。PLAY_NOTIFY请求包括关于流结束的信息，包括每个流的最后一个RTP序列号，从而使客户端能够顺利清空缓冲区。
The basic playback functionality of RTSP enables delivery of a range of requested content to the client at the pace intended by the content's creator. However, RTSP can also manipulate the delivery to the client in two ways.
RTSP的基本播放功能允许以内容创建者指定的速度向客户端交付一系列请求的内容。但是，RTSP还可以通过两种方式操纵向客户端的传递。
Scale: The ratio of media-content time delivered per unit of playback time.
比例：每单位播放时间内交付的媒体内容时间的比率。
Speed: The ratio of playback time delivered per unit of wallclock time.
速度：每单位挂钟时间的播放时间的比率。
Both affect the media delivery per time unit. However, they manipulate two independent timescales and the effects are possible to combine.
两者都会影响每个时间单位的介质传输。然而，它们操纵着两个独立的时间尺度，并且效果可以结合起来。
Scale (Section 18.46) is used for fast-forward or slow-motion control as it changes the amount of content timescale that should be played back per time unit. Scale > 1.0, means fast forward, e.g., scale = 2.0 results in that 2 seconds of content being played back every second of playback. Scale = 1.0 is the default value that is used if no scale is specified, i.e., playback at the content's original rate. Scale values between 0 and 1.0 provide for slow motion. Scale can be negative to allow for reverse playback in either regular pace (scale = -1.0), fast backwards (scale < -1.0), or slow-motion backwards (-1.0 < scale < 0). Scale = 0 would be equal to pause and is not allowed.
缩放（第18.46节）用于快进或慢动作控制，因为它改变了每个时间单位应播放的内容时间缩放量。缩放>1.0表示快进，例如，缩放=2.0会导致每秒播放2秒的内容。比例=1.0是默认值，如果未指定比例，即以内容的原始速率播放，则使用该值。0和1.0之间的缩放值可提供慢动作。音阶可以是负数，以允许以常规配速（音阶=-1.0）、快速后退（音阶<-1.0）或慢速后退（-1.0<音阶<0）进行反向播放。Scale=0将等于暂停，不允许。
In most cases, the realization of scale means server-side manipulation of the media to ensure that the client can actually play it back. The nature of these media manipulations and when they are needed is highly media-type dependent. Let's consider two common media types, audio and video.
在大多数情况下，scale的实现意味着服务器端对媒体进行操作，以确保客户端可以实际播放媒体。这些介质操作的性质和需要的时间高度依赖于介质类型。让我们考虑两种常见的媒体类型，音频和视频。
It is very difficult to modify the playback rate of audio. Typically, no more than a factor of two is possible while maintaining intelligibility by changing the pitch and rate of speech. Music goes out of tune if one tries to manipulate the playback rate by resampling it. This is a well-known problem, and audio is commonly muted or played back in short segments with skips to keep up with the current playback point.
修改音频的播放速率非常困难。通常，在通过改变音调和语速来保持清晰度的同时，不可能超过2倍。如果试图通过重新采样来控制播放速率，音乐就会走调。这是一个众所周知的问题，音频通常会静音或以短片段播放，并跳过以跟上当前播放点。
For video, it is possible to manipulate the frame rate, although the rendering capabilities are often limited to certain frame rates. Also, the allowed bitrates in decoding, the structure used in the encoding, and the dependency between frames and other capabilities of the rendering device limits the possible manipulations. Therefore, the basic fast-forward capabilities often are implemented by selecting certain subsets of frames.
对于视频，可以操纵帧速率，尽管渲染功能通常限于某些帧速率。此外，解码中允许的比特率、编码中使用的结构以及渲染设备的帧和其他功能之间的依赖性限制了可能的操作。因此，基本快进功能通常通过选择帧的某些子集来实现。
Due to the media restrictions, the possible scale values are commonly restricted to the set of realizable scale ratios. To enable the clients to select from the possible scale values, RTSP can signal the supported scale ratios for the content. To support aggregated or dynamic content, where this may change during the ongoing session and dependent on the location within the content, a mechanism for updating the media properties and the scale factor currently in use, exists.
由于介质限制，可能的标度值通常限制为可实现的标度比。为了使客户端能够从可能的比例值中进行选择，RTSP可以为内容发送支持的比例信号。为了支持聚合或动态内容（在正在进行的会话期间可能会发生变化，并且取决于内容中的位置），存在一种用于更新媒体属性和当前使用的比例因子的机制。
Speed (Section 18.50) affects how much of the playback timeline is delivered in a given wallclock period. The default is Speed = 1 which means to deliver at the same rate the media is consumed. Speed > 1 means that the receiver will get content faster than it regularly would consume it. Speed < 1 means that delivery is slower
速度（第18.50节）影响在给定的时钟周期内播放时间线的多少。默认值为速度=1，这意味着以与介质消耗相同的速率传输介质。速度>1意味着接收者获取内容的速度将快于其正常消费的速度。速度<1表示传递速度较慢
than the regular media rate. Speed values of 0 or lower have no meaning and are not allowed. This mechanism enables two general functionalities. One is client-side scale operations, i.e., the client receives all the frames and makes the adjustment to the playback locally. The second is delivery control for the buffering of media. By specifying a speed over 1.0, the client can build up the amount of playback time it has present in its buffers to a level that is sufficient for its needs.
比正常的媒体速率高。0或更低的速度值没有意义，不允许。此机制支持两种通用功能。一种是客户端缩放操作，即客户端接收所有帧并在本地对回放进行调整。第二个是介质缓冲的传递控制。通过指定超过1.0的速度，客户端可以将其缓冲区中的播放时间累积到足以满足其需要的水平。
A naive implementation of Speed would only affect the transmission schedule of the media and has a clear impact on the needed bandwidth. This would result in the data rate being proportional to the speed factor. Speed = 1.5, i.e., 50% faster than normal delivery, would result in a 50% increase in the data-transport rate. Whether or not that can be supported depends solely on the underlying network path. Scale may also have some impact on the required bandwidth due to the manipulation of the content in the new playback schedule. An example is fast forward where only the independently decodable intra-frames are included in the media stream. This usage of solely intra-frames increases the data rate significantly compared to a normal sequence with the same number of frames, where most frames are encoded using prediction.
速度的简单实现只会影响媒体的传输计划，并对所需带宽产生明显影响。这将导致数据速率与速度系数成比例。速度=1.5，即比正常传输速度快50%，将导致数据传输速率增加50%。是否支持这一点完全取决于底层网络路径。由于在新的播放时间表中对内容进行操作，缩放还可能对所需带宽产生一些影响。一个示例是快进，其中媒体流中仅包括独立可解码的帧内帧。与具有相同帧数的正常序列相比，仅使用帧内帧显著提高了数据速率，其中大多数帧使用预测进行编码。
This potential increase of the data rate needs to be handled by the media sender. The client has requested that the media be delivered in a specific way, which should be honored. However, the media sender cannot ignore if the network path between the sender and the receiver can't handle the resulting media stream. In that case, the media stream needs to be adapted to fit the available resources of the path. This can result in a reduced media quality.
数据速率的这种潜在增长需要由媒体发送方处理。客户要求以特定的方式交付媒体，这应该得到尊重。但是，如果发送方和接收方之间的网络路径无法处理生成的媒体流，则媒体发送方不能忽略。在这种情况下，需要调整媒体流以适合路径的可用资源。这可能导致介质质量降低。
The need for bitrate adaptation becomes especially problematic in connection with the Speed semantics. If the goal is to fill up the buffer, the client may not want to do that at the cost of reduced quality. If the client wants to make local playout changes, then it may actually require that the requested speed be honored. To resolve this issue, Speed uses a range so that both cases can be supported. The server is requested to use the highest possible speed value within the range, which is compatible with the available bandwidth. As long as the server can maintain a speed value within the range, it shall not change the media quality, but instead modify the actual delivery rate in response to available bandwidth and reflect this in the Speed value in the response. However, if this is not possible, the server should instead modify the media quality to respect the lowest speed value and the available bandwidth.
在速度语义方面，比特率自适应的需要变得特别困难。如果目标是填充缓冲区，客户机可能不希望以降低质量为代价来填充缓冲区。如果客户端想要进行本地播放更改，那么实际上可能需要遵守请求的速度。为了解决这个问题，Speed使用了一个范围，这样两种情况都可以得到支持。要求服务器使用与可用带宽兼容的范围内可能的最高速度值。只要服务器能够将速度值保持在该范围内，它就不会改变媒体质量，而是会根据可用带宽修改实际传输速率，并将其反映在响应中的速度值中。但是，如果这是不可能的，服务器应该改为修改媒体质量，以符合最低速度值和可用带宽。
This functionality enables the local scaling implementation to use a tight range, or even a range where the lower bound equals the upper bound, to identify that it requires the server to deliver the requested amount of media time per delivery time, independent of how much it needs to adapt the media quality to fit within the available path bandwidth. For buffer filling, it is suitable to use a range with a reasonable span and with a lower bound at the nominal media rate 1.0, such as 1.0 - 2.5. If the client wants to reduce the buffer, it can specify an upper bound that is below 1.0 to force the server to deliver slower than the nominal media rate.
此功能使本地扩展实现能够使用一个较窄的范围，甚至是下限等于上限的范围，以确定它需要服务器在每次交付时间交付请求的媒体时间，独立于调整媒体质量以适应可用路径带宽所需的量。对于缓冲区填充，适合使用具有合理跨度的范围，并在标称介质速率1.0下具有下限，例如1.0-2.5。如果客户机希望减少缓冲区，它可以指定一个低于1.0的上限，以强制服务器以低于标称媒体速率的速度传输。
The session context that has been established is kept alive by having the client show liveness. This is done in two main ways:
已建立的会话上下文通过让客户端显示活动性来保持活动。这主要通过两种方式实现：
o Media-transport protocol keep-alive. RTP Control Protocol (RTCP) may be used when using RTP.
o 媒体传输协议保持活动状态。使用RTP时，可使用RTP控制协议（RTCP）。
o Any RTSP request referencing the session context.
o 引用会话上下文的任何RTSP请求。
Section 10.5 discusses the methods for showing liveness in more depth. If the client fails to show liveness for more than the established session timeout value (normally 60 seconds), the server may terminate the context. Other values may be selected by the server through the inclusion of the timeout parameter in the session header.
第10.5节讨论了更深入地展示活力的方法。如果客户端无法显示活跃度超过已建立的会话超时值（通常为60秒），服务器可能会终止上下文。服务器可以通过在会话头中包含超时参数来选择其他值。
The session context is normally terminated by the client sending a TEARDOWN request (Section 13.7) to the server referencing the aggregated control URI. An individual media resource can be removed from a session context by a TEARDOWN request referencing that particular media resource. If all media resources are removed from a session context, the session context is terminated.
会话上下文通常由客户端向服务器发送拆卸请求（第13.7节）并引用聚合控制URI来终止。通过引用特定媒体资源的拆卸请求，可以从会话上下文中删除单个媒体资源。如果从会话上下文中删除了所有媒体资源，则会话上下文将终止。
A client may keep the session alive indefinitely if allowed by the server; however, a client is advised to release the session context when an extended period of time without media delivery activity has passed. The client can re-establish the session context if required later. What constitutes an extended period of time is dependent on the client, server, and their usage. It is recommended that the client terminate the session before ten times the session timeout value has passed. A server may terminate the session after one session timeout period without any client activity beyond keep-alive. When a server terminates the session context, it does so by sending a TEARDOWN request indicating the reason.
如果服务器允许，客户端可以无限期地保持会话活动；但是，建议客户端在没有媒体交付活动的延长时间后释放会话上下文。如果以后需要，客户端可以重新建立会话上下文。延长时间的构成取决于客户机、服务器及其使用情况。建议客户端在超过会话超时值十倍之前终止会话。服务器可以在一个会话超时时间后终止会话，并且在保持活动状态之外没有任何客户端活动。当服务器终止会话上下文时，它通过发送指示原因的拆卸请求来终止会话上下文。
A server can also request that the client tear down the session and re-establish it at an alternative server, as may be needed for maintenance. This is done by using the REDIRECT method (Section 13.10). The Terminate-Reason header (Section 18.52) is used to indicate when and why. The Location header indicates where it should connect if there is an alternative server available. When the deadline expires, the server simply stops providing the service. To achieve a clean closure, the client needs to initiate session termination prior to the deadline. In case the server has no other server to redirect to, and it wants to close the session for maintenance, it shall use the TEARDOWN method with a Terminate-Reason header.
服务器还可以请求客户端中断会话并在备用服务器上重新建立会话，这可能是维护所需的。这是通过使用重定向方法完成的（第13.10节）。终止原因标题（第18.52节）用于指示何时以及原因。Location标头指示如果有备用服务器可用，它应该连接的位置。当截止日期到期时，服务器将停止提供服务。为了实现干净的结束，客户端需要在截止日期之前启动会话终止。如果服务器没有可重定向到的其他服务器，并且希望关闭会话进行维护，则应使用带Terminate Reason标头的TEARDOWN方法。
RTSP is quite a versatile protocol that supports extensions in many different directions. Even this core specification contains several blocks of functionality that are optional to implement. The use case and need for the protocol deployment should determine what parts are implemented. Allowing for extensions makes it possible for RTSP to address additional use cases. However, extensions will affect the interoperability of the protocol; therefore, it is important that they can be added in a structured way.
RTSP是一个非常通用的协议，支持多个不同方向的扩展。即使是这个核心规范也包含几个可选的功能块。协议部署的用例和需求应该确定实现了哪些部分。允许扩展使RTSP能够处理其他用例。但是，扩展将影响协议的互操作性；因此，以结构化的方式添加它们非常重要。
The client can learn the capability of a server by using the OPTIONS method (Section 13.1) and the Supported header (Section 18.51). It can also try and possibly fail using new methods or require that particular features be supported using the Require (Section 18.43) or Proxy-Require (Section 18.37) header.
客户机可以通过使用选项方法（第13.1节）和支持的标题（第18.51节）了解服务器的功能。它还可以尝试使用新方法并可能失败，或者要求使用require（第18.43节）或Proxy require（第18.37节）标头支持特定功能。
The RTSP, in itself, can be extended in three ways, listed here in increasing order of the magnitude of changes supported:
RTSP本身可以通过三种方式进行扩展，此处按支持的更改的数量级递增顺序列出：
o Existing methods can be extended with new parameters, for example, headers, as long as these parameters can be safely ignored by the recipient. If the client needs negative acknowledgment when a method extension is not supported, a tag corresponding to the extension may be added in the field of the Require or Proxy-Require headers.
o 现有方法可以使用新参数（例如，头）进行扩展，只要收件人可以安全地忽略这些参数。如果客户端在不支持方法扩展时需要否定确认，则可以在Require或Proxy Require头的字段中添加与扩展对应的标记。
o New methods can be added. If the recipient of the message does not understand the request, it must respond with error code 501 (Not Implemented) so that the sender can avoid using this method again. A client may also use the OPTIONS method to inquire about methods supported by the server. The server must list the methods it supports using the Public response-header.
o 可以添加新方法。如果邮件的收件人不理解请求，则必须使用错误代码501（未实现）进行响应，以便发件人可以避免再次使用此方法。客户端还可以使用OPTIONS方法查询服务器支持的方法。服务器必须使用公共响应头列出它支持的方法。
o A new version of the protocol can be defined, allowing almost all aspects (except the position of the protocol version number) to change. A new version of the protocol must be registered through a Standards Track document.
o 可以定义协议的新版本，允许几乎所有方面（协议版本号的位置除外）发生更改。协议的新版本必须通过标准跟踪文件进行注册。
The basic capability discovery mechanism can be used to both discover support for a certain feature and to ensure that a feature is available when performing a request. For a detailed explanation of this, see Section 11.
基本功能发现机制可用于发现对特定功能的支持，并确保在执行请求时功能可用。有关详细说明，请参见第11节。
New media delivery protocols may be added and negotiated at session establishment, in addition to extensions to the core protocol. Certain types of protocol manipulations can be done through parameter formats using SET_PARAMETER and GET_PARAMETER.
除了核心协议的扩展之外，还可以在会话建立时添加和协商新的媒体交付协议。某些类型的协议操作可以通过使用SET_参数和GET_参数的参数格式来完成。
All the mechanisms specified in this document are described in both prose and the Augmented Backus-Naur form (ABNF) described in detail in [RFC5234].
本文件中规定的所有机制均以散文和[RFC5234]中详细描述的增广巴科斯诺尔形式（ABNF）进行了描述。
Indented paragraphs are used to provide informative background and motivation. This is intended to give readers who were not involved with the formulation of the specification an understanding of why things are the way they are in RTSP.
缩进段落用于提供信息背景和动机。这是为了让未参与规范制定的读者理解RTSP中的情况为何如此。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
The word, "unspecified" is used to indicate functionality or features that are not defined in this specification. Such functionality cannot be used in a standardized manner without further definition in an extension specification to RTSP.
“未指定”一词用于表示本规范中未定义的功能或特性。如果没有RTSP扩展规范中的进一步定义，则无法以标准化方式使用此类功能。
Aggregate control: The concept of controlling multiple streams using a single timeline, generally one maintained by the server. A client, for example, uses aggregate control when it issues a single play or pause message to simultaneously control both the audio and video in a movie. A session that is under aggregate control is referred to as an "aggregated session".
聚合控制：使用单个时间线控制多个流的概念，通常由服务器维护。例如，客户端在发出单个播放或暂停消息时使用聚合控件来同时控制电影中的音频和视频。受聚合控制的会话称为“聚合会话”。
Aggregate control URI: The URI used in an RTSP request to refer to and control an aggregated session. It normally, but not always, corresponds to the presentation URI specified in the session description. See Section 13.3 for more information.
聚合控制URI：RTSP请求中用于引用和控制聚合会话的URI。它通常（但不总是）对应于会话描述中指定的表示URI。更多信息请参见第13.3节。
Client: The client is the requester of media service from the media server.
客户端：客户端是来自媒体服务器的媒体服务请求者。
Connection: A transport-layer virtual circuit established between two programs for the purpose of communication.
连接：为通信目的在两个程序之间建立的传输层虚拟电路。
Container file: A file that may contain multiple media streams that often constitute a presentation when played together. The concept of a container file is not embedded in the protocol. However, RTSP servers may offer aggregate control on the media streams within these files.
容器文件：一种可能包含多个媒体流的文件，这些媒体流在一起播放时通常构成一个演示文稿。协议中没有嵌入容器文件的概念。但是，RTSP服务器可以对这些文件中的媒体流提供聚合控制。
Continuous media: Data where there is a timing relationship between source and sink; that is, the sink needs to reproduce the timing relationship that existed at the source. The most common examples of continuous media are audio and motion video. Continuous media can be real time (interactive or conversational), where there is a "tight" timing relationship between source and sink or it can be streaming where the relationship is less strict.
连续介质：源和汇之间存在定时关系的数据；也就是说，接收器需要重现源处存在的时序关系。连续媒体最常见的例子是音频和动态视频。连续媒体可以是实时的（交互的或对话的），在源和汇之间存在“紧密”的定时关系，也可以是关系不太严格的流媒体。
Feature tag: A tag representing a certain set of functionality, i.e., a feature.
功能标签：表示特定功能集的标签，即功能。
IRI: An Internationalized Resource Identifier is similar to a URI but allows characters from the whole Universal Character Set (Unicode/ISO 10646), rather than the US-ASCII only. See [RFC3987] for more information.
IRI：国际化资源标识符类似于URI，但允许来自整个通用字符集（Unicode/ISO10646）的字符，而不仅仅是US-ASCII。有关更多信息，请参阅[RFC3987]。
Live: A live presentation or session originates media from an event taking place at the same time as the media delivery. Live sessions often have an unbound or only loosely defined duration and seek operations may not be possible.
现场：现场演示或会议从与媒体交付同时发生的事件中生成媒体。实时会话通常具有未绑定的或定义松散的持续时间，因此可能无法执行seek操作。
Media initialization: The datatype- or codec-specific initialization. This includes such things as clock rates, color tables, etc. Any transport-independent information that is required by a client for playback of a media stream occurs in the media initialization phase of stream setup.
媒体初始化：特定于数据类型或编解码器的初始化。这包括诸如时钟速率、颜色表等。客户端回放媒体流所需的任何与传输无关的信息发生在流设置的媒体初始化阶段。
Media parameter: A parameter specific to a media type that may be changed before or during stream delivery.
媒体参数：特定于媒体类型的参数，可在流传送之前或期间更改。
Media server: The server providing media-delivery services for one or more media streams. Different media streams within a presentation may originate from different media servers. A media server may reside on the same host or on a different host from which the presentation is invoked.
媒体服务器：为一个或多个媒体流提供媒体传送服务的服务器。演示文稿中的不同媒体流可能来自不同的媒体服务器。媒体服务器可以位于同一主机上，也可以位于调用演示文稿的不同主机上。
(Media) Stream: A single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. When using RTP, a stream consists of all RTP and RTCP packets created by a media source within an RTP session.
（媒体）流：单个媒体实例，例如音频流或视频流以及单个白板或共享应用程序组。使用RTP时，流由RTP会话中媒体源创建的所有RTP和RTCP数据包组成。
Message: The basic unit of RTSP communication, consisting of a structured sequence of octets matching the syntax defined in Section 20 and transmitted over a transport between RTSP agents. A message is either a request or a response.
报文：RTSP通信的基本单元，由与第20节中定义的语法相匹配的八位字节的结构化序列组成，并通过RTSP代理之间的传输进行传输。消息是请求或响应。
Message body: The information transferred as the payload of a message (request or response). A message body consists of meta-information in the form of message body headers and content in the form of an arbitrary number of data octets, as described in Section 9.
消息体：作为消息（请求或响应）有效负载传输的信息。消息体由消息体头形式的元信息和任意数量的数据八位字节形式的内容组成，如第9节所述。
Non-aggregated control: Control of a single media stream.
非聚合控制：控制单个媒体流。
Presentation: A set of one or more streams presented to the client as a complete media feed and described by a presentation description as defined below. Presentations with more than one media stream are often handled in RTSP under aggregate control.
演示文稿：一组一个或多个流，作为完整的媒体馈送呈现给客户端，并通过下面定义的演示文稿描述进行描述。具有多个媒体流的演示文稿通常在聚合控制下的RTSP中处理。
Presentation description: A presentation description contains information about one or more media streams within a presentation, such as the set of encodings, network addresses, and information about the content. Other IETF protocols, such as SDP ([RFC4566]), use the term "session" for a presentation. The presentation description may take several different formats, including but not limited to SDP format.
演示文稿描述：演示文稿描述包含有关演示文稿中一个或多个媒体流的信息，例如编码集、网络地址和有关内容的信息。其他IETF协议，如SDP（[RFC4566]）使用术语“会话”来表示。演示文稿描述可以采用几种不同的格式，包括但不限于SDP格式。
Response: An RTSP response to a request. One type of RTSP message. If an HTTP response is meant, it is indicated explicitly.
响应：对请求的RTSP响应。一种类型的RTSP消息。如果表示HTTP响应，则显式指示它。
Request: An RTSP request. One type of RTSP message. If an HTTP request is meant, it is indicated explicitly.
请求：一个RTSP请求。一种类型的RTSP消息。如果表示HTTP请求，则会显式指示该请求。
Request-URI: The URI used in a request to indicate the resource on which the request is to be performed.
请求URI：在请求中使用的URI，用于指示要在其上执行请求的资源。
RTSP agent: Either an RTSP client, an RTSP server, or an RTSP proxy. In this specification, there are many capabilities that are common to these three entities such as the capability to send requests or receive responses. This term will be used when describing functionality that is applicable to all three of these entities.
RTSP代理：RTSP客户端、RTSP服务器或RTSP代理。在本规范中，这三个实体共有许多功能，例如发送请求或接收响应的功能。该术语将用于描述适用于所有这三个实体的功能。
RTSP session: A stateful abstraction upon which the main control methods of RTSP operate. An RTSP session is a common context; it is created and maintained on a client's request and can be destroyed by either the client or server. It is established by an RTSP server upon the completion of a successful SETUP request (when a 200 OK response is sent) and is labeled with a session identifier at that time. The session exists until timed out by the server or explicitly removed by a TEARDOWN request. An RTSP session is a stateful entity; an RTSP server maintains an explicit session state machine (see Appendix B) where most state transitions are triggered by client requests. The existence of a session implies the existence of state about the session's media streams and their respective transport mechanisms. A given session can have one or more media streams associated with it. An RTSP server uses the session to aggregate control over multiple media streams.
RTSP会话：RTSP的主要控制方法操作的有状态抽象。RTSP会话是一个公共上下文；它是根据客户机的请求创建和维护的，可以由客户机或服务器销毁。它由RTSP服务器在成功完成设置请求（当发送200 OK响应时）后建立，并在此时标记为会话标识符。会话一直存在，直到服务器超时或由拆卸请求显式删除为止。RTSP会话是有状态实体；RTSP服务器维护一个显式会话状态机（见附录B），其中大多数状态转换由客户端请求触发。会话的存在意味着会话媒体流及其各自传输机制的状态存在。给定会话可以有一个或多个与之关联的媒体流。RTSP服务器使用会话聚合对多个媒体流的控制。
Origin server: The server on which a given resource resides.
源服务器：给定资源所在的服务器。
Seeking: Requesting playback from a particular point in the content time line.
搜索：从内容时间线的特定点请求播放。
Transport initialization: The negotiation of transport information (e.g., port numbers, transport protocols) between the client and the server.
传输初始化：在客户端和服务器之间协商传输信息（例如，端口号、传输协议）。
URI: A Universal Resource Identifier; see [RFC3986]. The URIs used in RTSP are generally URLs as they give a location for the resource. As URLs are a subset of URIs, they will be referred to as URIs to cover also the cases when an RTSP URI would not be a URL.
URI：通用资源标识符；参见[RFC3986]。RTSP中使用的URI通常是URL，因为它们提供了资源的位置。由于URL是URI的一个子集，它们将被称为URI，以涵盖RTSP URI不是URL的情况。
URL: A Universal Resource Locator is a URI that identifies the resource through its primary access mechanism rather than identifying the resource by name or by some other attribute(s) of that resource.
URL：通用资源定位器是通过其主要访问机制标识资源的URI，而不是通过名称或该资源的其他属性标识资源。
This specification defines version 2.0 of RTSP.
本规范定义了RTSP的2.0版。
RTSP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further RTSP communication rather than the features obtained via that communication. No change is made to the version number for the addition of message components that do not affect communication behavior or that only add to extensible field values.
RTSP使用“<major><minor>”编号方案来表示协议的版本。协议版本控制策略旨在允许发送方指示消息的格式及其理解进一步RTSP通信的能力，而不是通过该通信获得的功能。对于添加不影响通信行为或仅添加到可扩展字段值的消息组件，不更改版本号。
The <minor> number is incremented when the changes made to the protocol add features that do not change the general message parsing algorithm but that may add to the message semantics and imply additional capabilities of the sender. The <major> number is incremented when the format of a message within the protocol is changed. The version of an RTSP message is indicated by an RTSP-Version field in the first line of the message. Note that the major and minor numbers MUST be treated as separate integers and that each MAY be incremented higher than a single digit. Thus, RTSP/2.4 is a lower version than RTSP/2.13, which, in turn, is lower than RTSP/12.3. Leading zeros SHALL NOT be sent and MUST be ignored by recipients.
当对协议所做的更改添加的功能不改变一般消息解析算法，但可能会增加消息语义并暗示发送方的附加功能时，<minor>数字将增加。当协议内的消息格式发生更改时，<major>编号将增加。RTSP消息的版本由消息第一行中的RTSP版本字段指示。请注意，主要数字和次要数字必须视为单独的整数，并且每个数字的增量可能大于一个位数。因此，RTSP/2.4的版本低于RTSP/2.13，而RTSP/2.13又低于RTSP/12.3。不应发送前导零，收件人必须忽略前导零。
RTSP 2.0 defines and registers or updates three URI schemes "rtsp", "rtsps", and "rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0 and is defined here to register the URI scheme that was defined in RTSP 1.0. The "rtspu" scheme indicates unspecified transport of the RTSP messages over unreliable transport means (UDP in RTSP 1.0). An RTSP server MUST respond with an error code indicating the "rtspu" scheme is not implemented (501) to a request that carries a "rtspu" URI scheme.
RTSP 2.0定义并注册或更新三个URI方案“RTSP”、“RTSP”和“rtspu”。最后一个“rtspu”的用法在RTSP 2.0中未指定，这里定义它是为了注册RTSP 1.0中定义的URI方案。“rtspu”方案表示通过不可靠的传输方式（RTSP 1.0中的UDP）传输未指定的RTSP消息。RTSP服务器必须使用错误代码响应带有“rtspu”URI方案的请求，该错误代码指示未实现“rtspu”方案（501）。
The details of the syntax of "rtsp" and "rtsps" URIs have been changed from RTSP 1.0. These changes include the addition of:
“rtsp”和“rtsps”URI的语法细节已从rtsp 1.0更改。这些变化包括增加：
o Support for an IPv6 literal in the host part and future IP literals through a mechanism defined in [RFC3986].
o 通过[RFC3986]中定义的机制支持主机部分中的IPv6文本和未来的IP文本。
o A new relative format to use in the RTSP elements that is not required to start with "/".
o RTSP元素中使用的新相对格式，不需要以“/”开头。
Neither should have any significant impact on interoperability. If IPv6 literals are needed in the RTSP URI, then that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully IPv6 capable protocol. If an RTSP 1.0 client attempts to process the URI, the URI will not match the allowed syntax, it will be considered invalid, and processing will be stopped. This is clearly a failure to reach the resource; however, it is not a signification issue as RTSP 2.0 support was needed anyway in both server and client. Thus, failure will only occur in a later step when there is an RTSP version mismatch between client and server. The second change will only occur inside RTSP message headers, as the Request-URI must be an absolute URI. Thus, such usages will only occur after an agent has accepted and started processing RTSP 2.0 messages, and an agent using RTSP 1.0 only will not be required to parse such types of relative URIs.
两者都不应对互操作性产生重大影响。如果RTSP URI中需要IPv6文本，则RTSP服务器必须支持IPv6，并且RTSP 1.0不是完全支持IPv6的协议。如果RTSP 1.0客户端试图处理URI，则URI将与允许的语法不匹配，它将被视为无效，处理将停止。这显然是未能获得资源；然而，这并不是一个有意义的问题，因为服务器和客户端都需要RTSP 2.0支持。因此，只有在客户端和服务器之间存在RTSP版本不匹配的情况下，才会出现故障。第二个更改将只发生在RTSP消息头中，因为请求URI必须是绝对URI。因此，只有在代理接受并开始处理RTSP 2.0消息之后，才会出现这种用法，并且只使用RTSP 1.0的代理不需要解析这种类型的相对URI。
This specification also defines the format of RTSP IRIs [RFC3987] that can be used as RTSP resource identifiers and locators on web pages, user interfaces, on paper, etc. However, the RTSP request message format only allows usage of the absolute URI format. The RTSP IRI format MUST use the rules and transformation for IRIs to URIs, as defined in [RFC3987]. This allows a URI that matches the RTSP 2.0 specification, and so is suitable for use in a request, to be created from an RTSP IRI.
本规范还定义了RTSP IRIs[RFC3987]的格式，该格式可用作网页、用户界面、纸张等上的RTSP资源标识符和定位器。然而，RTSP请求消息格式仅允许使用绝对URI格式。RTSP IRI格式必须使用[RFC3987]中定义的IRI到URI的规则和转换。这允许从RTSP IRI创建与RTSP 2.0规范匹配的URI，因此适合在请求中使用。
The RTSP IRI and URI are both syntax restricted compared to the generic syntax defined in [RFC3986] and [RFC3987]:
与[RFC3986]和[RFC3987]中定义的通用语法相比，RTSP IRI和URI都受到语法限制：
o An absolute URI requires the authority part; i.e., a host identity MUST be provided.
o 绝对URI需要权限部分；i、 例如，必须提供主机标识。
o Parameters in the path element are prefixed with the reserved separator ";".
o path元素中的参数以保留分隔符“；”作为前缀。
The "scheme" and "host" parts of all URIs [RFC3986] and IRIs [RFC3987] are case insensitive. All other parts of RTSP URIs and IRIs are case sensitive, and they MUST NOT be case mapped.
所有URI[RFC3986]和IRIs[RFC3987]的“方案”和“主机”部分不区分大小写。RTSP URI和IRIs的所有其他部分都是区分大小写的，并且它们不能进行大小写映射。
The fragment identifier is used as defined in Sections 3.5 and 4.3 of [RFC3986], i.e., the fragment is to be stripped from the IRI by the requester and not included in the Request-URI. The user agent needs to interpret the value of the fragment based on the media type the request relates to; i.e., the media type indicated in Content-Type header in the response to a DESCRIBE request.
按照[RFC3986]第3.5节和第4.3节中的定义使用片段标识符，即请求者从IRI中剥离片段，而不包括在请求URI中。用户代理需要根据请求所涉及的媒体类型解释片段的值；i、 例如，在对描述请求的响应中，在内容类型头中指示的媒体类型。
The syntax of any URI query string is unspecified and responder (usually the server) specific. The query is, from the requester's perspective, an opaque string and needs to be handled as such.
任何URI查询字符串的语法都是未指定的，并且响应者（通常是服务器）是特定的。从请求者的角度来看，查询是一个不透明的字符串，因此需要进行处理。
Please note that relative URIs with queries are difficult to handle due to the relative URI handling rules of RFC 3986. Any change of the path element using a relative URI results in the stripping of the query, which means the relative part needs to contain the query.
请注意，由于RFC 3986的相对URI处理规则，带有查询的相对URI很难处理。使用相对URI对path元素的任何更改都会导致查询的剥离，这意味着相对部分需要包含查询。
The URI scheme "rtsp" requires that commands be issued via a reliable protocol (within the Internet, TCP), while the scheme "rtsps" identifies a reliable transport using secure transport (TLS [RFC5246]); see Section 19.
URI方案“rtsp”要求通过可靠协议（在互联网内，TCP）发出命令，而方案“rtsp”使用安全传输（TLS[RFC5246]）标识可靠传输；见第19节。
For the scheme "rtsp", if no port number is provided in the authority part of the URI, the port number 554 MUST be used. For the scheme "rtsps", if no port number is provided in the authority part of the URI port number, the TCP port 322 MUST be used.
对于方案“rtsp”，如果URI的授权部分中没有提供端口号，则必须使用端口号554。对于方案“rtsps”，如果URI端口号的授权部分中没有提供端口号，则必须使用TCP端口322。
A presentation or a stream is identified by a textual media identifier, using the character set and escape conventions of URIs [RFC3986]. URIs may refer to a stream or an aggregate of streams; i.e., a presentation. Accordingly, requests described in Section 13 can apply to either the whole presentation or an individual stream within the presentation. Note that some request methods can only be applied to streams, not presentations, and vice versa.
表示或流由文本媒体标识符标识，使用URI的字符集和转义约定[RFC3986]。URI可指流或流的集合；i、 例如，介绍。因此，第13节中描述的请求可以应用于整个演示或演示中的单个流。请注意，某些请求方法只能应用于流，而不能应用于表示，反之亦然。
For example, the RTSP URI:
例如，RTSP URI：
rtsp://media.example.com:554/twister/audiotrack
rtsp://media.example.com:554/twister/audiotrack
may identify the audio stream within the presentation "twister", which can be controlled via RTSP requests issued over a TCP connection to port 554 of host media.example.com.
可以识别演示文稿“twister”中的音频流，该音频流可以通过TCP连接到host media.example.com的端口554发出的RTSP请求进行控制。
Also, the RTSP URI:
此外，RTSP URI：
rtsp://media.example.com:554/twister
rtsp://media.example.com:554/twister
identifies the presentation "twister", which may be composed of audio and video streams, but could also be something else, such as a random media redirector.
标识演示文稿“twister”，它可能由音频和视频流组成，但也可能是其他内容，例如随机媒体重定向器。
This does not imply a standard way to reference streams in URIs. The presentation description defines the hierarchical relationships in the presentation and the URIs for the individual streams. A presentation description may name a stream "a.mov" and the whole presentation "b.mov".
这并不意味着在URI中引用流的标准方法。表示描述定义了表示中的层次关系以及各个流的URI。演示文稿描述可以将流命名为“A.mov”，将整个演示文稿命名为“b.mov”。
The path components of the RTSP URI are opaque to the client and do not imply any particular file system structure for the server.
RTSP URI的路径组件对客户端是不透明的，并不意味着服务器有任何特定的文件系统结构。
This decoupling also allows presentation descriptions to be used with non-RTSP media control protocols simply by replacing the scheme in the URI.
这种解耦还允许通过替换URI中的方案，将表示描述与非RTSP媒体控制协议一起使用。
Session identifiers are strings of a length between 8-128 characters. A session identifier MUST be generated using methods that make it cryptographically random (see [RFC4086]). It is RECOMMENDED that a session identifier contain 128 bits of entropy, i.e., approximately 22 characters from a high-quality generator (see Section 21). However, note that the session identifier does not provide any security against session hijacking unless it is kept confidential by the client, server, and trusted proxies.
会话标识符是长度在8-128个字符之间的字符串。必须使用加密随机的方法生成会话标识符（请参见[RFC4086]）。建议会话标识符包含128位熵，即来自高质量生成器的大约22个字符（参见第21节）。但是，请注意，会话标识符不提供任何防止会话劫持的安全性，除非客户端、服务器和受信任的代理对其保密。
RTSP currently supports three different media-time formats defined below. Additional time formats may be specified in the future. These time formats can be used with the Range header (Section 18.40) to request playback and specify at which media position protocol requests actually will or have taken place. They are also used in description of the media's properties using the Media-Range header (Section 18.30). The unqualified format identifier is used on its own in Accept-Ranges header (Section 18.5) to declare supported time formats and also in the Range header (Section 18.40) to request the time format used in the response.
RTSP目前支持下面定义的三种不同的媒体时间格式。将来可能会指定其他时间格式。这些时间格式可与范围标头（第18.40节）一起使用，以请求播放，并指定媒体位置协议请求实际将或已经发生的位置。它们还用于使用介质范围标题描述介质属性（第18.30节）。不合格格式标识符在Accept Ranges标头（第18.5节）中单独用于声明支持的时间格式，在Range标头（第18.40节）中也用于请求响应中使用的时间格式。
A timestamp may use a format derived from a Society of Motion Picture and Television Engineers (SMPTE) specification and expresses time offsets anchored at the start of the media clip. Relative timestamps are expressed as SMPTE time codes [SMPTE-TC] for frame-level access accuracy. The time code has the format:
时间戳可以使用源自电影和电视工程师协会（SMPTE）规范的格式，并表示锚定在媒体剪辑开始处的时间偏移。相对时间戳表示为SMPTE时间码[SMPTE-TC]，用于帧级访问精度。时间代码的格式为：
hours:minutes:seconds:frames.subframes
hours:minutes:seconds:frames.subframes
with the origin at the start of the clip. The default SMPTE format is "SMPTE 30 drop" format, with a frame rate of 29.97 frames per second. Other SMPTE codes MAY be supported (such as "SMPTE 25") through the use of "smpte-type". For SMPTE 30, the "frames" field in the time value can assume the values 0 through 29. The difference between 30 and 29.97 frames per second is handled by dropping the first two frame indices (values 00 and 01) of every minute, except every tenth minute. If the frame and the subframe values are zero, they may be omitted. Subframes are measured in hundredths of a frame.
原点位于剪辑的开始处。默认SMPTE格式为“SMPTE 30 drop”格式，帧速率为每秒29.97帧。通过使用“SMPTE类型”，可以支持其他SMPTE代码（例如“SMPTE 25”）。对于SMPTE 30，时间值中的“帧”字段可以假定值0到29。每秒30帧和29.97帧之间的差异是通过每分钟（每十分钟除外）删除前两个帧索引（值00和01）来处理的。如果帧和子帧值为零，则可以省略它们。子帧是以帧的百分之一来度量的。
Examples:
示例：
smpte=10:12:33:20-
smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01
smpte=10:12:33:20-
smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01
Normal Play Time (NPT) indicates the stream-absolute position relative to the beginning of the presentation. The timestamp consists of two parts: The mandatory first part may be expressed in either seconds only or in hours, minutes, and seconds. The optional second part consists of a decimal point and decimal figures and indicates fractions of a second.
正常播放时间（NPT）表示相对于演示开始的流绝对位置。时间戳由两部分组成：强制的第一部分可以仅以秒表示，也可以以小时、分钟和秒表示。可选的第二部分由小数点和十进制数字组成，表示秒的分数。
The beginning of a presentation corresponds to 0.0 seconds. Negative values are not defined.
演示文稿的开头对应于0.0秒。未定义负值。
The special constant "now" is defined as the current instant of a live event. It MAY only be used for live events and MUST NOT be used for on-demand (i.e., non-live) content.
特殊常量“now”定义为实时事件的当前瞬间。它只能用于现场活动，不得用于点播（即非现场）内容。
NPT is defined as in Digital Storage Media Command and Control (DSMb;CC) [ISO.13818-6.1995]:
NPT定义为数字存储介质命令和控制（DSMb；CC）[ISO.13818-6.1995]：
Intuitively, NPT is the clock the viewer associates with a program. It is often digitally displayed on a DVD player. NPT advances normally when in normal play mode (scale = 1), advances at a faster rate when in fast-scan forward (high positive scale ratio), decrements when in scan reverse (negative scale ratio) and is fixed in pause mode. NPT is (logically) equivalent to SMPTE time codes.
直观地说，NPT是查看器与程序关联的时钟。它通常以数字方式显示在DVD播放机上。NPT在正常播放模式（刻度=1）下正常前进，在快速向前扫描（高正刻度比）下以更快的速度前进，在反向扫描（负刻度比）下递减，并在暂停模式下固定。NPT（逻辑上）等同于SMPTE时间代码。
Examples:
示例：
npt=123.45-125
npt=12:05:35.3-
npt=now-
npt=123.45-125
npt=12:05:35.3-
npt=now-
The syntax is based on ISO 8601 [ISO.8601.2000] and expresses the time elapsed since presentation start, with two different notations allowed:
语法基于ISO 8601[ISO.8601.2000]，表示自演示开始以来经过的时间，允许使用两种不同的符号：
o The npt-hhmmss notation uses an ISO 8601 extended complete representation of the time of the day format (Section 5.3.1.1 of [ISO.8601.2000] ) using colons (":") as separators between hours, minutes, and seconds (hh:mm:ss). The hour counter is not limited to 0-24 hours; up to nineteen (19) hour digits are allowed.
o npt hhmmss表示法使用ISO 8601扩展完整的时间表示格式（ISO.8601.2000第5.3.1.1节），使用冒号（：）作为小时、分钟和秒（hh:mm:ss）之间的分隔符。计时器不限于0-24小时；最多允许十九（19）个小时数字。
* In accordance with the requirements of the ISO 8601 time format, the hours, minutes, and seconds MUST all be present, with two digits used for minutes and for seconds and with at least two digits for hours. An NPT of 7 minutes and 0 seconds is represented as "00:07:00", and an NPT of 392 hours, 0 minutes, and 6 seconds is represented as "392:00:06".
* 根据ISO 8601时间格式的要求，小时、分钟和秒必须全部存在，两位数字分别表示分钟和秒，至少两位数字表示小时。7分0秒的NPT表示为“00:07:00”，392小时0分6秒的NPT表示为“392:00:06”。
* RTSP 1.0 allowed NPT in the npt-hhmmss notation without any leading zeros to ensure that implementations don't fail; for backward compatibility, all RTSP 2.0 implementations are REQUIRED to support receiving NPT values, hours, minutes, or seconds, without leading zeros.
* RTSP 1.0允许NPT hhmmss表示法中的NPT没有任何前导零，以确保实现不会失败；为了向后兼容，所有RTSP 2.0实现都需要支持接收NPT值、小时、分钟或秒，而无前导零。
o The npt-sec notation expresses the time in seconds, using between one and nineteen (19) digits.
o npt sec表示法以秒为单位表示时间，使用一到十九（19）位数字。
Both notations allow decimal fractions of seconds as specified in Section 5.3.1.3 of [ISO.8601.2000], using at most nine digits, and allowing only "." (full stop) as the decimal separator.
按照[ISO.8601.2000]第5.3.1.3节的规定，这两种符号都允许秒的小数部分，最多使用九位数字，并且只允许“.”（句号）作为十进制分隔符。
The npt-sec notation is optimized for automatic generation; the npt-hhmmss notation is optimized for consumption by human readers. The "now" constant allows clients to request to receive the live feed rather than the stored or time-delayed version. This is needed since neither absolute time nor zero time are appropriate for this case.
npt sec符号为自动生成而优化；npt hhmmss符号针对人类读者的消费进行了优化。“now”常量允许客户端请求接收实时提要，而不是存储或延迟的版本。这是必要的，因为绝对时间和零时间都不适合这种情况。
Absolute time is expressed using a timestamp based on ISO 8601 [ISO.8601.2000]. The date is a complete representation of the calendar date in basic format (YYYYMMDD) without separators (per Section 5.2.1.1 of [ISO.8601.2000]). The time of day is provided in the complete representation basic format (hhmmss) as specified in Section 5.3.1.1 of [ISO.8601.2000], allowing decimal fractions of seconds following Section 5.3.1.3 requiring "." (full stop) as decimal separator and limiting the number of digits to no more than nine. The time expressed MUST use UTC (GMT), i.e., no time zone offsets are allowed. The full date and time specification is the
绝对时间使用基于ISO 8601[ISO.8601.2000]的时间戳表示。日期以基本格式（YYYYMMDD）完整表示日历日期，不带分隔符（根据[ISO.8601.2000]第5.2.1.1节）。按照[ISO.8601.2000]第5.3.1.1节的规定，以完整表示基本格式（hhmmss）提供一天中的时间，允许在第5.3.1.3节之后以秒为小数点，要求“.”（句号）作为十进制分隔符，并将位数限制在不超过9位。表示的时间必须使用UTC（GMT），即不允许时区偏移。完整的日期和时间规范如下所示
eight-digit date followed by a "T" followed by the six-digit time value, optionally followed by a full stop followed by one to nine fractions of a second and ended by "Z", e.g., YYYYMMDDThhmmss.ssZ.
八位日期，后跟一个“T”，后跟六位时间值，可选择后跟一个句号，后跟一到九分之一秒，以“Z”结尾，例如YYYYMMDDThhmmss.ssZ。
The reasons for this time format rather than using "Date and Time on the Internet: Timestamps" [RFC3339] are historic. We continue to use the format specified in RTSP 1.0. The motivations raised in RFC 3339 apply to why a selection from ISO 8601 was made; however, a different and even more restrictive selection was applied in this case.
使用这种时间格式而不是使用“互联网上的日期和时间：时间戳”[RFC3339]的原因是历史性的。我们继续使用RTSP 1.0中指定的格式。RFC 3339中提出的动机适用于为什么选择ISO 8601；然而，在这种情况下，采用了一种不同的、甚至更严格的选择。
Below are three examples of media time formats, first, a request for a clock format range request for a starting time of November 8, 1996 at 14 h 37 min and 20 1/4 seconds UTC playing for 10 min and 5 seconds, followed by a Media-Properties header's "Time-Limited" UTC property for the 24th of December 2014 at 15 hours and 00 minutes, and finally a Terminate-Reason header "time" property for the 18th of June 2013 at 16 hours, 12 minutes, and 56 seconds:
以下是媒体时间格式的三个示例，首先，请求时钟格式范围请求，开始时间为1996年11月8日，UTC时间为14小时37分20 1/4秒，播放时间为10分钟5秒，然后是2014年12月24日15小时00分媒体属性标题的“限时”UTC属性，最后是2013年6月18日16小时12分56秒的终止原因标题“时间”属性：
clock=19961108T143720.25Z-19961108T144725.25Z Time-Limited=20141224T1500Z time=20130618T161256Z
时钟=19961108T143720.25Z-19961108T144725.25Z时间限制=20141224T1500Z时间=20130618T161256Z
Feature tags are unique identifiers used to designate features in RTSP. These tags are used in Require (Section 18.43), Proxy-Require (Section 18.37), Proxy-Supported (Section 18.38), Supported (Section 18.51), and Unsupported (Section 18.55) header fields.
特征标记是用于在RTSP中指定特征的唯一标识符。这些标签用于Require（第18.43节）、Proxy Require（第18.37节）、Proxy Supported（第18.38节）、Supported（第18.51节）和Unsupported（第18.55节）标题字段。
A feature tag definition MUST indicate which combination of clients, servers, or proxies to which it applies.
功能标记定义必须指明其应用于哪个客户端、服务器或代理组合。
The creator of a new RTSP feature tag should either prefix the feature tag with a reverse domain name (e.g., "com.example.mynewfeature" is an apt name for a feature whose inventor can be reached at "example.com") or register the new feature tag with the Internet Assigned Numbers Authority (IANA). (See Section 22, "IANA Considerations".)
新RTSP功能标签的创建者应在功能标签前面加上反向域名（例如，“com.example.mynewfeature”是一个合适的名称，其发明者可以通过“example.com”联系到该功能），或者向互联网分配号码管理局（IANA）注册新功能标签。（参见第22节“IANA注意事项”。）
The usage of feature tags is further described in Section 11, which deals with capability handling.
功能标签的使用在第11节中作了进一步描述，该节涉及功能处理。
Message body tags are opaque strings that are used to compare two message bodies from the same resource, for example, in caches or to optimize setup after a redirect. Message body tags can be carried in the MTag header (see Section 18.31) or in SDP (see Appendix D.1.9). MTag is similar to ETag in HTTP/1.1 (see Section 3.11 of [RFC2068]).
消息正文标记是不透明字符串，用于比较来自同一资源的两个消息正文，例如，在缓存中，或在重定向后优化设置。邮件正文标签可在MTag标题（见第18.31节）或SDP（见附录D.1.9）中携带。MTag类似于HTTP/1.1中的ETag（参见[RFC2068]的第3.11节）。
A message body tag MUST be unique across all versions of all message bodies associated with a particular resource. A given message body tag value MAY be used for message bodies obtained by requests on different URIs. The use of the same message body tag value in conjunction with message bodies obtained by requests on different URIs does not imply the equivalence of those message bodies.
消息正文标记在与特定资源关联的所有消息正文的所有版本中必须是唯一的。给定的消息正文标记值可用于由不同URI上的请求获得的消息正文。将相同的消息体标记值与通过不同URI上的请求获得的消息体结合使用并不意味着这些消息体是等价的。
Message body tags are used in RTSP to make some methods conditional. The methods are made conditional through the inclusion of headers; see Section 18.24 and Section 18.26 for information on the If-Match and If-None-Match headers, respectively. Note that RTSP message body tags apply to the complete presentation, i.e., both the presentation description and the individual media streams. Thus, message body tags can be used to verify at setup time after a redirect that the same session description applies to the media at the new location using the If-Match header.
RTSP中使用消息体标记使某些方法具有条件。这些方法通过包含头来实现条件化；关于If-Match和If-None-Match标题的信息，请分别参见第18.24节和第18.26节。请注意，RTSP消息正文标记适用于完整的演示文稿，即演示文稿描述和单个媒体流。因此，在重定向之后，可以使用消息正文标记在设置时使用If-Match报头验证相同的会话描述是否适用于新位置的媒体。
When an RTSP server handles media, it is important to consider the different properties a media instance for delivery and playback can have. This specification considers the media properties listed below in its protocol operations. They are derived from the differences between a number of supported usages.
当RTSP服务器处理媒体时，重要的是考虑媒体实例的不同属性，以便传递和回放。本规范在其协议操作中考虑以下列出的媒体属性。它们来源于许多受支持的用法之间的差异。
On-demand: Media that has a fixed (given) duration that doesn't change during the lifetime of the RTSP session and is known at the time of the creation of the session. It is expected that the content of the media will not change, even if the representation, such as encoding, or quality, may change. Generally, one can seek, i.e., request any range, within the media.
按需：具有固定（给定）持续时间的媒体，在RTSP会话的生存期内不会更改，并且在创建会话时已知。即使表示（例如编码或质量）可能改变，也期望媒体的内容不会改变。通常，人们可以在媒体中搜索，即请求任何范围。
Dynamic On-demand: This is a variation of the on-demand case where external methods are used to manipulate the actual content of the media setup for the RTSP session. The main example is content defined by a playlist.
动态按需：这是按需情况的一种变体，使用外部方法操作RTSP会话的媒体设置的实际内容。主要示例是由播放列表定义的内容。
Live: Live media represents a progressing content stream (such as broadcast TV) where the duration may or may not be known. It is not seekable, only the content presently being delivered can be accessed.
直播：直播媒体代表一个持续时间未知或未知的内容流（如广播电视）。它是不可查找的，只能访问当前正在交付的内容。
Live with Recording: A live stream that is combined with a server-side capability to store and retain the content of the live session and allow for random access delivery within the part of the already-recorded content. The actual behavior of the media stream is very much dependent on the retention policy for the media stream; either the server will be able to capture the complete media stream or it will have a limitation in how much will be retained. The media range will dynamically change as the session progress. For servers with a limited amount of storage available for recording, there will typically be a sliding window that moves forward while new data is made available and older data is discarded.
Live with Recording：与服务器端功能相结合的实时流，用于存储和保留实时会话的内容，并允许在已录制内容的部分内进行随机访问传递。媒体流的实际行为在很大程度上取决于媒体流的保留策略；服务器将能够捕获完整的媒体流，或者对保留的数量有限制。媒体范围将随着会话的进行而动态变化。对于可用于录制的存储空间有限的服务器，通常会有一个滑动窗口，在新数据可用且旧数据被丢弃时向前移动。
To cover the above usages, the following media properties with appropriate values are specified.
为了涵盖上述用途，指定了以下具有适当值的介质属性。
Random access is the ability to specify and get media delivered starting from any time (instant) within the content, an operation called "seeking". The Media-Properties header will indicate the general capability for a media resource to perform random access.
随机访问是指从内容中的任何时间（瞬间）开始指定和获取媒体交付的能力，这种操作称为“查找”。媒体属性标头将指示媒体资源执行随机访问的一般能力。
Random-Access: The media is seekable to any out of a large number of points within the media. Due to media-encoding limitations, a particular point may not be reachable, but seeking to a point close by is enabled. A floating-point number of seconds may be provided to express the worst-case distance between random access points.
随机访问：可以在媒体中的大量点中查找媒体。由于媒体编码的限制，特定点可能无法到达，但已启用查找附近的点。可以提供浮点秒数来表示随机接入点之间的最坏情况距离。
Beginning-Only: Seeking is only possible to the beginning of the content.
仅开始：仅可在内容的开始处搜索。
No-Seeking: Seeking is not possible at all.
不寻求：寻求根本不可能。
If random access is possible, as indicated by the Media-Properties header, the actual behavior policy when seeking can be controlled using the Seek-Style header (Section 18.47).
如媒体属性标题所示，如果可以进行随机访问，则可使用Seek样式标题控制查找时的实际行为策略（第18.47节）。
The following retention policies are used by media to limit possible protocol operations:
介质使用以下保留策略来限制可能的协议操作：
Unlimited: The media will not be removed as long as the RTSP session is in existence.
无限：只要RTSP会话存在，就不会删除介质。
Time-Limited: The media will not be removed before the given wallclock time. After that time, it may or may not be available anymore.
时间限制：在给定的挂钟时间之前，不会取出介质。在那之后，它可能会，也可能不再可用。
Time-Duration: The media (on fragment or unit basis) will be retained for the specified duration.
持续时间：介质（以片段或单位为单位）将保留指定的持续时间。
The media content and its timeline can be of different types, e.g. pre-produced content on demand, a live source that is being generated as time progresses, or something that is dynamically altered or recomposed during playback. Therefore, a media property for content modifications is needed and the following initial values are defined:
媒体内容及其时间线可以是不同的类型，例如，按需预制作的内容、随时间推移生成的实时源，或者在播放过程中动态更改或重新组合的内容。因此，需要用于内容修改的媒体属性，并定义以下初始值：
Immutable: The content of the media will not change, even if the representation, such as encoding or quality changes.
不变：即使表示（如编码或质量）发生更改，媒体内容也不会更改。
Dynamic: The content can change due to external methods or triggers, such as playlists, but this will be announced by explicit updates.
动态：内容可能会因外部方法或触发器（如播放列表）而更改，但这将通过显式更新来宣布。
Time-Progressing: As time progresses, new content will become available. If the content is also retained, it will become longer as everything between the start point and the point currently being made available can be accessed. If the media server uses a sliding-window policy for retention, the start point will also change as time progresses.
时间进度：随着时间的推移，新内容将变得可用。如果内容也被保留，它将变得更长，因为可以访问起点和当前可用点之间的所有内容。如果媒体服务器使用滑动窗口策略进行保留，则起始点也会随着时间的推移而改变。
A particular media content item often supports only a limited set or range of scales when delivering the media. To enable the client to know what values or ranges of scale operations that the whole content or the current position supports, a media properties attribute for this is defined that contains a list with the values or ranges that are supported. The attribute is named "Scales". The "Scales" attribute may be updated at any point in the content due to content consisting of spliced pieces or content being dynamically updated by out-of-band mechanisms.
在交付媒体时，特定媒体内容项通常仅支持有限的一组或一系列缩放。为了使客户端能够了解整个内容或当前位置支持的缩放操作的值或范围，定义了一个包含支持的值或范围列表的媒体属性属性。该属性名为“Scales”。由于由拼接片段组成的内容或由带外机制动态更新的内容，可以在内容中的任何点更新“缩放”属性。
This section shows examples of how one would map the above usages to the properties and their values.
本节展示了如何将上述用法映射到属性及其值的示例。
Example of On-Demand: Random Access: Random-Access=5.0, Content Modifications: Immutable, Retention: Unlimited or Time-Limited.
随需应变示例：随机访问：随机访问=5.0，内容修改：不可变，保留：无限制或有时间限制。
Example of Dynamic On-Demand: Random Access: Random-Access=3.0, Content Modifications: Dynamic, Retention: Unlimited or Time-Limited.
动态随需应变示例：随机访问：随机访问=3.0，内容修改：动态，保留：无限制或有时间限制。
Example of Live:
Random Access: No-Seeking, Content Modifications: Time-
Progressing, Retention: Time-Duration=0.0
Example of Live:
Random Access: No-Seeking, Content Modifications: Time-
Progressing, Retention: Time-Duration=0.0
Example of Live with Recording:
Random Access: Random-Access=3.0, Content Modifications: Time-
Progressing, Retention: Time-Duration=7200.0
Example of Live with Recording:
Random Access: Random-Access=3.0, Content Modifications: Time-
Progressing, Retention: Time-Duration=7200.0
RTSP is a text-based protocol that uses the ISO 10646 character set in UTF-8 encoding per RFC 3629 [RFC3629]. Lines MUST be terminated by a CRLF.
RTSP是一种基于文本的协议，根据RFC 3629[RFC3629]使用UTF-8编码的ISO 10646字符集。行必须由CRLF终止。
Text-based protocols make it easier to add optional parameters in a self-describing manner. Since the number of parameters and the frequency of commands is low, processing efficiency is not a concern. Text-based protocols, if used carefully, also allow easy implementation of research prototypes in scripting languages such as Python, PHP, Perl and TCL.
基于文本的协议使以自描述方式添加可选参数变得更容易。由于参数数量和命令频率较低，因此处理效率不受关注。如果仔细使用基于文本的协议，还可以使用Python、PHP、Perl和TCL等脚本语言轻松实现研究原型。
The ISO 10646 character set avoids character-set switching, but is invisible to the application as long as US-ASCII is being used. This is also the encoding used for text fields in RTCP [RFC3550].
ISO10646字符集避免了字符集切换，但只要使用US-ASCII，应用程序就看不到该字符集。这也是RTCP[RFC3550]中用于文本字段的编码。
A request contains a method, the object the method is operating upon, and parameters to further describe the method. Methods are idempotent unless otherwise noted. Methods are also designed to require little or no state maintenance at the media server.
请求包含一个方法、该方法所操作的对象以及进一步描述该方法的参数。方法是幂等的，除非另有说明。方法还被设计为只需要很少或不需要在媒体服务器上进行状态维护。
RTSP messages are either requests from client to server or from server to client, and responses in the reverse direction. Request (Section 7) and response (Section 8) messages use a format based on the generic message format of RFC 5322 [RFC5322] for transferring bodies (the payload of the message). Both types of messages consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the headers, and possibly the data of the message body. The ABNF [RFC5234] below is for illustration only; the formal message specification is presented in Section 20.2.2.
RTSP消息是从客户端到服务器或从服务器到客户端的请求，以及反向的响应。请求（第7节）和响应（第8节）消息使用基于RFC 5322[RFC5322]的通用消息格式的格式传输实体（消息的有效负载）。这两种类型的消息都由起始行、零个或多个标头字段（也称为“标头”）、指示标头结束的空行（即，在CRLF之前没有任何内容的行）以及可能的消息正文数据组成。下面的ABNF[RFC5234]仅用于说明；正式消息规范见第20.2.2节。
generic-message = start-line *(rtsp-header CRLF) CRLF [ message-body-data ] start-line = Request-Line / Status-Line
通用消息=起始行*（rtsp标头CRLF）CRLF[消息正文数据]起始行=请求行/状态行
In the interest of robustness, agents MUST ignore any empty line(s) received where a Request-Line or Status-Line is expected. In other words, if the agent is reading the protocol stream at the beginning of a message and receives any number of CRLFs first, it MUST ignore all of the CRLFs.
为了保证健壮性，代理必须忽略接收到的任何空行，其中需要请求行或状态行。换句话说，如果代理在消息开头读取协议流并首先接收任意数量的CRLF，那么它必须忽略所有CRLF。
RTSP header fields (see Section 18) include general-header, request-header, response-header, and message body header fields.
RTSP头字段（见第18节）包括常规头、请求头、响应头和消息正文头字段。
The order in which header fields with differing field names are received is not significant. However, it is "good practice" to send general-header fields first, followed by a request-header or response-header field, and ending with the message body header fields.
接收具有不同字段名的标题字段的顺序并不重要。不过，最好先发送常规头字段，然后发送请求头或响应头字段，最后发送消息体头字段。
Multiple header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value; thus, a proxy MUST NOT change the order of these field-values when a message is forwarded.
当且仅当消息头字段的整个字段值定义为逗号分隔列表时，消息中可能存在具有相同字段名的多个标题字段。必须能够将多个标题字段合并为一个“字段名称：字段值”对，而不改变消息的语义，方法是将每个后续字段值附加到第一个字段值，每个字段值用逗号分隔。因此，具有相同字段名称的标题字段的接收顺序对于组合字段值的解释非常重要；因此，在转发消息时，代理不得更改这些字段值的顺序。
Unknown message headers MUST be ignored (skipping over the header to the next protocol element, and not causing an error) by an RTSP server or client. An RTSP proxy MUST forward unknown message headers. Message headers defined outside of this specification that are required to be interpreted by the RTSP agent will need to use feature tags (Section 4.5) and include them in the appropriate Require (Section 18.43) or Proxy-Require (Section 18.37) header.
RTSP服务器或客户端必须忽略未知消息头（跳过该头到下一个协议元素，并且不会导致错误）。RTSP代理必须转发未知的消息头。本规范之外定义的需要RTSP代理解释的消息头需要使用功能标签（第4.5节），并将其包含在适当的Require（第18.43节）或Proxy Require（第18.37节）头中。
The message body (if any) of an RTSP message is used to carry further information for a particular resource associated with the request or response. An example of a message body is an SDP message.
RTSP消息的消息体（如果有）用于承载与请求或响应相关联的特定资源的进一步信息。消息正文的一个示例是SDP消息。
The presence of a message body in either a request or a response MUST be signaled by the inclusion of a Content-Length header (see Section 18.17) and Content-Type header (see Section 18.19). A message body MUST NOT be included in a request or response if the specification of the particular method (see Method Definitions (Section 13)) does not allow sending a message body. In case a message body is received in a message when not expected, the message body data SHOULD be discarded. This is to allow future extensions to define optional use of a message body.
请求或响应中的消息正文必须通过包含内容长度头（见第18.17节）和内容类型头（见第18.19节）来表示。如果特定方法的规范（参见方法定义（第13节））不允许发送消息体，则请求或响应中不得包含消息体。如果在非预期的情况下在消息中接收到消息正文，则应丢弃消息正文数据。这是为了允许将来的扩展定义消息体的可选使用。
An RTSP message that does not contain any message body is terminated by the first empty line after the header fields (note: an empty line is a line with nothing preceding the CRLF.). In RTSP messages that contain message bodies, the empty line is followed by the message body. The length of that body is determined by the value of the Content-Length header (Section 18.17). The value in the header represents the length of the message body in octets. If this header field is not present, a value of zero is assumed, i.e., no message body present in the message. Unlike an HTTP message, an RTSP message MUST contain a Content-Length header whenever it contains a message body. Note that RTSP does not support the HTTP/1.1 "chunked" transfer coding (see Section 4.1 of [RFC7230]).
不包含任何消息正文的RTSP消息由标题字段后的第一个空行终止（注意：空行是指CRLF前面没有任何内容的行）。在包含消息正文的RTSP消息中，空行后跟消息正文。正文的长度由内容长度标题的值决定（第18.17节）。标头中的值表示消息正文的长度（以八位字节为单位）。如果此标头字段不存在，则假定值为零，即消息中不存在消息正文。与HTTP消息不同，RTSP消息在包含消息正文时必须包含内容长度头。注意，RTSP不支持HTTP/1.1“分块”传输编码（见[RFC7230]第4.1节）。
Given the moderate length of presentation descriptions returned, the server should always be able to determine its length, even if it is generated dynamically, making the chunked transfer encoding unnecessary.
给定返回的表示描述的中等长度，服务器应该始终能够确定其长度，即使它是动态生成的，这使得分块传输编码变得不必要。
General headers are headers that may be used in both requests and responses. The general-headers are listed in Table 1:
常规标头是可以在请求和响应中使用的标头。表1列出了一般标题：
+--------------------+----------------+
| Header Name | Defined in |
+--------------------+----------------+
| Accept-Ranges | Section 18.5 |
| | |
| Cache-Control | Section 18.11 |
| | |
| Connection | Section 18.12 |
| | |
| CSeq | Section 18.20 |
| | |
| Date | Section 18.21 |
| | |
| Media-Properties | Section 18.29 |
| | |
| Media-Range | Section 18.30 |
| | |
| Pipelined-Requests | Section 18.33 |
| | |
| Proxy-Supported | Section 18.38 |
| | |
| Range | Section 18.40 |
| | |
| RTP-Info | Section 18.45 |
| | |
| Scale | Section 18.46 |
| | |
| Seek-Style | Section 18.47 |
| | |
| Server | Section 18.48 |
| | |
| Session | Section 18.49 |
| | |
| Speed | Section 18.50 |
| | |
| Supported | Section 18.51 |
| | |
| Timestamp | Section 18.53 |
| | |
| Transport | Section 18.54 |
| | |
| User-Agent | Section 18.56 |
| | |
| Via | Section 18.57 |
+--------------------+----------------+
+--------------------+----------------+
| Header Name | Defined in |
+--------------------+----------------+
| Accept-Ranges | Section 18.5 |
| | |
| Cache-Control | Section 18.11 |
| | |
| Connection | Section 18.12 |
| | |
| CSeq | Section 18.20 |
| | |
| Date | Section 18.21 |
| | |
| Media-Properties | Section 18.29 |
| | |
| Media-Range | Section 18.30 |
| | |
| Pipelined-Requests | Section 18.33 |
| | |
| Proxy-Supported | Section 18.38 |
| | |
| Range | Section 18.40 |
| | |
| RTP-Info | Section 18.45 |
| | |
| Scale | Section 18.46 |
| | |
| Seek-Style | Section 18.47 |
| | |
| Server | Section 18.48 |
| | |
| Session | Section 18.49 |
| | |
| Speed | Section 18.50 |
| | |
| Supported | Section 18.51 |
| | |
| Timestamp | Section 18.53 |
| | |
| Transport | Section 18.54 |
| | |
| User-Agent | Section 18.56 |
| | |
| Via | Section 18.57 |
+--------------------+----------------+
Table 1: The General Headers Used in RTSP
表1:RTSP中使用的常规标头
A request message uses the format outlined below regardless of the direction of a request, whether client to server or server to client:
无论请求的方向是客户端到服务器还是服务器到客户端，请求消息都使用下面概述的格式：
o Request line, containing the method to be applied to the resource, the identifier of the resource, and the protocol version in use;
o 请求行，包含要应用于资源的方法、资源的标识符和正在使用的协议版本；
o Zero or more Header lines, which can be of the following types: general-headers (Section 6), request-headers (Section 7.2), or message body headers (Section 9.1);
o 零个或多个标题行，可以是以下类型：一般标题（第6节）、请求标题（第7.2节）或消息正文标题（第9.1节）；
o One empty line (CRLF) to indicate the end of the header section;
o 一条空行（CRLF）表示收割台部分的结束；
o Optionally, a message body, consisting of one or more lines. The length of the message body in octets is indicated by the Content-Length message header.
o （可选）消息正文，由一行或多行组成。消息正文的长度（以八位字节为单位）由内容长度消息头指示。
The request line provides the key information about the request: what method, on what resources, and using which RTSP version. The methods that are defined by this specification are listed in Table 2.
请求行提供有关请求的关键信息：什么方法、什么资源以及使用哪个RTSP版本。表2列出了本规范规定的方法。
+---------------+----------------+
| Method | Defined in |
+---------------+----------------+
| DESCRIBE | Section 13.2 |
| | |
| GET_PARAMETER | Section 13.8 |
| | |
| OPTIONS | Section 13.1 |
| | |
| PAUSE | Section 13.6 |
| | |
| PLAY | Section 13.4 |
| | |
| PLAY_NOTIFY | Section 13.5 |
| | |
| REDIRECT | Section 13.10 |
| | |
| SETUP | Section 13.3 |
| | |
| SET_PARAMETER | Section 13.9 |
| | |
| TEARDOWN | Section 13.7 |
+---------------+----------------+
+---------------+----------------+
| Method | Defined in |
+---------------+----------------+
| DESCRIBE | Section 13.2 |
| | |
| GET_PARAMETER | Section 13.8 |
| | |
| OPTIONS | Section 13.1 |
| | |
| PAUSE | Section 13.6 |
| | |
| PLAY | Section 13.4 |
| | |
| PLAY_NOTIFY | Section 13.5 |
| | |
| REDIRECT | Section 13.10 |
| | |
| SETUP | Section 13.3 |
| | |
| SET_PARAMETER | Section 13.9 |
| | |
| TEARDOWN | Section 13.7 |
+---------------+----------------+
Table 2: The RTSP Methods
表2：RTSP方法
The syntax of the RTSP request line has the following:
RTSP请求行的语法如下所示：
<Method> SP <Request-URI> SP <RTSP-Version> CRLF
<Method> SP <Request-URI> SP <RTSP-Version> CRLF
Note: This syntax cannot be freely changed in future versions of RTSP. This line needs to remain parsable by older RTSP implementations since it indicates the RTSP version of the message.
注意：此语法不能在RTSP的未来版本中自由更改。这一行需要由较旧的RTSP实现保持可解析性，因为它指示消息的RTSP版本。
In contrast to HTTP/1.1 [RFC7230], RTSP requests identify the resource through an absolute RTSP URI (including scheme, host, and port) (see Section 4.2) rather than just the absolute path.
与HTTP/1.1[RFC7230]不同，RTSP请求通过绝对RTSP URI（包括方案、主机和端口）（参见第4.2节）而不仅仅是绝对路径来标识资源。
HTTP/1.1 requires servers to understand the absolute URI, but clients are supposed to use the Host request-header. This is purely needed for backward compatibility with HTTP/1.0 servers, a consideration that does not apply to RTSP.
HTTP/1.1要求服务器理解绝对URI，但客户端应该使用主机请求头。这纯粹是为了与HTTP/1.0服务器向后兼容而需要的，这一点不适用于RTSP。
An asterisk "*" can be used instead of an absolute URI in the Request-URI part to indicate that the request does not apply to a particular resource but to the server or proxy itself, and is only allowed when the request method does not necessarily apply to a resource.
在请求URI部分中，可以使用星号“*”代替绝对URI，以指示请求不应用于特定资源，而是应用于服务器或代理本身，并且仅当请求方法不一定应用于资源时才允许。
For example:
例如：
OPTIONS * RTSP/2.0
选项*RTSP/2.0
An OPTIONS in this form will determine the capabilities of the server or the proxy that first receives the request. If the capability of the specific server needs to be determined, without regard to the capability of an intervening proxy, the server should be addressed explicitly with an absolute URI that contains the server's address.
此表单中的选项将确定首先接收请求的服务器或代理的功能。如果需要确定特定服务器的能力，而不考虑中间代理的能力，则应使用包含服务器地址的绝对URI显式寻址服务器。
For example:
例如：
OPTIONS rtsp://example.com RTSP/2.0
OPTIONS rtsp://example.com RTSP/2.0
The RTSP headers in Table 3 can be included in a request, as request-headers, to modify the specifics of the request.
表3中的RTSP头可以作为请求头包含在请求中，以修改请求的细节。
+---------------------+----------------+
| Header | Defined in |
+---------------------+----------------+
| Accept | Section 18.1 |
| | |
| Accept-Credentials | Section 18.2 |
| | |
| Accept-Encoding | Section 18.3 |
| | |
| Accept-Language | Section 18.4 |
| | |
| Authorization | Section 18.8 |
| | |
| Bandwidth | Section 18.9 |
| | |
| Blocksize | Section 18.10 |
| | |
| From | Section 18.23 |
| | |
| If-Match | Section 18.24 |
| | |
| If-Modified-Since | Section 18.25 |
| | |
| If-None-Match | Section 18.26 |
| | |
| Notify-Reason | Section 18.32 |
| | |
| Proxy-Authorization | Section 18.36 |
| | |
| Proxy-Require | Section 18.37 |
| | |
| Referrer | Section 18.41 |
| | |
| Request-Status | Section 18.42 |
| | |
| Require | Section 18.43 |
| | |
| Terminate-Reason | Section 18.52 |
+---------------------+----------------+
+---------------------+----------------+
| Header | Defined in |
+---------------------+----------------+
| Accept | Section 18.1 |
| | |
| Accept-Credentials | Section 18.2 |
| | |
| Accept-Encoding | Section 18.3 |
| | |
| Accept-Language | Section 18.4 |
| | |
| Authorization | Section 18.8 |
| | |
| Bandwidth | Section 18.9 |
| | |
| Blocksize | Section 18.10 |
| | |
| From | Section 18.23 |
| | |
| If-Match | Section 18.24 |
| | |
| If-Modified-Since | Section 18.25 |
| | |
| If-None-Match | Section 18.26 |
| | |
| Notify-Reason | Section 18.32 |
| | |
| Proxy-Authorization | Section 18.36 |
| | |
| Proxy-Require | Section 18.37 |
| | |
| Referrer | Section 18.41 |
| | |
| Request-Status | Section 18.42 |
| | |
| Require | Section 18.43 |
| | |
| Terminate-Reason | Section 18.52 |
+---------------------+----------------+
Table 3: The RTSP Request-Headers
表3:RTSP请求头
Detailed header definitions are provided in Section 18.
第18节提供了详细的标题定义。
New request-headers may be defined. If the receiver of the request is required to understand the request-header, the request MUST include a corresponding feature tag in a Require or Proxy-Require header to ensure the processing of the header.
可以定义新的请求头。如果请求的接收者需要理解请求标头，则请求必须在Require或Proxy Require标头中包含相应的功能标签，以确保标头的处理。
After receiving and interpreting a request message, the recipient responds with an RTSP response message. Normally, there is only one, final, response. Responses using the response code class 1xx is the only class for which there MAY be sent one or more responses prior to the final response message.
在接收并解释请求消息后，接收方将使用RTSP响应消息进行响应。通常，只有一个最终响应。使用响应代码类1xx的响应是在最终响应消息之前可以发送一个或多个响应的唯一类。
The valid response codes and the methods they can be used with are listed in Table 4.
表4列出了有效的响应代码及其可使用的方法。
The first line of a response message is the Status-Line, consisting of the protocol version followed by a numeric status code and the textual phrase associated with the status code, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
响应消息的第一行是状态行，由协议版本、数字状态代码和与状态代码关联的文本短语组成，每个元素由SP字符分隔。除最终CRLF序列外，不允许使用CR或LF。
<RTSP-Version> SP <Status-Code> SP <Reason Phrase> CRLF
<RTSP-Version> SP <Status-Code> SP <Reason Phrase> CRLF
The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes are fully defined in Section 17. The reason phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the reason phrase is intended for the human user. The client is not required to examine or display the reason phrase.
状态代码元素是试图理解和满足请求的3位整数结果代码。这些代码在第17节中有完整的定义。原因短语旨在对状态代码进行简短的文本描述。状态代码供自动机使用，原因短语供人类用户使用。客户端不需要检查或显示原因短语。
The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are five values for the first digit:
状态代码的第一位数字定义了响应的类别。最后两位数字没有任何分类角色。第一个数字有五个值：
1xx: Informational - Request received, continuing process
1xx：信息性-收到请求，继续处理
2xx: Success - The action was successfully received, understood, and accepted
2xx：成功-成功接收、理解和接受行动
3rr: Redirection - Further action needs to be taken in order to complete the request (3rr rather than 3xx is used as 304 is excluded; see Section 17.3)
3rr：重定向-需要采取进一步措施以完成请求（3rr而不是3xx被使用，因为304被排除在外；参见第17.3节）
4xx: Client Error - The request contains bad syntax or cannot be fulfilled
4xx:客户端错误-请求包含错误语法或无法实现
5xx: Server Error - The server failed to fulfill an apparently valid request
5xx:服务器错误-服务器未能完成明显有效的请求
The individual values of the numeric status codes defined for RTSP 2.0, and an example set of corresponding reason phrases, are presented in Table 4. The reason phrases listed here are only recommended; they may be replaced by local equivalents without affecting the protocol. Note that RTSP adopted most HTTP/1.1 [RFC2068] status codes and then added RTSP-specific status codes starting at x50 to avoid conflicts with future HTTP status codes that are desirable to import into RTSP. All these codes are RTSP specific and RTSP has its own registry separate from HTTP for status codes.
表4给出了为RTSP 2.0定义的数字状态代码的单个值以及相应原因短语的示例集。此处列出的原因短语仅供推荐；它们可以在不影响协议的情况下由本地等效物替换。请注意，RTSP采用了大多数HTTP/1.1[RFC2068]状态代码，然后从x50开始添加了RTSP特定的状态代码，以避免与将来需要导入RTSP的HTTP状态代码发生冲突。所有这些代码都是特定于RTSP的，RTSP有自己的注册表，与HTTP分开用于状态代码。
RTSP status codes are extensible. RTSP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with an exception for unknown 3xx codes, which MUST be treated as a 302 (Found). The reason for that exception is that the status code 300 (Multiple Choices in HTTP) is not defined for RTSP. A response with an unrecognized status code MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the message body returned with the response, since that message body is likely to include human-readable information that will explain the unusual status.
RTSP状态代码是可扩展的。RTSP应用程序不需要理解所有注册状态代码的含义，尽管这种理解显然是可取的。但是，应用程序必须理解任何状态代码的类别（如第一位数字所示），并将任何无法识别的响应视为等同于该类别的x00状态代码，未知3xx代码除外，该代码必须视为302（已找到）。该异常的原因是没有为RTSP定义状态代码300（HTTP中的多选）。不能缓存状态代码无法识别的响应。例如，如果客户端接收到无法识别的状态代码431，它可以安全地假设其请求有问题，并将响应视为收到400状态代码。在这种情况下，用户代理应该向用户呈现随响应返回的消息体，因为该消息体可能包括将解释异常状态的人类可读信息。
+------+---------------------------------+--------------------------+
| Code | Reason | Method |
+------+---------------------------------+--------------------------+
| 100 | Continue | all |
| | | |
| 200 | OK | all |
| | | |
| 301 | Moved Permanently | all |
| | | |
| 302 | Found | all |
| | | |
| 303 | See Other | n/a |
| | | |
| 304 | Not Modified | all |
| | | |
+------+---------------------------------+--------------------------+
| Code | Reason | Method |
+------+---------------------------------+--------------------------+
| 100 | Continue | all |
| | | |
| 200 | OK | all |
| | | |
| 301 | Moved Permanently | all |
| | | |
| 302 | Found | all |
| | | |
| 303 | See Other | n/a |
| | | |
| 304 | Not Modified | all |
| | | |
| 305 | Use Proxy | all |
| | | |
| 400 | Bad Request | all |
| | | |
| 401 | Unauthorized | all |
| | | |
| 402 | Payment Required | all |
| | | |
| 403 | Forbidden | all |
| | | |
| 404 | Not Found | all |
| | | |
| 405 | Method Not Allowed | all |
| | | |
| 406 | Not Acceptable | all |
| | | |
| 407 | Proxy Authentication Required | all |
| | | |
| 408 | Request Timeout | all |
| | | |
| 410 | Gone | all |
| | | |
| 412 | Precondition Failed | DESCRIBE, SETUP |
| | | |
| 413 | Request Message Body Too Large | all |
| | | |
| 414 | Request-URI Too Long | all |
| | | |
| 415 | Unsupported Media Type | all |
| | | |
| 451 | Parameter Not Understood | SET_PARAMETER, |
| | | GET_PARAMETER |
| | | |
| 452 | reserved | n/a |
| | | |
| 453 | Not Enough Bandwidth | SETUP |
| | | |
| 454 | Session Not Found | all |
| | | |
| 455 | Method Not Valid in This State | all |
| | | |
| 456 | Header Field Not Valid for | all |
| | Resource | |
| | | |
| 457 | Invalid Range | PLAY, PAUSE |
| | | |
| 458 | Parameter Is Read-Only | SET_PARAMETER |
| | | |
| 305 | Use Proxy | all |
| | | |
| 400 | Bad Request | all |
| | | |
| 401 | Unauthorized | all |
| | | |
| 402 | Payment Required | all |
| | | |
| 403 | Forbidden | all |
| | | |
| 404 | Not Found | all |
| | | |
| 405 | Method Not Allowed | all |
| | | |
| 406 | Not Acceptable | all |
| | | |
| 407 | Proxy Authentication Required | all |
| | | |
| 408 | Request Timeout | all |
| | | |
| 410 | Gone | all |
| | | |
| 412 | Precondition Failed | DESCRIBE, SETUP |
| | | |
| 413 | Request Message Body Too Large | all |
| | | |
| 414 | Request-URI Too Long | all |
| | | |
| 415 | Unsupported Media Type | all |
| | | |
| 451 | Parameter Not Understood | SET_PARAMETER, |
| | | GET_PARAMETER |
| | | |
| 452 | reserved | n/a |
| | | |
| 453 | Not Enough Bandwidth | SETUP |
| | | |
| 454 | Session Not Found | all |
| | | |
| 455 | Method Not Valid in This State | all |
| | | |
| 456 | Header Field Not Valid for | all |
| | Resource | |
| | | |
| 457 | Invalid Range | PLAY, PAUSE |
| | | |
| 458 | Parameter Is Read-Only | SET_PARAMETER |
| | | |
| 459 | Aggregate Operation Not Allowed | all |
| | | |
| 460 | Only Aggregate Operation | all |
| | Allowed | |
| | | |
| 461 | Unsupported Transport | all |
| | | |
| 462 | Destination Unreachable | all |
| | | |
| 463 | Destination Prohibited | SETUP |
| | | |
| 464 | Data Transport Not Ready Yet | PLAY |
| | | |
| 465 | Notification Reason Unknown | PLAY_NOTIFY |
| | | |
| 466 | Key Management Error | all |
| | | |
| 470 | Connection Authorization | all |
| | Required | |
| | | |
| 471 | Connection Credentials Not | all |
| | Accepted | |
| | | |
| 472 | Failure to Establish Secure | all |
| | Connection | |
| | | |
| 500 | Internal Server Error | all |
| | | |
| 501 | Not Implemented | all |
| | | |
| 502 | Bad Gateway | all |
| | | |
| 503 | Service Unavailable | all |
| | | |
| 504 | Gateway Timeout | all |
| | | |
| 505 | RTSP Version Not Supported | all |
| | | |
| 551 | Option Not Supported | all |
| | | |
| 553 | Proxy Unavailable | all |
+------+---------------------------------+--------------------------+
| 459 | Aggregate Operation Not Allowed | all |
| | | |
| 460 | Only Aggregate Operation | all |
| | Allowed | |
| | | |
| 461 | Unsupported Transport | all |
| | | |
| 462 | Destination Unreachable | all |
| | | |
| 463 | Destination Prohibited | SETUP |
| | | |
| 464 | Data Transport Not Ready Yet | PLAY |
| | | |
| 465 | Notification Reason Unknown | PLAY_NOTIFY |
| | | |
| 466 | Key Management Error | all |
| | | |
| 470 | Connection Authorization | all |
| | Required | |
| | | |
| 471 | Connection Credentials Not | all |
| | Accepted | |
| | | |
| 472 | Failure to Establish Secure | all |
| | Connection | |
| | | |
| 500 | Internal Server Error | all |
| | | |
| 501 | Not Implemented | all |
| | | |
| 502 | Bad Gateway | all |
| | | |
| 503 | Service Unavailable | all |
| | | |
| 504 | Gateway Timeout | all |
| | | |
| 505 | RTSP Version Not Supported | all |
| | | |
| 551 | Option Not Supported | all |
| | | |
| 553 | Proxy Unavailable | all |
+------+---------------------------------+--------------------------+
Table 4: Status Codes and Their Usage with RTSP Methods
表4：状态代码及其与RTSP方法的使用
The response-headers allow the request recipient to pass additional information about the response that cannot be placed in the Status-Line. This header gives information about the server and about further access to the resource identified by the Request-URI. All headers currently classified as response-headers are listed in Table 5.
响应头允许请求收件人传递有关响应的附加信息，这些信息不能放在状态行中。此标头提供有关服务器的信息以及有关进一步访问由请求URI标识的资源的信息。表5列出了当前分类为响应头的所有头。
+------------------------+----------------+
| Header | Defined in |
+------------------------+----------------+
| Authentication-Info | Section 18.7 |
| | |
| Connection-Credentials | Section 18.13 |
| | |
| Location | Section 18.28 |
| | |
| MTag | Section 18.31 |
| | |
| Proxy-Authenticate | Section 18.34 |
| | |
| Public | Section 18.39 |
| | |
| Retry-After | Section 18.44 |
| | |
| Unsupported | Section 18.55 |
| | |
| WWW-Authenticate | Section 18.58 |
+------------------------+----------------+
+------------------------+----------------+
| Header | Defined in |
+------------------------+----------------+
| Authentication-Info | Section 18.7 |
| | |
| Connection-Credentials | Section 18.13 |
| | |
| Location | Section 18.28 |
| | |
| MTag | Section 18.31 |
| | |
| Proxy-Authenticate | Section 18.34 |
| | |
| Public | Section 18.39 |
| | |
| Retry-After | Section 18.44 |
| | |
| Unsupported | Section 18.55 |
| | |
| WWW-Authenticate | Section 18.58 |
+------------------------+----------------+
Table 5: The RTSP Response Headers
表5:RTSP响应头
Response-header names can be extended reliably only in combination with a change in the protocol version. However, the usage of feature tags in the request allows the responding party to learn the capability of the receiver of the response. A new or experimental header can be given the semantics of response-header if all parties in the communication recognize them to be a response-header. Unrecognized headers in responses MUST be ignored.
只有结合协议版本的更改，才能可靠地扩展响应头名称。然而，在请求中使用特征标记允许响应方了解响应接收方的能力。如果通信中的所有各方都将响应头识别为响应头，则可以为新的或实验性的头赋予响应头的语义。必须忽略响应中无法识别的标题。
Some request and response messages include a message body, if not otherwise restricted by the request method or response status code. The message body consists of the content data itself (see also Section 5.3).
如果不受请求方法或响应状态代码的限制，某些请求和响应消息包括消息正文。消息正文由内容数据本身组成（另见第5.3节）。
The SET_PARAMETER and GET_PARAMETER requests and responses, and the DESCRIBE response as defined by this specification, can have a message body; the purpose of the message body is defined in each case. All 4xx and 5xx responses MAY also have a message body to carry additional response information. Generally, a message body MAY be attached to any RTSP 2.0 request or response, but the content of the message body MAY be ignored by the receiver. Extensions to this specification can specify the purpose and content of message bodies, including requiring their inclusion.
SET_参数和GET_参数请求和响应以及本规范定义的descripe响应可以有一个消息体；在每种情况下都定义了消息体的用途。所有4xx和5xx响应也可能有一个消息体来承载额外的响应信息。通常，消息体可以附加到任何RTSP 2.0请求或响应，但接收方可能会忽略消息体的内容。此规范的扩展可以指定消息体的目的和内容，包括要求包含它们。
In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives the message body.
在本节中，发件人和收件人都指客户机或服务器，具体取决于谁发送和谁接收消息正文。
Message body header fields define meta-information about the content data in the message body. The message body header fields are listed in Table 6.
消息正文标题字段定义有关消息正文中内容数据的元信息。表6列出了消息正文标题字段。
+------------------+----------------+
| Header | Defined in |
+------------------+----------------+
| Allow | Section 18.6 |
| | |
| Content-Base | Section 18.14 |
| | |
| Content-Encoding | Section 18.15 |
| | |
| Content-Language | Section 18.16 |
| | |
| Content-Length | Section 18.17 |
| | |
| Content-Location | Section 18.18 |
| | |
| Content-Type | Section 18.19 |
| | |
| Expires | Section 18.22 |
| | |
| Last-Modified | Section 18.27 |
+------------------+----------------+
+------------------+----------------+
| Header | Defined in |
+------------------+----------------+
| Allow | Section 18.6 |
| | |
| Content-Base | Section 18.14 |
| | |
| Content-Encoding | Section 18.15 |
| | |
| Content-Language | Section 18.16 |
| | |
| Content-Length | Section 18.17 |
| | |
| Content-Location | Section 18.18 |
| | |
| Content-Type | Section 18.19 |
| | |
| Expires | Section 18.22 |
| | |
| Last-Modified | Section 18.27 |
+------------------+----------------+
Table 6: The RTSP Message Body Headers
表6:RTSP消息正文头
The extension-header mechanism allows additional message body header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields MUST be ignored by the recipient and forwarded by proxies.
扩展头机制允许在不更改协议的情况下定义其他消息正文头字段，但不能假定收件人可以识别这些字段。收件人必须忽略无法识别的标题字段，并由代理转发。
An RTSP message with a message body MUST include the Content-Type and Content-Length headers. When a message body is included with a message, the data type of that content data is determined via the Content-Type and Content-Encoding header fields.
具有消息正文的RTSP消息必须包含内容类型和内容长度标题。当消息包含消息正文时，通过内容类型和内容编码头字段确定该内容数据的数据类型。
Content-Type specifies the media type of the underlying data. There is no default media format and the actual format used in the body is required to be explicitly stated in the Content-Type header. By being explicit and always requiring the inclusion of the Content-Type header with accurate information, one avoids the many pitfalls in a heuristic-based interpretation of the body content. The user experience of HTTP and email have suffered from relying on such heuristics.
内容类型指定基础数据的媒体类型。没有默认媒体格式，正文中使用的实际格式需要在内容类型标题中明确说明。通过明确且始终要求包含内容类型标题和准确信息，可以避免基于启发式的正文内容解释中的许多陷阱。HTTP和电子邮件的用户体验因依赖这种启发式方法而受到影响。
Content-Encoding may be used to indicate any additional content-codings applied to the data, usually for the purpose of data compression, that are a property of the requested resource. The default encoding is 'identity', i.e. no transformation of the message body.
内容编码可用于指示应用于数据的任何附加内容编码，通常用于数据压缩，这是所请求资源的属性。默认编码为“标识”，即不转换消息体。
The Content-Length of a message is the length of the content, measured in octets.
消息的内容长度是内容的长度，以八位字节为单位。
The content format of the message body is provided using the Content-Type header (Section 18.19). To enable the responder of a request to determine which media type it should use, the requester may include the Accept header (Section 18.1) in a request to identify supported media types or media type ranges suitable to the response. In case the responder is not supporting any of the specified formats, then the request response will be a 406 (Not Acceptable) error code.
消息正文的内容格式使用内容类型标题提供（第18.19节）。为了使请求的响应者能够确定其应该使用哪种媒体类型，请求者可以在请求中包括Accept标头（第18.1节），以确定支持的媒体类型或适合响应的媒体类型范围。如果响应程序不支持任何指定格式，那么请求响应将是406（不可接受）错误代码。
The media types that may be used on requests with message bodies need to be determined through the use of feature tags, specification requirement, or trial and error. Trial and error works because when the responder does not support the media type of the message body, it will respond with a 415 (Unsupported Media Type).
可用于消息体请求的媒体类型需要通过使用功能标签、规范要求或试错来确定。试错法之所以有效，是因为当响应者不支持消息正文的媒体类型时，它将使用415（不支持的媒体类型）进行响应。
The formats supported and their negotiation is done individually on a per method and direction (request or response body) direction. Requirements on supporting particular media types for use as message bodies in requests and response SHALL also be specified on a per-method and per-direction basis.
支持的格式及其协商是按照每个方法和方向（请求或响应主体）单独完成的。还应根据每个方法和每个方向规定支持用作请求和响应中消息体的特定媒体类型的要求。
RTSP messages are transferred between RTSP agents and proxies using a transport connection. This transport connection uses TCP or TCP/TLS. This transport connection is referred to as the "connection" or "RTSP connection" within this document.
RTSP消息使用传输连接在RTSP代理和代理之间传输。此传输连接使用TCP或TCP/TLS。此传输连接在本文件中称为“连接”或“RTSP连接”。
RTSP requests can be transmitted using the two different connection scenarios listed below:
RTSP请求可以使用以下两种不同的连接方案进行传输：
o persistent - a transport connection is used for several request/ response transactions;
o 持久性-传输连接用于多个请求/响应事务；
o transient - a transport connection is used for each single request/response transaction.
o 瞬态-传输连接用于每个请求/响应事务。
RFC 2326 attempted to specify an optional mechanism for transmitting RTSP messages in connectionless mode over a transport protocol such as UDP. However, it was not specified in sufficient detail to allow for interoperable implementations. In an attempt to reduce complexity and scope, and due to lack of interest, RTSP 2.0 does not attempt to define a mechanism for supporting RTSP over UDP or other connectionless transport protocols. A side effect of this is that RTSP requests MUST NOT be sent to multicast groups since no connection can be established with a specific receiver in multicast environments.
RFC 2326试图指定一种可选机制，用于通过传输协议（如UDP）以无连接模式传输RTSP消息。然而，它没有被详细地指定以允许互操作的实现。为了降低复杂性和范围，并且由于缺乏兴趣，RTSP 2.0不尝试定义通过UDP或其他无连接传输协议支持RTSP的机制。这样做的一个副作用是RTSP请求不能发送到多播组，因为在多播环境中无法与特定的接收器建立连接。
Certain RTSP headers, such as the CSeq header (Section 18.20), which may appear to be relevant only to connectionless transport scenarios, are still retained and MUST be implemented according to this specification. In the case of CSeq, it is quite useful for matching responses to requests if the requests are pipelined (see Section 12). It is also useful in proxies for keeping track of the different requests when aggregating several client requests on a single TCP connection.
某些RTSP报头，如CSeq报头（第18.20节），可能看起来仅与无连接传输场景相关，仍然保留，必须根据本规范实施。在CSeq的情况下，如果请求是流水线的，那么将响应与请求进行匹配非常有用（参见第12节）。在代理中，当在单个TCP连接上聚合多个客户端请求时，它还可以用于跟踪不同的请求。
Since RTSP messages are transmitted using reliable transport protocols, they MUST NOT be retransmitted at the RTSP level. Instead, the implementation must rely on the underlying transport to
由于RTSP消息使用可靠的传输协议传输，因此不得在RTSP级别重新传输。相反，实现必须依赖于底层传输
provide reliability. The RTSP implementation may use any indication of reception acknowledgment of the message from the underlying transport protocols to optimize the RTSP behavior.
提供可靠性。RTSP实现可以使用来自底层传输协议的消息的接收确认的任何指示来优化RTSP行为。
If both the underlying reliable transport, such as TCP, and the RTSP application retransmit requests, each packet loss or message loss may result in two retransmissions. The receiver typically cannot take advantage of the application-layer retransmission since the transport stack will not deliver the application-layer retransmission before the first attempt has reached the receiver. If the packet loss is caused by congestion, multiple retransmissions at different layers will exacerbate the congestion.
如果底层可靠传输（如TCP）和RTSP应用程序都重新传输请求，则每个数据包丢失或消息丢失可能会导致两次重新传输。接收器通常不能利用应用层重传，因为传输堆栈在第一次尝试到达接收器之前不会交付应用层重传。如果分组丢失是由拥塞引起的，那么在不同的层上多次重传将加剧拥塞。
Lack of acknowledgment of an RTSP request should be handled within the constraints of the connection timeout considerations described below (Section 10.4).
RTSP请求的未确认应在以下所述连接超时注意事项的限制范围内处理（第10.4节）。
A TCP transport can be used for both persistent connections (for several message exchanges) and transient connections (for a single message exchange). Implementations of this specification MUST support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) allows the client to specify the port it will contact the server on, and defines the default port to use if one is not explicitly given.
TCP传输可用于持久连接（用于多个消息交换）和瞬态连接（用于单个消息交换）。本规范的实现必须支持TCP上的RTSP。RTSP URI的方案（第4.2节）允许客户机指定它将与服务器联系的端口，并定义默认端口（如果没有明确给出）。
In addition to the registered default ports, i.e., 554 (rtsp) and 322 (rtsps), there is an alternative port 8554 registered. This port may provide some benefits over non-registered ports if an RTSP server is unable to use the default ports. The benefits may include preconfigured security policies as well as classifiers in network monitoring tools.
除了注册的默认端口，即554（rtsp）和322（rtsp），还有一个注册的替代端口8554。如果RTSP服务器无法使用默认端口，则此端口可能比未注册的端口提供一些好处。好处可能包括预配置的安全策略以及网络监控工具中的分类器。
An RTSP client opening a TCP connection to access a particular resource as identified by a URI uses the IP address and port derived from the host and port parts of the URI. The IP address is either the explicit address provided in the URI or any of the addresses provided when performing A and AAAA record DNS lookups of the hostname in the URI.
RTSP客户端打开TCP连接以访问URI标识的特定资源时，会使用从URI的主机和端口部分派生的IP地址和端口。IP地址可以是URI中提供的显式地址，也可以是在URI中对主机名执行DNS和AAAA记录查找时提供的任何地址。
A server MUST handle both persistent and transient connections.
服务器必须同时处理持久连接和临时连接。
Transient connections facilitate mechanisms for fault tolerance. They also allow for application-layer mobility. A server-and-client pair that supports transient connections can survive the
瞬态连接有助于容错机制。它们还允许应用程序层的移动性。支持临时连接的服务器和客户端对可以在
loss of a TCP connection; e.g., due to a NAT timeout. When the client has discovered that the TCP connection has been lost, it can set up a new one when there is need to communicate again.
TCP连接丢失；e、 例如，由于NAT超时。当客户端发现TCP连接已丢失时，它可以在需要再次通信时设置一个新连接。
A persistent connection is RECOMMENDED to be used for all transactions between the server and client, including messages for multiple RTSP sessions. However, a persistent connection MAY be closed after a few message exchanges. For example, a client may use a persistent connection for the initial SETUP and PLAY message exchanges in a session and then close the connection. Later, when the client wishes to send a new request, such as a PAUSE for the session, a new connection would be opened. This connection may be either transient or persistent.
建议对服务器和客户端之间的所有事务使用持久连接，包括多个RTSP会话的消息。但是，在几次消息交换之后，可能会关闭持久连接。例如，客户机可以使用持久连接进行初始设置，并在会话中播放消息交换，然后关闭连接。稍后，当客户端希望发送一个新请求（例如暂停会话）时，将打开一个新连接。此连接可以是暂时的，也可以是持久的。
An RTSP agent MAY use one connection to handle multiple RTSP sessions on the same server. The RTSP agent SHALL NOT use more than one connection per RTSP session at any given point.
RTSP代理可以使用一个连接来处理同一服务器上的多个RTSP会话。RTSP代理在任何给定点的每个RTSP会话不得使用多个连接。
Having only one connection in use at any time avoids confusion regarding on which connection any server-to-client requests shall be sent. Using a single connection for multiple RTSP sessions also saves complexity by enabling the server to maintain less state about its connection resources on the server. Not using more than one connection at a time for a particular RTSP session avoids wasting connection resources and allows the server to track only the most recently used client-to-server connection for each RTSP session as being the currently valid server-to-client connection.
在任何时候只有一个连接在使用中，避免了关于任何服务器到客户端的请求应该在哪个连接上发送的混淆。对多个RTSP会话使用单个连接还可以通过使服务器在服务器上保持较少的连接资源状态来节省复杂性。对于特定RTSP会话，一次不使用多个连接可避免浪费连接资源，并允许服务器仅跟踪每个RTSP会话最近使用的客户端到服务器连接，作为当前有效的服务器到客户端连接。
RTSP allows a server to send requests to a client. However, this can be supported only if a client establishes a persistent connection with the server. In cases where a persistent connection does not exist between a server and its client, due to the lack of a signaling channel, the server may be forced to silently discard RTSP messages, and it may even drop an RTSP session without notifying the client. An example of such a case is when the server desires to send a REDIRECT request for an RTSP session to the client but is not able to do so because it cannot reach the client. A server that attempts to send a request to a client that has no connection currently to the server SHALL discard the request.
RTSP允许服务器向客户端发送请求。但是，只有当客户端与服务器建立持久连接时，才能支持此操作。在服务器与其客户端之间不存在持久连接的情况下，由于缺少信令通道，服务器可能被迫以静默方式丢弃RTSP消息，甚至可能在不通知客户端的情况下丢弃RTSP会话。这种情况的一个示例是，服务器希望向客户端发送RTSP会话的重定向请求，但由于无法到达客户端而无法这样做。尝试向当前未连接到服务器的客户端发送请求的服务器应放弃该请求。
Without a persistent connection between the client and the server, the media server has no reliable way of reaching the client. Because of the likely failure of server-to-client established connections, the server will not even attempt establishing any connection.
如果客户端和服务器之间没有持久连接，媒体服务器就无法可靠地到达客户端。由于服务器到客户端建立的连接可能失败，服务器甚至不会尝试建立任何连接。
Queuing of server-to-client requests has been considered. However, a security issue exists as to how it might be possible to authorize a client establishing a new connection as being a legitimate receiver of a request related to a particular RTSP session, without the client first issuing requests related to the pending request. Thus, it would be likely to make any such requests even more delayed and less useful.
已经考虑了服务器到客户端请求的排队。但是，存在一个安全问题，即如何授权建立新连接的客户端作为与特定RTSP会话相关的请求的合法接收者，而不需要客户端首先发出与挂起的请求相关的请求。因此，它很可能会使任何此类请求更加延迟，而且用处更小。
The sending of client and server requests can be asynchronous events. To avoid deadlock situations, both client and server MUST be able to send and receive requests simultaneously. As an RTSP response may be queued up for transmission, reception or processing behind the peer RTSP agent's own requests, all RTSP agents are required to have a certain capability of handling outstanding messages. A potential issue is that outstanding requests may time out despite being processed by the peer; this can be due to the response being caught in the queue behind a number of requests that the RTSP agent is processing but that take some time to complete. To avoid this problem, an RTSP agent should buffer incoming messages locally so that any response messages can be processed immediately upon reception. If responses are separated from requests and directly forwarded for processing, not only can the result be used immediately, the state associated with that outstanding request can also be released. However, buffering a number of requests on the receiving RTSP agent consumes resources and enables a resource exhaustion attack on the agent. Therefore, this buffer should be limited so that an unreasonable number of requests or total message size is not allowed to consume the receiving agent's resources. In most APIs, having the receiving agent stop reading from the TCP socket will result in TCP's window being clamped, thus forcing the buffering onto the sending agent when the load is larger than expected. However, as both RTSP message sizes and frequency may be changed in the future by protocol extensions, an agent should be careful about taking harsher measurements against a potential attack. When under attack, an RTSP agent can close TCP connections and release state associated with that TCP connection.
客户端和服务器请求的发送可以是异步事件。为了避免死锁情况，客户端和服务器必须能够同时发送和接收请求。由于RTSP响应可能在对等RTSP代理自己的请求之后排队等待传输、接收或处理，因此所有RTSP代理都需要具有一定的处理未完成消息的能力。一个潜在的问题是，未完成的请求可能会超时，尽管已被对等方处理；这可能是因为响应被捕获在RTSP代理正在处理但需要一些时间才能完成的多个请求后面的队列中。为避免此问题，RTSP代理应在本地缓冲传入消息，以便在接收到任何响应消息后立即进行处理。如果响应与请求分离并直接转发以进行处理，那么不仅可以立即使用结果，还可以释放与未完成请求相关联的状态。但是，在接收RTSP代理上缓冲大量请求会消耗资源，并在代理上启用资源耗尽攻击。因此，应该限制此缓冲区，以便不允许不合理的请求数或总消息大小消耗接收代理的资源。在大多数API中，让接收代理停止从TCP套接字读取将导致TCP的窗口被钳制，从而在负载大于预期时迫使发送代理进行缓冲。但是，由于RTSP消息的大小和频率将来可能会因协议扩展而改变，因此代理应小心对潜在攻击采取更严厉的措施。受到攻击时，RTSP代理可以关闭TCP连接并释放与该TCP连接关联的状态。
To provide some guidance on what is reasonable, the following guidelines are given. It is RECOMMENDED that:
为了提供一些合理的指导，给出了以下指南。建议：
o an RTSP agent should not have more than 10 outstanding requests per RTSP session;
o RTSP代理在每个RTSP会话中的未完成请求不应超过10个；
o an RTSP agent should not have more than 10 outstanding requests that are not related to an RTSP session or that are requesting to create an RTSP session.
o RTSP代理的未完成请求不应超过10个，这些请求与RTSP会话无关或请求创建RTSP会话。
In light of the above, it is RECOMMENDED that clients use persistent connections whenever possible. A client that supports persistent connections MAY "pipeline" its requests (see Section 12).
鉴于上述情况，建议客户机尽可能使用持久连接。支持持久连接的客户端可以“管道化”其请求（参见第12节）。
RTSP agents can send requests to multiple different destinations, either server or client contexts over the same connection to a proxy. Then, the proxy forks the message to the different destinations over proxy-to-agent connections. In these cases when multiple requests are outstanding, the requesting agent MUST be ready to receive the responses out of order compared to the order they where sent on the connection. The order between multiple messages for each destination will be maintained; however, the order between response from different destinations can be different.
RTSP代理可以通过与代理的同一连接向多个不同的目的地（服务器或客户端上下文）发送请求。然后，代理通过代理到代理的连接将消息分叉到不同的目的地。在这些情况下，当多个请求未完成时，与响应在连接上发送的顺序相比，请求代理必须准备好接收无序的响应。将维护每个目的地的多条消息之间的顺序；但是，来自不同目的地的响应之间的顺序可能不同。
The reason for this is to avoid a head-of-line blocking situation. In a sequence of requests, an early outstanding request may take time to be processed at one destination. Simultaneously, a response from any other destination that was later in the sequence of requests may have arrived at the proxy; thus, allowing out-of-order responses avoids forcing the proxy to buffer this response and instead deliver it as soon as possible. Note, this will not affect the order in which the messages sent to each separate destination were processed at the request destination.
这样做的原因是为了避免线路阻塞情况。在一系列请求中，在一个目的地处理早期未完成的请求可能需要时间。同时，来自请求序列中稍后的任何其他目的地的响应可能已经到达代理；因此，允许无序响应可以避免强制代理缓冲此响应，而是尽快交付它。注意，这不会影响发送到每个单独目的地的消息在请求目的地的处理顺序。
This scenario can occur in two cases involving proxies. The first is a client issuing requests for sessions on different servers using a common client-to-proxy connection. The second is for server-to-client requests, like REDIRECT being sent by the server over a common transport connection the proxy created for its different connecting clients.
这种情况可能发生在两种涉及代理的情况下。第一种是客户端使用公共客户端到代理连接在不同服务器上发出会话请求。第二种是用于服务器到客户端的请求，例如服务器通过公共传输连接发送重定向，该传输连接是代理为其不同的连接客户端创建的。
The client MAY close a connection at any point when no outstanding request/response transactions exist for any RTSP session being managed through the connection. The server, however, SHOULD NOT close a connection until all RTSP sessions being managed through the connection have been timed out (Section 18.49). A server SHOULD NOT close a connection immediately after responding to a session-level TEARDOWN request for the last RTSP session being controlled through the connection. Instead, the server should wait for a reasonable amount of time for the client to receive and act upon the TEARDOWN
当通过连接管理的任何RTSP会话不存在未完成的请求/响应事务时，客户端可以在任何时候关闭连接。但是，在通过连接管理的所有RTSP会话超时之前，服务器不应关闭连接（第18.49节）。服务器不应在响应通过连接控制的最后一个RTSP会话的会话级拆卸请求后立即关闭连接。相反，服务器应该等待一段合理的时间，以便客户机接收拆卸并对其进行操作
response and then initiate the connection closing. The server SHOULD wait at least 10 seconds after sending the TEARDOWN response before closing the connection.
响应，然后启动连接关闭。服务器应在发送拆卸响应后等待至少10秒，然后再关闭连接。
This is to ensure that the client has time to issue a SETUP for a new session on the existing connection after having torn the last one down. Ten seconds should give the client ample opportunity to get its message to the server.
这是为了确保客户端在拆除最后一个会话后，有时间在现有连接上发布新会话的设置。十秒钟应该给客户端足够的机会将其消息发送到服务器。
A server SHOULD NOT close the connection directly as a result of responding to a request with an error code.
服务器不应因响应带有错误代码的请求而直接关闭连接。
Certain error responses such as 460 (Only Aggregate Operation Allowed) (Section 17.4.24) are used for negotiating capabilities of a server with respect to content or other factors. In such cases, it is inefficient for the server to close a connection on an error response. Also, such behavior would prevent implementation of advanced or special types of requests or result in extra overhead for the client when testing for new features. On the other hand, keeping connections open after sending an error response poses a Denial-of-Service (DoS) security risk (Section 21).
某些错误响应，例如460（仅允许聚合操作）（第17.4.24节），用于协商服务器在内容或其他因素方面的能力。在这种情况下，服务器在错误响应时关闭连接是低效的。此外，这种行为将阻止高级或特殊类型请求的实现，或者在测试新功能时导致客户端额外的开销。另一方面，在发送错误响应后保持连接打开会带来拒绝服务（DoS）安全风险（第21节）。
The server MAY close a connection if it receives an incomplete message and if the message is not completed within a reasonable amount of time. It is RECOMMENDED that the server wait at least 10 seconds for the completion of a message or for the next part of the message to arrive (which is an indication that the transport and the client are still alive). Servers believing they are under attack or that are otherwise starved for resources during that event MAY consider using a shorter timeout.
如果服务器收到不完整的消息，并且消息未在合理的时间内完成，则服务器可能会关闭连接。建议服务器至少等待10秒钟，等待消息完成或消息的下一部分到达（这表示传输和客户端仍处于活动状态）。服务器认为他们处于攻击状态，或者在该事件中饿死资源时，可以考虑使用更短的超时时间。
If a server closes a connection while the client is attempting to send a new request, the client will have to close its current connection, establish a new connection, and send its request over the new connection.
如果服务器在客户端尝试发送新请求时关闭连接，则客户端必须关闭其当前连接，建立新连接，然后通过新连接发送请求。
An RTSP message SHOULD NOT be terminated by closing the connection. Such a message MAY be considered to be incomplete by the receiver and discarded. An RTSP message is properly terminated as defined in Section 5.
不应通过关闭连接来终止RTSP消息。这样的消息可能被接收器认为是不完整的，并被丢弃。RTSP消息按照第5节的定义正确终止。
Receivers of a request (responders) SHOULD respond to requests in a timely manner even when a reliable transport such as TCP is used. Similarly, the sender of a request (requester) SHOULD wait for a sufficient time for a response before concluding that the responder will not be acting upon its request.
请求的接收者（响应者）应该及时响应请求，即使使用了可靠的传输，如TCP。类似地，请求的发送者（请求者）应该等待足够的时间进行响应，然后才能断定响应者不会对其请求采取行动。
A responder SHOULD respond to all requests within 5 seconds. If the responder recognizes that the processing of a request will take longer than 5 seconds, it SHOULD send a 100 (Continue) response as soon as possible. It SHOULD continue sending a 100 response every 5 seconds thereafter until it is ready to send the final response to the requester. After sending a 100 response, the responder MUST send a final response indicating the success or failure of the request.
响应者应在5秒内响应所有请求。如果响应者意识到处理请求的时间将超过5秒，则应尽快发送100（继续）响应。此后，它应每5秒继续发送100个响应，直到准备好将最终响应发送给请求者。发送100响应后，响应者必须发送最终响应，指示请求的成功或失败。
A requester SHOULD wait at least 10 seconds for a response before concluding that the responder will not be responding to its request. After receiving a 100 response, the requester SHOULD continue waiting for further responses. If more than 10 seconds elapse without receiving any response, the requester MAY assume that the responder is unresponsive and abort the connection by closing the TCP connection.
请求者应等待至少10秒钟的响应，然后才能断定响应者不会响应其请求。在收到100响应后，请求者应继续等待进一步的响应。如果超过10秒没有收到任何响应，请求者可能会认为响应者没有响应，并通过关闭TCP连接中止连接。
In some cases, multiple RTSP sessions share the same transport connection; abandoning a request and closing the connection may have significant impact on those other sessions. First of all, other RTSP requests may have become queued up due to the request taking a long time to process. Secondly, those sessions also lose the possibility to receive server-to-client requests. To mitigate that situation, the RTSP client or server SHOULD establish a new connection and send any requests that are queued up or that haven't received a response on this new connection. Thirdly, to ensure that the RTSP server knows which connection is valid for a particular RTSP session, the RTSP agent SHOULD send a keep-alive request, if no other request will be sent immediately for that RTSP session, for each RTSP session on the old connection. The keep-alive request will normally be a SET_PARAMETER with a session header to inform the server that this agent cares about this RTSP session.
在某些情况下，多个RTSP会话共享相同的传输连接；放弃请求并关闭连接可能会对其他会话产生重大影响。首先，其他RTSP请求可能由于处理该请求需要很长时间而排队。其次，这些会话也失去了接收服务器到客户端请求的可能性。为了缓解这种情况，RTSP客户端或服务器应该建立一个新连接，并发送任何排队的请求或在这个新连接上没有收到响应的请求。第三，为了确保RTSP服务器知道哪个连接对特定RTSP会话有效，RTSP代理应该为旧连接上的每个RTSP会话发送保持活动请求（如果不会立即为该RTSP会话发送其他请求）。keep-alive请求通常是一个SET_参数，带有会话头，用于通知服务器此代理关心此RTSP会话。
A requester SHOULD wait longer than 10 seconds for a response if it is experiencing significant transport delays on its connection to the responder. The requester is capable of determining the Round-Trip Time (RTT) of the request/response cycle using the Timestamp header (Section 18.53) in any RTSP request.
如果请求者在与响应者的连接上遇到严重的传输延迟，则请求者应等待响应时间超过10秒。请求者能够在任何RTSP请求中使用时间戳头（第18.53节）确定请求/响应周期的往返时间（RTT）。
The 10-second wait was chosen for the following reasons. It gives TCP time to perform a couple of retransmissions, even if operating on default values. It is short enough that users may not abandon the process themselves. However, it should be noted that 10 seconds can be aggressive on certain types of networks. The 5-second value for 1xx messages is half the timeout giving a reasonable chance of successful delivery before timeout happens on the requester side.
选择10秒等待是因为以下原因。它为TCP提供了执行几次重传的时间，即使是在默认值下操作。它足够短，用户自己可能不会放弃这个过程。然而，应该注意的是，在某些类型的网络上，10秒可能具有攻击性。1xx消息的5秒值是超时的一半，在请求方发生超时之前，有合理的成功传递机会。
RTSP requires the client to periodically show its liveness to the server or the server may terminate any session state. Several different protocol mechanism include in their usage a liveness proof from the client. These mechanisms are RTSP requests with a Session header to the server; if RTP & RTCP is used for media data transport and the transport is established, the RTCP message proves liveness; or through any other used media-transport protocol capable of indicating liveness of the RTSP client. It is RECOMMENDED that a client not wait to the last second of the timeout before trying to send a liveness message. The RTSP message may take some time to arrive safely at the receiver, due to packet loss and TCP retransmissions. To show liveness between RTSP requests being issued to accomplish other things, the following mechanisms can be used, in descending order of preference:
RTSP要求客户端定期向服务器显示其活动性，否则服务器可能会终止任何会话状态。几种不同的协议机制在其使用中包括来自客户端的活动性证明。这些机制是向服务器发送会话头的RTSP请求；如果媒体数据传输使用RTP&RTCP，并且传输已建立，则RTCP消息证明是活跃的；或者通过能够指示RTSP客户端活动性的任何其他使用的媒体传输协议。建议客户端不要等到超时的最后一秒才尝试发送活动消息。由于数据包丢失和TCP重传，RTSP消息可能需要一些时间才能安全到达接收器。为了显示为完成其他任务而发出的RTSP请求之间的活跃性，可以使用以下机制，按首选项的降序排列：
RTCP: If RTP is used for media transport, RTCP SHOULD be used. If RTCP is used to report transport statistics, it will necessarily also function as a keep-alive. The server can determine the client by network address and port together with the fact that the client is reporting on the server's RTP sender sources (synchronization source (SSRCs)). A downside of using RTCP is that it only gives statistical guarantees of reaching the server. However, the probability of a false client timeout is so low that it can be ignored in most cases. For example, assume a session with a 60-second timeout and enough bitrate assigned to RTCP messages to send a message from client to server on average every 5 seconds. That client has, for a network with 5% packet loss, a probability of failing to confirm liveness within the timeout interval for that session of 2.4*E-16. Sessions with shorter timeouts, much higher packet loss, or small RTCP bandwidths SHOULD also implement one or more of the mechanisms below.
RTCP：如果RTP用于媒体传输，则应使用RTCP。如果RTCP用于报告传输统计数据，则它还必须起到保持活动的作用。服务器可以通过网络地址和端口以及客户端报告服务器的RTP发送方源（同步源（SSRC））来确定客户端。使用RTCP的一个缺点是，它只提供到达服务器的统计保证。但是，错误客户端超时的概率很低，在大多数情况下都可以忽略。例如，假设一个会话有60秒的超时，并且为RTCP消息分配了足够的比特率，以便平均每5秒从客户端向服务器发送一条消息。对于包丢失率为5%的网络，该客户端有可能无法在2.4*E-16会话的超时间隔内确认活动性。具有较短超时、较高数据包丢失或较小RTCP带宽的会话也应实现以下一种或多种机制。
SET_PARAMETER: When using SET_PARAMETER for keep-alives, a body SHOULD NOT be included. This method is the RECOMMENDED RTSP method to use for a request intended only to perform keep-alives. RTSP servers MUST support the SET_PARAMETER method, so that clients can always use this mechanism.
SET_参数：当使用SET_参数保存生命时，不应包含正文。对于仅用于执行保留验证的请求，建议使用此方法作为RTSP方法。RTSP服务器必须支持SET_参数方法，以便客户端始终可以使用此机制。
GET_PARAMETER: When using GET_PARAMETER for keep-alives, a body SHOULD NOT be included, dependent on implementation support in the server. Use the OPTIONS method to determine if there is method support or simply try.
GET_参数：当使用GET_参数来保持有效性时，不应包含正文，具体取决于服务器中的实现支持。使用OPTIONS方法确定是否有方法支持，或者简单地尝试一下。
OPTIONS: This method is also usable, but it causes the server to perform more unnecessary processing and results in bigger responses than necessary for the task. The reason is that the server needs to determine the capabilities associated with the media resource to correctly populate the Public and Allow headers.
选项：此方法也可用，但它会导致服务器执行更多不必要的处理，并导致比任务所需的响应更大。原因是服务器需要确定与媒体资源相关联的功能，以便正确填充公共和允许标头。
The timeout parameter of the Session header (Section 18.49) MAY be included in a SETUP response and MUST NOT be included in requests. The server uses it to indicate to the client how long the server is prepared to wait between RTSP commands or other signs of life before closing the session due to lack of activity (see Appendix B). The timeout is measured in seconds, with a default of 60 seconds. The length of the session timeout MUST NOT be changed in an established session.
会话头（第18.49节）的超时参数可包含在设置响应中，不得包含在请求中。服务器使用它向客户端指示服务器准备在RTSP命令或其他生命迹象之间等待多长时间，然后由于缺少活动而关闭会话（见附录B）。超时以秒为单位，默认值为60秒。在已建立的会话中，不能更改会话超时的长度。
Explicit IPv6 [RFC2460] support was not present in RTSP 1.0. RTSP 2.0 has been updated for explicit IPv6 support. Implementations of RTSP 2.0 MUST understand literal IPv6 addresses in URIs and RTSP headers. Although the general URI format envisages potential future new versions of the literal IP address, usage of any such new version would require other modifications to the RTSP specification (e.g., address fields in the Transport header (Section 18.54)).
RTSP 1.0中不存在明确的IPv6[RFC2460]支持。RTSP 2.0已针对明确的IPv6支持进行了更新。RTSP 2.0的实现必须理解URI和RTSP头中的文字IPv6地址。尽管通用URI格式设想了文字IP地址的潜在未来新版本，但使用任何此类新版本都需要对RTSP规范进行其他修改（例如，传输头中的地址字段（第18.54节））。
Overload in RTSP can occur when servers and proxies have insufficient resources to complete the processing of a request. An improper handling of such an overload situation at proxies and servers can impact the operation of the RTSP deployment, and probably worsen the situation. RTSP defines the 503 (Service Unavailable) response (Section 17.5.4) to let servers and proxies notify requesting proxies and RTSP clients about an overload situation. In conjunction with
当服务器和代理没有足够的资源来完成请求处理时，RTSP中可能会出现过载。在代理和服务器上不当处理此类过载情况可能会影响RTSP部署的操作，并可能使情况恶化。RTSP定义503（服务不可用）响应（第17.5.4节），让服务器和代理将过载情况通知请求代理和RTSP客户端。结合
the Retry-After header (Section 18.44), the server or proxy can indicate the time after which the requesting entity can send another request to the proxy or server.
在Retry After标头（第18.44节）中，服务器或代理可以指示请求实体可以向代理或服务器发送另一个请求的时间。
There are two scopes of such 503 answers. The first scope is for an established RTSP session, where the request resulting in the 503 response as well as the response itself carries a Session header identifying the session that is suffering overload. This response only applies to this particular session. The other scope is the general RTSP server as identified by the host in the Request-URI. Such a 503 answer with any Retry-After header applies to all requests that are not session specific to that server, including a SETUP request intended to create a new RTSP session.
这503个答案有两个范围。第一个作用域用于已建立的RTSP会话，其中导致503响应的请求以及响应本身携带识别正在遭受过载的会话的会话报头。此响应仅适用于此特定会话。另一个作用域是由主机在请求URI中标识的通用RTSP服务器。这样的503应答和任何重试后报头适用于所有不特定于该服务器会话的请求，包括用于创建新RTSP会话的设置请求。
Another scope for overload situations exists: the RTSP proxy. To enable an RTSP proxy to signal that it is overloaded, or otherwise unavailable and unable to handle the request, a 553 response code has been defined with the meaning "Proxy Unavailable". As with servers, there is a separation in response scopes between requests associated with existing RTSP sessions and requests to create new sessions or general proxy requests.
存在过载情况的另一个作用域：RTSP代理。为了使RTSP代理能够发出过载或不可用且无法处理请求的信号，定义了553响应代码，其含义为“代理不可用”。与服务器一样，与现有RTSP会话关联的请求与创建新会话或常规代理请求的请求之间在响应范围上存在分离。
Simply implementing and using the 503 (Service Unavailable) and 553 (Proxy Unavailable) response codes is not sufficient for properly handling overload situations. For instance, a simplistic approach would be to send the 503 response with a Retry-After header set to a fixed value. However, this can cause a situation in which multiple RTSP clients again send requests to a proxy or server at roughly the same time, which may again cause an overload situation. Another situation would be if the "old" overload situation is not yet resolved, i.e., the length indicated in the Retry-After header was too short for the overload situation to subside.
仅仅实现和使用503（服务不可用）和553（代理不可用）响应代码不足以正确处理过载情况。例如，一种过于简单的方法是发送503响应，并将Retry After头设置为固定值。但是，这可能会导致多个RTSP客户端几乎同时再次向代理或服务器发送请求，这可能再次导致过载情况。另一种情况是，如果“旧”过载情况尚未解决，即，在Retry After标头中指示的长度太短，过载情况无法缓解。
An RTSP server or proxy in an overload situation must select the value of the Retry-After header carefully, bearing in mind its current load situation. It is REQUIRED to increase the timeout period in proportion to the current load on the server, i.e., an increasing workload should result in an increased length of the indicated unavailability. It is REQUIRED not to send the same value in the Retry-After header to all requesting proxies and clients, but to add a variation to the mean value of the Retry-After header.
处于过载情况的RTSP服务器或代理必须仔细选择Retry After标头的值，并记住其当前的负载情况。需要根据服务器上的当前负载按比例增加超时时间，即，增加的工作负载应导致指示的不可用性长度增加。不需要在Retry After标头中向所有请求代理和客户端发送相同的值，但需要在Retry After标头的平均值上添加一个变量。
A more complex case may arise when a load-balancing RTSP proxy is in use. This is the case when an RTSP proxy is used to select amongst a set of RTSP servers to handle the requests or when multiple server addresses are available for a given server name. The proxy or client may receive a 503 (Service Unavailable) or 553 (Proxy Unavailable) response code from one of its RTSP servers or proxies, or a TCP
当使用负载平衡RTSP代理时，可能会出现更复杂的情况。当使用RTSP代理从一组RTSP服务器中进行选择以处理请求时，或者当给定服务器名称有多个服务器地址可用时，就会出现这种情况。代理或客户端可从其RTSP服务器或代理之一或TCP接收503（服务不可用）或553（代理不可用）响应代码
timeout (if the server is even unable to handle the request message). The proxy or client simply retries the other addresses or configured proxies, but it may also receive a 503 (Service Unavailable) or 553 (Proxy Unavailable) response or TCP timeouts from those addresses. In such a situation, where none of the RTSP servers/proxies/addresses can handle the request, the RTSP agent has to wait before it can send any new requests to the RTSP server. Any additional request to a specific address MUST be delayed according to the Retry-After headers received. For addresses where no response was received or TCP timeout occurred, an initial wait timer SHOULD be set to 5 seconds. That timer MUST be doubled for each additional failure to connect or receive response until the value exceeds 30 minutes when the timer's mean value may be set to 30 minutes. It is REQUIRED not to set the same value in the timer for each scheduling, but instead to add a variation to the mean value, resulting in picking a random value within the range of 0.5 to 1.5 times the mean value.
超时（如果服务器甚至无法处理请求消息）。代理或客户端只是重试其他地址或配置的代理，但也可能从这些地址接收503（服务不可用）或553（代理不可用）响应或TCP超时。在这种情况下，如果RTSP服务器/代理/地址都无法处理请求，RTSP代理必须等待，然后才能向RTSP服务器发送任何新请求。对特定地址的任何附加请求都必须根据收到头后的重试延迟。对于未收到响应或发生TCP超时的地址，初始等待计时器应设置为5秒。对于连接或接收响应的每一个额外故障，该计时器必须加倍，直到该值超过30分钟，此时计时器的平均值可以设置为30分钟。对于每个调度，不需要在计时器中设置相同的值，而是要在平均值上添加一个变量，从而在平均值的0.5到1.5倍范围内选择一个随机值。
This section describes the available capability-handling mechanism that allows RTSP to be extended. Extensions to this version of the protocol are basically done in two ways. Firstly, new headers can be added. Secondly, new methods can be added. The capability-handling mechanism is designed to handle both cases.
本节描述了允许扩展RTSP的可用能力处理机制。此版本协议的扩展基本上通过两种方式完成。首先，可以添加新的标题。第二，可以增加新的方法。能力处理机制设计用于处理这两种情况。
When a method is added, the involved parties can use the OPTIONS method to discover whether it is supported. This is done by issuing an OPTIONS request to the other party. Depending on the URI, it will either apply in regard to a certain media resource, the whole server in general, or simply the next hop. The OPTIONS response MUST contain a Public header that declares all methods supported for the indicated resource.
添加方法时，相关方可以使用OPTIONS方法来发现是否支持该方法。这是通过向另一方发出期权请求来实现的。根据URI的不同，它要么应用于某个媒体资源，要么应用于整个服务器，要么应用于下一跳。选项响应必须包含一个公共标头，该标头声明所指示资源支持的所有方法。
It is not necessary to use OPTIONS to discover support of a method, as the client could simply try the method. If the receiver of the request does not support the method, it will respond with an error code indicating the method is either not implemented (501) or does not apply for the resource (405). The choice between the two discovery methods depends on the requirements of the service.
不必使用选项来发现对方法的支持，因为客户机可以简单地尝试该方法。如果请求的接收器不支持该方法，则其将以错误代码响应，指示该方法未实现（501）或不应用于资源（405）。这两种发现方法之间的选择取决于服务的需求。
Feature tags are defined to handle functionality additions that are not new methods. Each feature tag represents a certain block of functionality. The amount of functionality that a feature tag represents can vary significantly. For example, a feature tag can represent the functionality a single RTSP header provides. Another feature tag can represent much more functionality, such as the "play.basic" feature tag (Section 11.1), which represents the minimal media delivery for playback implementation.
功能标记的定义是为了处理不是新方法的功能添加。每个功能标记表示特定的功能块。功能标签所代表的功能量可能会有很大的不同。例如，功能标签可以表示单个RTSP标头提供的功能。另一个功能标签可以表示更多的功能，例如“play.basic”功能标签（第11.1节），它表示播放实现的最小媒体交付。
Feature tags are used to determine whether the client, server, or proxy supports the functionality that is necessary to achieve the desired service. To determine support of a feature tag, several different headers can be used, each explained below:
功能标签用于确定客户端、服务器或代理是否支持实现所需服务所需的功能。为了确定对功能标签的支持，可以使用几个不同的标题，每个标题解释如下：
Supported: This header is used to determine the complete set of functionality that both client and server have, in general, and is not dependent on a specific resource. The intended usage is to determine before one needs to use a functionality that it is supported. It can be used in any method, but OPTIONS is the most suitable as it simultaneously determines all methods that are implemented. When sending a request, the requester declares all its capabilities by including all supported feature tags. This results in the receiver learning the requester's feature support. The receiver then includes its set of features in the response.
支持：此标头用于确定客户端和服务器通常都具有的完整功能集，并且不依赖于特定资源。预期用途是在需要使用支持的功能之前确定。它可以用在任何方法中，但选项是最合适的，因为它同时决定了所有实现的方法。发送请求时，请求者通过包含所有支持的功能标签来声明其所有功能。这导致接收者学习请求者的特性支持。然后，接收器在响应中包括其特征集。
Proxy-Supported: This header is used in a similar fashion as the Supported header, but instead of giving the supported functionality of the client or server, it provides both the requester and the responder a view of the common functionality supported in general by all members of the proxy chain between the client and server; it does not depend on the resource. Proxies are required to add this header whenever the Supported header is present, but proxies may also add it independently of the requester.
支持的代理：此标头的使用方式与支持的标头类似，但它不是提供客户端或服务器的支持功能，而是向请求者和响应者提供客户端和服务器之间的代理链的所有成员通常支持的通用功能的视图；它不依赖于资源。只要支持的头存在，就需要代理添加此头，但代理也可以独立于请求者添加此头。
Require: This header can be included in any request where the endpoint, i.e., the client or server, is required to understand the feature to correctly perform the request. This can, for example, be a SETUP request, where the server is required to understand a certain parameter to be able to set up the media delivery correctly. Ignoring this parameter would not have the desired effect and is not acceptable. Therefore, the endpoint receiving a request containing a Require MUST negatively acknowledge any feature that it does not understand and not perform the request. The response in cases where features are not supported is 551 (Option Not Supported). Also, the features that are not supported are given in the Unsupported header in the response.
Require：如果需要端点（即客户端或服务器）了解功能以正确执行请求，则可以在任何请求中包含此标头。例如，这可能是一个设置请求，服务器需要了解某个参数才能正确设置媒体传送。忽略此参数不会产生预期效果，并且是不可接受的。因此，接收包含Require的请求的端点必须否定地确认它不理解的任何特性，并且不执行该请求。在不支持功能的情况下，响应为551（不支持选项）。此外，响应中不支持的标题中给出了不支持的功能。
Proxy-Require: This header has the same purpose and behavior as Require except that it only applies to proxies and not the endpoint. Features that need to be supported by both proxies and endpoints need to be included in both the Require and Proxy-Require header.
Proxy Require：此标头与Require具有相同的用途和行为，只是它仅适用于代理，而不适用于端点。代理和端点都需要支持的功能需要包含在Require和Proxy Require头中。
Unsupported: This header is used in a 551 (Option Not Supported) error response, to indicate which features were not supported. Such a response is only the result of the usage of the Require or Proxy-Require headers where one or more features were not supported. This information allows the requester to make the best of situations as it knows which features are not supported.
不支持：此标题用于551（选项不支持）错误响应，以指示不支持哪些功能。这样的响应只是使用Require或Proxy Require头的结果，其中一个或多个功能不受支持。此信息允许请求者充分利用情况，因为它知道哪些功能不受支持。
An implementation supporting all normative parts of this specification for the setup and control of playback of media uses the feature tag "play.basic" to indicate this support. The appendices (starting with letters) are not part of the functionality included in the feature tag unless the appendix is explicitly specified in a main section as being a required appendix.
支持本规范所有规范部分的媒体播放设置和控制的实现使用功能标签“play.basic”来表示此支持。附录（以字母开头）不是功能标签中包含的功能的一部分，除非附录在主要章节中明确规定为必需附录。
Note: This feature tag does not mandate any media delivery protocol, such as RTP.
注意：此功能标签不强制使用任何媒体传送协议，如RTP。
In RTSP 1.0, there was a minimal implementation section. However, that was not consistent with the rest of the specification. So, rather than making an attempt to explicitly enumerate the features for play.basic, this specification has to be taken as a whole and the necessary features normatively defined as being required are included.
在RTSP1.0中，有一个最小的实现部分。但是，这与规范的其余部分不一致。因此，与其试图明确列举play.basic的特性，还不如将本规范作为一个整体，并包括规范定义为必需的必要特性。
Pipelining is a general method to improve performance of request/ response protocols by allowing the requesting agent to have more than one request outstanding and to send them over the same persistent connection. For RTSP, where the relative order of requests will matter, it is important to maintain the order of the requests. Because of this, the responding agent MUST process the incoming requests in their sending order. The sending order can be determined by the CSeq header and its sequence number. For TCP, the delivery order will be the same, between two agents, as the sending order. The processing of the request MUST also have been finished before processing the next request from the same agent. The responses MUST be sent in the order the requests were processed.
通过允许请求代理有多个未完成的请求并通过相同的持久连接发送它们，管道是一种提高请求/响应协议性能的通用方法。对于RTSP，请求的相对顺序很重要，因此维护请求的顺序很重要。因此，响应代理必须按照发送顺序处理传入的请求。发送顺序可由CSeq头及其序列号确定。对于TCP，两个代理之间的交货订单与发送订单相同。在处理来自同一代理的下一个请求之前，请求的处理也必须已经完成。响应必须按照处理请求的顺序发送。
RTSP 2.0 has extended support for pipelining beyond the capabilities in RTSP 1.0. As a major improvement, all requests involved in setting up and initiating media delivery can now be pipelined, indicated by the Pipelined-Request header (see Section 18.33). This header allows a client to request that two or more requests be processed in the same RTSP session context that the first request
RTSP 2.0扩展了对管道的支持，超出了RTSP 1.0的功能范围。作为一项重大改进，设置和启动介质交付所涉及的所有请求现在都可以通过管道传输，由管道传输请求头指示（见第18.33节）。此标头允许客户端请求在与第一个请求相同的RTSP会话上下文中处理两个或多个请求
creates. In other words, a client can request that two or more media streams be set up and then played without needing to wait for a single response. This speeds up the initial start-up time for an RTSP session by at least one RTT.
创造。换句话说，客户端可以请求设置两个或多个媒体流，然后播放，而无需等待单个响应。这将使RTSP会话的初始启动时间至少加快一个RTT。
If a pipelined request builds on the successful completion of one or more prior requests, the requester must verify that all requests were executed as expected. A common example will be two SETUP requests and a PLAY request. In case one of the SETUP requests fails unexpectedly, the PLAY request can still be successfully executed. However, the resulting presentation will not be as expected by the requesting client, as only a single media instead of two will be played. In this case, the client can send a PAUSE request, correct the failing SETUP request, and then request it be played.
如果管道化请求建立在成功完成一个或多个先前请求的基础上，请求者必须验证所有请求是否按预期执行。一个常见的例子是两个设置请求和一个播放请求。如果其中一个设置请求意外失败，则仍可成功执行播放请求。但是，由于只播放一种媒体而不是两种媒体，因此生成的演示文稿不会如请求客户端所预期的那样。在这种情况下，客户端可以发送暂停请求，更正失败的设置请求，然后请求播放。
The method indicates what is to be performed on the resource identified by the Request-URI. The method name is case sensitive. New methods may be defined in the future. Method names MUST NOT start with a $ character (decimal 36) and MUST be a token as defined by the ABNF [RFC5234] in Section 20. The methods are summarized in Table 7.
该方法指示在由请求URI标识的资源上要执行的操作。方法名称区分大小写。将来可能会定义新的方法。方法名称不得以$字符（十进制36）开头，且必须是第20节中ABNF[RFC5234]定义的标记。表7总结了这些方法。
+---------------+-----------+--------+-------------+-------------+
| method | direction | object | Server req. | Client req. |
+---------------+-----------+--------+-------------+-------------+
| DESCRIBE | C -> S | P,S | recommended | recommended |
| | | | | |
| GET_PARAMETER | C -> S | P,S | optional | optional |
| | | | | |
| | S -> C | P,S | optional | optional |
| | | | | |
| OPTIONS | C -> S | P,S | required | required |
| | | | | |
| | S -> C | P,S | optional | optional |
| | | | | |
| PAUSE | C -> S | P,S | required | required |
| | | | | |
| PLAY | C -> S | P,S | required | required |
| | | | | |
| PLAY_NOTIFY | S -> C | P,S | required | required |
| | | | | |
| REDIRECT | S -> C | P,S | optional | required |
| | | | | |
| SETUP | C -> S | S | required | required |
| | | | | |
| SET_PARAMETER | C -> S | P,S | required | optional |
| | | | | |
| | S -> C | P,S | optional | optional |
| | | | | |
| TEARDOWN | C -> S | P,S | required | required |
| | | | | |
| | S -> C | P | required | required |
+---------------+-----------+--------+-------------+-------------+
+---------------+-----------+--------+-------------+-------------+
| method | direction | object | Server req. | Client req. |
+---------------+-----------+--------+-------------+-------------+
| DESCRIBE | C -> S | P,S | recommended | recommended |
| | | | | |
| GET_PARAMETER | C -> S | P,S | optional | optional |
| | | | | |
| | S -> C | P,S | optional | optional |
| | | | | |
| OPTIONS | C -> S | P,S | required | required |
| | | | | |
| | S -> C | P,S | optional | optional |
| | | | | |
| PAUSE | C -> S | P,S | required | required |
| | | | | |
| PLAY | C -> S | P,S | required | required |
| | | | | |
| PLAY_NOTIFY | S -> C | P,S | required | required |
| | | | | |
| REDIRECT | S -> C | P,S | optional | required |
| | | | | |
| SETUP | C -> S | S | required | required |
| | | | | |
| SET_PARAMETER | C -> S | P,S | required | optional |
| | | | | |
| | S -> C | P,S | optional | optional |
| | | | | |
| TEARDOWN | C -> S | P,S | required | required |
| | | | | |
| | S -> C | P | required | required |
+---------------+-----------+--------+-------------+-------------+
Table 7: Overview of RTSP Methods
表7：RTSP方法概述
Note on Table 7: This table covers RTSP methods, their direction, and on what objects (P: presentation, S: stream) they operate. Further, it indicates whether a server or a client implementation is required (mandatory), recommended, or optional.
表7中的注释：该表包括RTSP方法、它们的方向以及它们操作的对象（P:presentation，S:stream）。此外，它还指示服务器或客户端实现是必需的（必需的）、推荐的还是可选的。
Further note on Table 7: the GET_PARAMETER is optional. For example, a fully functional server can be built to deliver media without any parameters. However, SET_PARAMETER is required, i.e., mandatory to implement for the server; this is due to its usage for keep-alive. PAUSE is required because it is the only way of leaving the Play state without terminating the whole session.
关于表7的进一步说明：GET_参数是可选的。例如，可以构建一个功能齐全的服务器，以便在不使用任何参数的情况下交付介质。但是，SET_参数是必需的，即必须为服务器实现；这是因为它用于“保持活力”。暂停是必需的，因为这是离开播放状态而不终止整个会话的唯一方法。
If an RTSP agent does not support a particular method, it MUST return a 501 (Not Implemented) response code and the requesting RTSP agent, in turn, SHOULD NOT try this method again for the given agent/ resource combination. An RTSP proxy whose 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 that the proxy still needs to perform the minimal required processing, like adding the Via header.
如果RTSP代理不支持特定方法，则它必须返回501（未实现）响应代码，而请求RTSP代理则不应针对给定的代理/资源组合再次尝试此方法。RTSP代理的主要功能是记录或审核，而不是以任何方式修改传输或媒体处理，它可以使用未知方法转发RTSP消息。请注意，代理仍然需要执行所需的最小处理，例如添加Via头。
The semantics of the RTSP OPTIONS method is similar to that of the HTTP OPTIONS method described in Section 4.3.7 of [RFC7231]. However, in RTSP, OPTIONS is bidirectional in that a client can send the request to a server and vice versa. A client MUST implement the capability to send an OPTIONS request and a server or a proxy MUST implement the capability to respond to an OPTIONS request. In addition to this "MUST-implement" functionality, clients, servers and proxies MAY provide support both for sending OPTIONS requests and for generating responses to the requests.
RTSP OPTIONS方法的语义与[RFC7231]第4.3.7节中描述的HTTP OPTIONS方法的语义相似。然而，在RTSP中，选项是双向的，因为客户端可以向服务器发送请求，反之亦然。客户端必须实现发送选项请求的功能，服务器或代理必须实现响应选项请求的功能。除此“必须实现”功能外，客户端、服务器和代理还可以提供发送选项请求和生成请求响应的支持。
An OPTIONS request may be issued at any time. Such a request does not modify the session state. However, it may prolong the session lifespan (see below). The URI in an OPTIONS request determines the scope of the request and the corresponding response. If the Request-URI refers to a specific media resource on a given host, the scope is limited to the set of methods supported for that media resource by the indicated RTSP agent. A Request-URI with only the host address limits the scope to the specified RTSP agent's general capabilities without regard to any specific media. If the Request-URI is an asterisk ("*"), the scope is limited to the general capabilities of the next hop (i.e., the RTSP agent in direct communication with the request sender).
可随时发出期权申请。这样的请求不会修改会话状态。但是，它可能会延长会话寿命（见下文）。选项请求中的URI决定了请求的范围和相应的响应。如果请求URI引用给定主机上的特定媒体资源，则范围仅限于指定RTSP代理支持的该媒体资源的方法集。仅具有主机地址的请求URI将范围限制为指定RTSP代理的一般功能，而不考虑任何特定媒体。如果请求URI是星号（“*”），则范围仅限于下一跳的一般功能（即，与请求发送方直接通信的RTSP代理）。
Regardless of the scope of the request, the Public header MUST always be included in the OPTIONS response, listing the methods that are supported by the responding RTSP agent. In addition, if the scope of the request is limited to a media resource, the Allow header MUST be included in the response to enumerate the set of methods that are allowed for that resource unless the set of methods completely matches the set in the Public header. If the given resource is not available, the RTSP agent SHOULD return an appropriate response code, such as 3rr or 4xx. The Supported header MAY be included in the request to query the set of features that are supported by the responding RTSP agent.
无论请求的范围如何，公共标头必须始终包含在选项响应中，列出响应RTSP代理支持的方法。此外，如果请求的范围限于媒体资源，则必须在响应中包含Allow标头，以枚举该资源允许的方法集，除非该方法集与公共标头中的方法集完全匹配。如果给定资源不可用，RTSP代理应返回适当的响应代码，如3rr或4xx。请求查询响应RTSP代理所支持的功能集时，可能会包含受支持的标头。
The OPTIONS method can be used to keep an RTSP session alive. However, this is not the preferred way of session keep-alive signaling; see Section 18.49. An OPTIONS request intended for keeping alive an RTSP session MUST include the Session header with the associated session identifier. Such a request SHOULD also use the media or the aggregated control URI as the Request-URI.
OPTIONS方法可用于保持RTSP会话处于活动状态。然而，这不是会话保持活动信令的首选方式；见第18.49节。用于使RTSP会话保持活动状态的选项请求必须包括会话头和相关会话标识符。这样的请求还应该使用媒体或聚合控制URI作为请求URI。
Example:
例子：
C->S: OPTIONS rtsp://server.example.com RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Proxy-Require: gzipped-messages
Supported: play.basic
C->S: OPTIONS rtsp://server.example.com RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Proxy-Require: gzipped-messages
Supported: play.basic
S->C: RTSP/2.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS
Supported: play.basic, setup.rtp.rtcp.mux, play.scale
Server: PhonyServer/1.1
S->C: RTSP/2.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS
Supported: play.basic, setup.rtp.rtcp.mux, play.scale
Server: PhonyServer/1.1
Note that the "gzipped-messages" feature tag in the Proxy-Require is a fictitious feature.
请注意，Proxy Require中的“gzip消息”功能标记是一个虚构的功能。
The DESCRIBE method is used to retrieve the description of a presentation or media object from a server. The Request-URI of the DESCRIBE request identifies the media resource of interest. The client MAY include the Accept header in the request to list the description formats that it understands. The server MUST respond with a description of the requested resource and return the description in the message body of the response, if the DESCRIBE method request can be successfully fulfilled. The DESCRIBE reply-response pair constitutes the media initialization phase of RTSP.
描述方法用于从服务器检索演示文稿或媒体对象的描述。描述请求的请求URI标识感兴趣的媒体资源。客户机可以在请求中包含Accept头，以列出其理解的描述格式。如果可以成功完成descripe方法请求，服务器必须使用请求资源的描述进行响应，并在响应的消息体中返回描述。描述应答对构成RTSP的媒体初始化阶段。
The DESCRIBE response SHOULD contain all media initialization information for the resource(s) that it describes. Servers SHOULD NOT use the DESCRIBE response as a means of media indirection by having the description point at another server; instead, using the 3rr responses is RECOMMENDED.
描述响应应包含所描述资源的所有媒体初始化信息。服务器不应通过将描述点放在另一台服务器上，将描述响应用作媒体间接寻址的手段；相反，建议使用3rr响应。
By forcing a DESCRIBE response to contain all media initialization information for the set of streams that it describes, and discouraging the use of DESCRIBE for media indirection, any looping problems can be avoided that might have resulted from other approaches.
通过强制descripe响应包含它所描述的流集的所有媒体初始化信息，并阻止使用descripe for media indirection，可以避免可能由其他方法导致的任何循环问题。
Example:
例子：
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312
User-Agent: PhonyClient/1.2
Accept: application/sdp, application/example
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/2.0
CSeq: 312
User-Agent: PhonyClient/1.2
Accept: application/sdp, application/example
S->C: RTSP/2.0 200 OK
CSeq: 312
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.1
Content-Base: rtsp://server.example.com/fizzle/foo/
Content-Type: application/sdp
Content-Length: 358
S->C: RTSP/2.0 200 OK
CSeq: 312
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.1
Content-Base: rtsp://server.example.com/fizzle/foo/
Content-Type: application/sdp
Content-Length: 358
v=0
o=MNobody 2890844526 2890842807 IN IP4 192.0.2.46
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps
e=seminar@example.com (Seminar Management)
c=IN IP4 0.0.0.0
a=control:*
t=2873397496 2873404696
m=audio 3456 RTP/AVP 0
a=control:audio
m=video 2232 RTP/AVP 31
a=control:video
v=0
o=MNobody 2890844526 2890842807 IN IP4 192.0.2.46
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/lectures/sdp.ps
e=seminar@example.com (Seminar Management)
c=IN IP4 0.0.0.0
a=control:*
t=2873397496 2873404696
m=audio 3456 RTP/AVP 0
a=control:audio
m=video 2232 RTP/AVP 31
a=control:video
Media initialization is a requirement for any RTSP-based system, but the RTSP specification does not dictate that this is required to be done via the DESCRIBE method. There are three ways that an RTSP client may receive initialization information:
任何基于RTSP的系统都需要进行介质初始化，但RTSP规范并未规定需要通过描述方法进行介质初始化。RTSP客户端可以通过三种方式接收初始化信息：
o via an RTSP DESCRIBE request
o 通过RTSP描述请求
o via some other protocol (HTTP, email attachment, etc.)
o 通过其他协议（HTTP、电子邮件附件等）
o via some form of user interface
o 通过某种形式的用户界面
If a client obtains a valid description from an alternate source, the client MAY use this description for initialization purposes without issuing a DESCRIBE request for the same media. The client should use any MTag to either validate the presentation description or make the session establishment conditional on being valid.
如果客户机从备用源获得有效描述，则客户机可将该描述用于初始化目的，而无需对同一介质发出描述请求。客户端应使用任何MTag来验证演示文稿描述或使会话建立以有效为条件。
It is RECOMMENDED that minimal servers support the DESCRIBE method, and highly recommended that minimal clients support the ability to act as "helper applications" that accept a media initialization file from a user interface, or other means that are appropriate to the operating environment of the clients.
建议minimal Server支持descripe方法，强烈建议minimal Client支持充当“助手应用程序”的功能，该应用程序从用户界面或适合于客户端操作环境的其他方式接受媒体初始化文件。
The description below uses the following states in a protocol state machine that is related to a specific session when that session has been created. The state transitions are driven by protocol interactions. For additional information about the state machine, see Appendix B.
下面的描述使用协议状态机中的以下状态，该状态机在创建特定会话时与该会话相关。状态转换由协议交互驱动。有关状态机的更多信息，请参见附录B。
Init: Initial state. No session exists.
Init：初始状态。没有会话存在。
Ready: Session is ready to start playing.
准备就绪：会话已准备好开始播放。
Play: Session is playing, i.e., sending media-stream data in the direction S->C.
播放：正在播放会话，即沿S->C方向发送媒体流数据。
The SETUP request for a URI specifies the transport mechanism to be used for the streamed media. The SETUP method may be used in two different cases, namely, creating an RTSP session and changing the transport parameters of media streams that are already set up. SETUP can be used in all three states, Init, Ready, and Play, to change the transport parameters. Additionally, Init and Ready can also be used for the creation of the RTSP session. The usage of the SETUP method in the Play state to add a media resource to the session is unspecified.
URI的设置请求指定用于流媒体的传输机制。设置方法可用于两种不同的情况，即创建RTSP会话和更改已设置的媒体流的传输参数。设置程序可用于所有三种状态，即初始、就绪和播放，以更改传输参数。此外，Init和Ready还可用于创建RTSP会话。未指定在播放状态下使用设置方法向会话添加媒体资源。
The Transport header, see Section 18.54, specifies the media-transport parameters acceptable to the client for data transmission; the response will contain the transport parameters selected by the server. This allows the client to enumerate, in descending order of preference, the transport mechanisms and parameters acceptable to it, so the server can select the most appropriate. It is expected that the session description format used will enable the client to select a limited number of possible configurations that are offered as choices to the server. All transport-related parameters SHALL be included in the Transport header; the use of other headers for this purpose is NOT RECOMMENDED due to middleboxes, such as firewalls or NATs.
传输头（见第18.54节）规定了客户可接受的用于数据传输的媒体传输参数；响应将包含服务器选择的传输参数。这允许客户机按首选项的降序枚举其可接受的传输机制和参数，以便服务器可以选择最合适的传输机制和参数。预期使用的会话描述格式将使客户端能够选择作为服务器选项提供的有限数量的可能配置。所有运输相关参数应包含在运输总管中；由于中间盒（如防火墙或NAT）的原因，不建议为此目的使用其他标头。
For the benefit of any intervening firewalls, a client MUST indicate the known transport parameters, even if it has no influence over these parameters, for example, where the server advertises a fixed-multicast address as destination.
对于任何介入防火墙的好处，客户机必须指示已知的传输参数，即使它对这些参数没有影响，例如，在服务器播发固定的多播地址作为目的地的情况下。
Since SETUP includes all transport initialization information, firewalls and other intermediate network devices (which need this information) are spared the more arduous task of parsing the DESCRIBE response, which has been reserved for media initialization.
由于安装程序包括所有传输初始化信息，防火墙和其他中间网络设备（需要此信息）可以省去解析描述响应这一更艰巨的任务，该响应已保留用于媒体初始化。
The client MUST include the Accept-Ranges header in the request, indicating all supported unit formats in the Range header. This allows the server to know which formats it may use in future session-related responses, such as a PLAY response without any range in the request. If the client does not support a time format necessary for the presentation, the server MUST respond using 456 (Header Field Not Valid for Resource) and include the Accept-Ranges header with the range unit formats supported for the resource.
客户端必须在请求中包含Accept Ranges标头，以指示Range标头中支持的所有单位格式。这允许服务器知道在未来会话相关响应中可能使用的格式，例如请求中没有任何范围的播放响应。如果客户端不支持演示所需的时间格式，服务器必须使用456（标头字段对资源无效）进行响应，并使用资源支持的范围单位格式包含Accept Ranges标头。
In a SETUP response, the server MUST include the Accept-Ranges header (see Section 18.5) to indicate which time formats are acceptable to use for this media resource.
在设置响应中，服务器必须包含Accept Ranges标头（请参阅第18.5节），以指示此媒体资源可以使用哪些时间格式。
The SETUP 200 OK response MUST include the Media-Properties header (see Section 18.29). The combination of the parameters of the Media-Properties header indicates the nature of the content present in the session (see also Section 4.7). For example, a live stream with time shifting is indicated by
SETUP 200 OK响应必须包括介质属性标题（参见第18.29节）。媒体属性标题的参数组合表示会话中内容的性质（另请参见第4.7节）。例如，具有时间偏移的实时流由
o Random access set to Random-Access,
o 随机访问设置为随机访问，
o Content Modifications set to Time-Progressing, and
o 内容修改设置为时间进度，以及
o Retention set to Time-Duration (with specific recording window time value).
o 保留时间设置为持续时间（具有特定的录制窗口时间值）。
The SETUP 200 OK response MUST include the Media-Range header (see Section 18.30) if the media is Time-Progressing.
如果介质正在进行时间处理，则SETUP 200 OK响应必须包括介质范围标题（参见第18.30节）。
A basic example for SETUP:
设置的一个基本示例：
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, clock
User-Agent: PhonyClient/1.2
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302
Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, clock
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 302
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.1
Session: QKyjN8nt2WqbWw4tIYof52;timeout=60
Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/
"192.0.2.53:4589"; src_addr="198.51.100.241:6256"/
"198.51.100.241:6257"; ssrc=2A3F93ED
Accept-Ranges: npt
Media-Properties: Random-Access=3.2, Time-Progressing,
Time-Duration=3600.0
Media-Range: npt=0-2893.23
S->C: RTSP/2.0 200 OK
CSeq: 302
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.1
Session: QKyjN8nt2WqbWw4tIYof52;timeout=60
Transport: RTP/AVP;unicast;dest_addr="192.0.2.53:4588"/
"192.0.2.53:4589"; src_addr="198.51.100.241:6256"/
"198.51.100.241:6257"; ssrc=2A3F93ED
Accept-Ranges: npt
Media-Properties: Random-Access=3.2, Time-Progressing,
Time-Duration=3600.0
Media-Range: npt=0-2893.23
In the above example, the client wants to create an RTSP session containing the media resource "rtsp://example.com/foo/bar/baz.rm". The transport parameters acceptable to the client are either RTP/AVP/ UDP (UDP per default) to be received on client port 4588 and 4589 at the address the RTSP setup connection comes from or RTP/AVP interleaved on the RTSP control channel. The server selects the RTP/AVP/UDP transport and adds the address and ports it will send and receive RTP and RTCP from, and the RTP SSRC that will be used by the server.
在上面的示例中，客户端希望创建包含媒体资源的RTSP会话“rtsp://example.com/foo/bar/baz.rm". 客户机可接受的传输参数为RTP/AVP/UDP（默认为UDP），将在RTSP设置连接所来自的地址的客户机端口4588和4589上接收，或在RTSP控制通道上交叉接收RTP/AVP。服务器选择RTP/AVP/UDP传输，并添加它将从中发送和接收RTP和RTCP的地址和端口，以及服务器将使用的RTP SSRC。
The server MUST generate a session identifier in response to a successful SETUP request unless a SETUP request to a server includes a session identifier or a Pipelined-Requests header referencing an existing session context. In that latter case, the server MUST bundle this SETUP request into the existing session (aggregated session) or return a 459 (Aggregate Operation Not Allowed) error code (see Section 17.4.23). An aggregate control URI MUST be used to control an aggregated session. This URI MUST be different from the stream control URIs of the individual media streams included in the aggregate (see Section 13.4.2 for aggregated sessions and for the particular URIs see Appendix D.1.1). The aggregate control URI is to be specified by the session description if the server supports aggregated control and aggregated control is desired for the session.
服务器必须生成会话标识符以响应成功的设置请求，除非对服务器的设置请求包含引用现有会话上下文的会话标识符或流水线请求标头。在后一种情况下，服务器必须将此设置请求捆绑到现有会话（聚合会话）中，或返回459（不允许聚合操作）错误代码（参见第17.4.23节）。必须使用聚合控制URI来控制聚合会话。该URI必须不同于聚合中包含的单个媒体流的流控制URI（聚合会话见第13.4.2节，特定URI见附录D.1.1）。如果服务器支持聚合控制且会话需要聚合控制，则聚合控制URI将由会话描述指定。
However, even if aggregated control is offered, the client MAY choose not to set up the session in aggregated control. If an aggregate control URI is not specified in the session description, it is normally an indication that non-aggregated control should be used.
但是，即使提供了聚合控制，客户端也可以选择不在聚合控制中设置会话。如果会话描述中未指定聚合控件URI，则通常表示应使用非聚合控件。
The SETUP of media streams in an aggregate that has not been given an aggregated control URI is unspecified.
未指定未提供聚合控制URI的聚合中媒体流的设置。
While the session ID sometimes carries enough information for aggregate control of a session, the aggregate control URI is still important for some methods such as SET_PARAMETER where the control URI enables the resource in question to be easily identified. The aggregate control URI is also useful for proxies, enabling them to route the request to the appropriate server, and for logging, where it is useful to note the actual resource on which a request was operating.
虽然会话ID有时携带足够的信息用于会话的聚合控制，但聚合控制URI对于某些方法（例如SET_参数）仍然很重要，其中控制URI使相关资源能够容易识别。聚合控制URI对于代理也很有用，使它们能够将请求路由到适当的服务器，对于日志记录也很有用，在日志记录中，记录请求运行的实际资源很有用。
A session will exist until it is either removed by a TEARDOWN request or is timed out by the server. The server MAY remove a session that has not demonstrated liveness signs from the client(s) within a certain timeout period. The default timeout value is 60 seconds; the server MAY set this to a different value and indicate so in the timeout field of the Session header in the SETUP response. For further discussion, see Section 18.49. Signs of liveness for an RTSP session include any RTSP requests from a client that contain a Session header with the ID for that session, as well as RTCP sender or receiver reports if RTP is used to transport the underlying media stream. RTCP sender reports may, for example, be received in session where the server is invited into a conference session and are thus valid as a liveness indicator.
会话将一直存在，直到它被拆卸请求删除或被服务器超时为止。服务器可能会在特定的超时时间内从客户端删除未显示活跃迹象的会话。默认超时值为60秒；服务器可以将其设置为不同的值，并在设置响应中会话头的超时字段中指示。有关进一步讨论，请参见第18.49节。RTSP会话的活跃迹象包括来自客户端的任何RTSP请求，该请求包含会话头和会话ID，以及RTP发送方或接收方报告（如果RTP用于传输底层媒体流）。例如，可以在会话中接收RTCP发送方报告，其中服务器被邀请参加会议会话，因此作为活跃度指示器有效。
If a SETUP request on a session fails for any reason, the session state, as well as transport and other parameters for associated streams, MUST remain unchanged from their values as if the SETUP request had never been received by the server.
如果会话上的设置请求因任何原因失败，则会话状态以及关联流的传输和其他参数的值必须保持不变，就像服务器从未收到设置请求一样。
A client MAY issue a SETUP request for a stream that is already set up or playing in the session to change transport parameters, which a server MAY allow. If it does not allow the changing of parameters, it MUST respond with error 455 (Method Not Valid in This State). The reasons to support changing transport parameters include allowing application-layer mobility and flexibility to utilize the best available transport as it becomes available. If a client receives a 455 error when trying to change transport parameters while the server is in Play state, it MAY try to put the server in Ready state using PAUSE before issuing the SETUP request again. If that also fails,
客户端可能会对会话中已设置或正在播放的流发出设置请求，以更改传输参数，这是服务器允许的。如果不允许更改参数，则必须响应错误455（此状态下的方法无效）。支持更改传输参数的原因包括允许应用程序层移动性和灵活性，以便在可用时利用最佳可用传输。当服务器处于播放状态时，如果客户端在尝试更改传输参数时收到455错误，则在再次发出设置请求之前，它可能会尝试使用暂停将服务器置于就绪状态。如果这也失败了，
the changing of transport parameters will require that the client perform a TEARDOWN of the affected media and then set it up again. For an aggregated session, not tearing down all the media at the same time will avoid the creation of a new session.
更改传输参数需要客户端对受影响的介质进行拆卸，然后重新设置。对于聚合会话，不同时拆下所有媒体将避免创建新会话。
All transport parameters MAY be changed. However, the primary usage expected is to either change the transport protocol completely, like switching from Interleaved TCP mode to UDP or vice versa, or to change the delivery address.
所有传输参数都可以更改。但是，预期的主要用途是完全更改传输协议，如从交错TCP模式切换到UDP模式，或反之亦然，或者更改传递地址。
In a SETUP response for a request to change the transport parameters while in Play state, the server MUST include the Range header to indicate at what point the new transport parameters will be used. Further, if RTP is used for delivery, the server MUST also include the RTP-Info header to indicate at what timestamp and RTP sequence number the change will take place. If both RTP-Info and Range are included in the response, the "rtp_time" parameter and start point in the Range header MUST be for the corresponding time, i.e., be used in the same way as for PLAY to ensure the correct synchronization information is available.
在设置响应中，对于在播放状态下更改传输参数的请求，服务器必须包含范围标头，以指示将在何时使用新的传输参数。此外，如果使用RTP进行交付，服务器还必须包含RTP Info标头，以指示更改将在什么时间戳和RTP序列号发生。如果响应中同时包含RTP信息和范围，则范围标头中的“RTP_时间”参数和起始点必须对应于相应的时间，即以与播放相同的方式使用，以确保提供正确的同步信息。
If the transport-parameters change that happened while in Play state results in a change of synchronization-related information, for example, changing RTP SSRC, the server MUST include the necessary synchronization information in the SETUP response. However, the server SHOULD avoid changing the synchronization information if possible.
如果在播放状态下发生的传输参数更改导致同步相关信息的更改，例如更改RTP SSRC，则服务器必须在设置响应中包含必要的同步信息。但是，如果可能，服务器应该避免更改同步信息。
This section describes the usage of the PLAY method in general, for aggregated sessions, and in different usage scenarios.
本节介绍PLAY方法的一般用法、聚合会话以及在不同使用场景中的用法。
The PLAY method tells the server to start sending data via the mechanism specified in SETUP and which part of the media should be played out. PLAY requests are valid when the session is in Ready or Play state. A PLAY request MUST include a Session header to indicate to which session the request applies.
播放方法告诉服务器开始通过设置中指定的机制发送数据，以及播放媒体的哪部分。当会话处于就绪或播放状态时，播放请求有效。播放请求必须包含一个会话头，以指示请求应用于哪个会话。
Upon receipt of the PLAY request, the server MUST position the normal play time to the beginning of the range specified in the received Range header, within the limits of the media resource and in accordance with the Seek-Style header (Section 18.47). It MUST deliver stream data until the end of the range if given, until a new PLAY request is received, until a PAUSE request (Section 13.5) is received, or until the end of the media is reached. If no Range
在收到播放请求后，服务器必须将正常播放时间定位到接收范围标头中指定范围的开始位置，在媒体资源的限制范围内，并符合搜索样式标头（第18.47节）。它必须传输流数据，直到范围结束（如果给定）、接收到新的播放请求、接收到暂停请求（第13.5节）或媒体结束。如果没有范围
header is present in the PLAY request, the server SHALL play from current pause point until the end of media. The pause point defaults at session start to the beginning of the media. For media that is time-progressing and has no retention, the pause point will always be set equal to NPT "now", i.e., the current delivery point. The pause point may also be set to a particular point in the media by the PAUSE method; see Section 13.6. The pause point for media that is currently playing is equal to the current media position. For time-progressing media with time-limited retention, if the pause point represents a position that is older than what is retained by the server, the pause point will be moved to the oldest retained position.
如果播放请求中存在报头，服务器将从当前暂停点播放到媒体结束。暂停点默认为从会话开始到媒体开始。对于随时间推移而没有保留的介质，暂停点将始终设置为等于NPT“now”，即当前交付点。也可以通过暂停方法将暂停点设置为媒体中的特定点；见第13.6节。当前播放的媒体的暂停点等于当前媒体位置。对于保留时间有限的按时间进行的介质，如果暂停点表示的位置比服务器保留的位置旧，则暂停点将移动到保留时间最早的位置。
What range values are valid depends on the type of content. For content that isn't time-progressing, the range value is valid if the given range is part of any media within the aggregate. In other words, the valid media range for the aggregate is the union of all of the media components in the aggregate. If a given range value points outside of the media, the response MUST be the 457 (Invalid Range) error code and include the Media-Range header (Section 18.30) with the valid range for the media. Except for time-progressing content where the client requests a start point prior to what is retained, the start point is adjusted to the oldest retained content. For a start point that is beyond the media front edge, i.e., beyond the current value for "now", the server SHALL adjust the start value to the current front edge. The Range header's stop point value may point beyond the current media edge. In that case, the server SHALL deliver media from the requested (and possibly adjusted) start point until the first of either the provided stop point or the end of the media. Please note that if one simply wants to play from a particular start point until the end of media, using a Range header with an implicit stop point is RECOMMENDED.
有效的范围值取决于内容的类型。对于非时间进度的内容，如果给定范围是聚合中任何媒体的一部分，则范围值有效。换句话说，聚合的有效媒体范围是聚合中所有媒体组件的并集。如果给定的范围值指向介质之外，则响应必须为457（无效范围）错误代码，并包括介质范围标题（第18.30节）和介质的有效范围。除了客户端在保留内容之前请求起始点的时间进度内容外，起始点将调整为最早保留的内容。对于超出媒体前缘的起始点，即超出“now”的当前值，服务器应将起始值调整为当前前缘。范围标头的停止点值可能超出当前媒体边缘。在这种情况下，服务器应从请求的（或可能调整的）起始点传送介质，直到提供的第一个停止点或介质的末端。请注意，如果您只是想从特定的开始点播放到媒体结束，建议使用带有隐式停止点的范围标头。
If a client requests to start playing at the end of media, either explicitly with a Range header or implicitly with a pause point that is at the end of media, a 457 (Invalid Range) error MUST be sent and include the Media-Range header (Section 18.30). It is specified below that the Range header also must be included in the response and that it will carry the pause point in the media, in the case of the session being in Ready State. Note that this also applies if the pause point or requested start point is at the beginning of the media and a Scale header (Section 18.46) is included with a negative value (playing backwards).
如果客户端请求在媒体结束时开始播放，无论是显式使用范围标头还是隐式使用媒体结束时的暂停点，都必须发送457（无效范围）错误，并包括媒体范围标头（第18.30节）。下面规定，响应中还必须包含范围标头，并且在会话处于就绪状态时，它将在媒体中携带暂停点。请注意，如果暂停点或请求的起始点位于介质的开头，且标尺标题（第18.46节）包含负值（向后播放），则这也适用。
For media with random access properties, a client may indicate which policy for start point selection the server should use. This is done by including the Seek-Style header (Section 18.47) in the PLAY
对于具有随机访问属性的介质，客户机可能会指示服务器应使用的起始点选择策略。这是通过在游戏中包括Seek样式标题（第18.47节）来实现的
request. The Seek-Style applied will affect the content of the Range header as it will be adjusted to indicate from what point the media actually is delivered.
要求应用的搜索样式将影响范围标头的内容，因为它将被调整以指示媒体实际从哪个点传送。
A client desiring to play the media from the beginning MUST send a PLAY request with a Range header pointing at the beginning, e.g., "npt=0-". If a PLAY request is received without a Range header and media delivery has stopped at the end, the server SHOULD respond with a 457 (Invalid Range) error response. In that response, the current pause point MUST be included in a Range header.
希望从开始播放媒体的客户端必须发送一个播放请求，其范围标头指向开始，例如“npt=0-”。如果接收到播放请求时没有范围标头，并且媒体传送在结束时停止，服务器应以457（无效范围）错误响应进行响应。在该响应中，当前暂停点必须包含在范围标头中。
All range specifiers in this specification allow for ranges with an implicit start point (e.g., "npt=-30"). When used in a PLAY request, the server treats this as a request to start or resume delivery from the current pause point, ending at the end time specified in the Range header. If the pause point is located later than the given end value, a 457 (Invalid Range) response MUST be returned.
本规范中的所有范围说明符都允许具有隐式起点的范围（例如，“npt=-30”）。在播放请求中使用时，服务器将其视为从当前暂停点开始或恢复传送的请求，在范围标头中指定的结束时间结束。如果暂停点的位置晚于给定的结束值，则必须返回457（无效范围）响应。
The example below will play seconds 10 through 25. It also requests that the server deliver media from the first random access point prior to the indicated start point.
下面的示例将播放10秒到25秒。它还请求服务器在指定的起点之前从第一个随机访问点交付媒体。
C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0
CSeq: 835
Session: ULExwZCXh2pd0xuFgkgZJW
Range: npt=10-25
Seek-Style: RAP
User-Agent: PhonyClient/1.2
C->S: PLAY rtsp://audio.example.com/audio RTSP/2.0
CSeq: 835
Session: ULExwZCXh2pd0xuFgkgZJW
Range: npt=10-25
Seek-Style: RAP
User-Agent: PhonyClient/1.2
Servers MUST include a Range header in any PLAY response, even if no Range header was present in the request. The response MUST use the same format as the request's Range header contained. If no Range header was in the request, the format used in any previous PLAY request within the session SHOULD be used. If no format has been indicated in a previous request, the server MAY use any time format supported by the media and indicated in the Accept-Ranges header in the SETUP request. It is RECOMMENDED that NPT is used if supported by the media.
服务器必须在任何播放响应中包含范围标头，即使请求中不存在范围标头。响应必须使用与包含的请求范围标头相同的格式。如果请求中没有范围标头，则应使用会话中以前任何播放请求中使用的格式。如果在以前的请求中未指明格式，服务器可以使用介质支持的任何时间格式，并在安装请求的Accept Ranges标头中指明。如果媒体支持，建议使用NPT。
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 using a Range header with the pause point as the explicit start point and an implicit stop point. For time-progressing content, where the pause-point moves with real-time due to limited retention, the current pause point is returned. For sessions in Play state, the current playout point and
对于播放请求的任何错误响应，服务器的响应取决于当前会话状态。如果会话处于就绪状态，则使用范围标头返回当前暂停点，其中暂停点作为显式起点和隐式停止点。对于按时间推进的内容，如果暂停点由于保留时间有限而实时移动，则返回当前暂停点。对于处于播放状态的会话，当前播放点和
the remaining parts of the range request are returned. For any media with retention longer than 0 seconds, the currently valid Media-Range header SHALL also be included in the response.
返回范围请求的其余部分。对于保留时间超过0秒的任何介质，响应中还应包括当前有效的介质范围标头。
A PLAY response MAY include a header carrying synchronization information. As the information necessary is dependent on the media-transport format, further rules specifying the header and its usage are needed. For RTP the RTP-Info header is specified, see Section 18.45, and used in the following example.
播放响应可以包括承载同步信息的报头。由于所需信息取决于媒体传输格式，因此需要进一步的规则来指定报头及其用法。对于RTP，指定了RTP信息头，请参见第18.45节，并在以下示例中使用。
Here is a simple example for a single audio stream where the client requests the media starting from 3.52 seconds and to the end. The server sends a 200 OK response with the actual play time, which is 10 ms prior (3.51), and the RTP-Info header that contains the necessary parameters for the RTP stack.
这里是一个简单的单一音频流示例，其中客户端从3.52秒开始一直请求媒体。服务器发送一个200 OK响应，其中包含实际播放时间，即10毫秒之前（3.51），以及包含RTP堆栈所需参数的RTP Info头。
C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836
Session: ULExwZCXh2pd0xuFgkgZJW
Range: npt=3.52-
User-Agent: PhonyClient/1.2
C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836
Session: ULExwZCXh2pd0xuFgkgZJW
Range: npt=3.52-
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.0
Range: npt=3.51-324.39
Seek-Style: First-Prior
Session: ULExwZCXh2pd0xuFgkgZJW
RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTSP/2.0 200 OK
CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.0
Range: npt=3.51-324.39
Seek-Style: First-Prior
Session: ULExwZCXh2pd0xuFgkgZJW
RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.51
Media duration=0.16 seconds
S->C: RTP Packet TS=2345962545 => NPT=3.51
Media duration=0.16 seconds
The server replies with the actual start point that will be delivered. This may differ from the requested range if alignment of the requested range to valid frame boundaries is required for the media source. Note that some media streams in an aggregate may need to be delivered from even earlier points. Also, some media formats have a very long duration per individual data unit; therefore, it might be necessary for the client to parse the data unit, and select where to start. The server SHALL also indicate which policy it uses for selecting the actual start point by including a Seek-Style header.
服务器用将要传递的实际起点进行响应。如果媒体源需要将请求的范围与有效帧边界对齐，则这可能与请求的范围不同。请注意，聚合中的某些媒体流可能需要从更早的点交付。此外，某些媒体格式在每个数据单元中的持续时间非常长；因此，客户端可能需要解析数据单元，并选择从何处开始。服务器还应通过包含Seek样式头来指示其用于选择实际起点的策略。
In the following example, the client receives the first media packet that stretches all the way up and past the requested playtime. Thus, it is the client's decision whether to render to the user the time between 3.52 and 7.05 or to skip it. In most cases, it is probably most suitable not to render that time period.
在下面的示例中，客户端接收到第一个媒体包，该媒体包一直向上延伸并超过请求的播放时间。因此，客户决定是向用户呈现3.52到7.05之间的时间，还是跳过它。在大多数情况下，不渲染该时间段可能是最合适的。
C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836
Session: ZGGyCJOs8xaLkdNK2dmxQO
Range: npt=7.05-
User-Agent: PhonyClient/1.2
C->S: PLAY rtsp://example.com/audio RTSP/2.0
CSeq: 836
Session: ZGGyCJOs8xaLkdNK2dmxQO
Range: npt=7.05-
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.0
Session: ZGGyCJOs8xaLkdNK2dmxQO
Range: npt=3.52-
Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTSP/2.0 200 OK
CSeq: 836
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.0
Session: ZGGyCJOs8xaLkdNK2dmxQO
Range: npt=3.52-
Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTP Packet TS=2345962545 => NPT=3.52
Duration=4.15 seconds
S->C: RTP Packet TS=2345962545 => NPT=3.52
Duration=4.15 seconds
After playing the desired range, the presentation does NOT change to the Ready state, media delivery simply stops. If it is necessary to put the stream into the Ready state, a PAUSE request MUST be issued. A PLAY request while the stream is still in the Play state is legal and can be issued without an intervening PAUSE request. Such a request MUST replace the current PLAY action with the new one requested, i.e., being handled in the same way as if as the request was received in Ready state. In the case that the range in the Range header has an implicit start time ("-endtime"), the server MUST continue to play from where it currently was until the specified endpoint. This is useful to change the end to at another point than in the previous request.
播放所需范围后，演示文稿不会更改为就绪状态，媒体传送将停止。如果需要将流置于就绪状态，则必须发出暂停请求。流仍处于播放状态时的播放请求是合法的，可以在没有中间暂停请求的情况下发出。此类请求必须用新请求的播放操作替换当前播放操作，即，以与在就绪状态下接收请求相同的方式进行处理。如果范围标头中的范围具有隐式开始时间（“-endtime”），则服务器必须从当前所在位置继续播放，直到指定的端点。这对于在上一个请求之外的其他点将结束更改为非常有用。
The following example plays the whole presentation starting at SMPTE time code 0:10:20 until the end of the clip. Note: the RTP-Info headers have been broken into several lines, where subsequent lines start with whitespace as allowed by the syntax.
以下示例从SMPTE时间代码0:10:20开始播放整个演示文稿，直到剪辑结束。注意：RTP信息头被分成了几行，后面的几行按照语法允许以空格开头。
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0
CSeq: 833
Session: N465Wvsv0cjUy6tLqINkcf
Range: smpte=0:10:20-
User-Agent: PhonyClient/1.2
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/2.0
CSeq: 833
Session: N465Wvsv0cjUy6tLqINkcf
Range: smpte=0:10:20-
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 833
Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: N465Wvsv0cjUy6tLqINkcf
Server: PhonyServer/1.0
Range: smpte=0:10:22-0:15:45
Seek-Style: Next
RTP-Info:url="rtsp://example.com/twister.en"
ssrc=0D12F123:seq=14783;rtptime=2345962545
S->C: RTSP/2.0 200 OK
CSeq: 833
Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: N465Wvsv0cjUy6tLqINkcf
Server: PhonyServer/1.0
Range: smpte=0:10:22-0:15:45
Seek-Style: Next
RTP-Info:url="rtsp://example.com/twister.en"
ssrc=0D12F123:seq=14783;rtptime=2345962545
For playing back a recording of a live presentation, it may be desirable to use clock units:
为了回放实况演示文稿的录制，可能需要使用时钟单元：
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0
CSeq: 835
Session: N465Wvsv0cjUy6tLqINkcf
Range: clock=19961108T142300Z-19961108T143520Z
User-Agent: PhonyClient/1.2
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/2.0
CSeq: 835
Session: N465Wvsv0cjUy6tLqINkcf
Range: clock=19961108T142300Z-19961108T143520Z
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 835
Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: N465Wvsv0cjUy6tLqINkcf
Server: PhonyServer/1.0
Range: clock=19961108T142300Z-19961108T143520Z
Seek-Style: Next
RTP-Info:url="rtsp://example.com/meeting.en"
ssrc=0D12F123:seq=53745;rtptime=484589019
S->C: RTSP/2.0 200 OK
CSeq: 835
Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: N465Wvsv0cjUy6tLqINkcf
Server: PhonyServer/1.0
Range: clock=19961108T142300Z-19961108T143520Z
Seek-Style: Next
RTP-Info:url="rtsp://example.com/meeting.en"
ssrc=0D12F123:seq=53745;rtptime=484589019
PLAY requests can operate on sessions controlling a single media stream and on aggregated sessions controlling multiple media streams.
播放请求可以在控制单个媒体流的会话上操作，也可以在控制多个媒体流的聚合会话上操作。
In an aggregated session, the PLAY request MUST contain an aggregated control URI. A server MUST respond with a 460 error (Only Aggregate Operation Allowed) if the client PLAY Request-URI is for a single media. The media in an aggregate MUST be played in sync. If a client wants individual control of the media, it needs to use separate RTSP sessions for each media.
在聚合会话中，播放请求必须包含聚合控件URI。如果客户端播放请求URI用于单个媒体，则服务器必须响应460错误（仅允许聚合操作）。聚合中的媒体必须同步播放。如果客户端希望单独控制介质，则需要为每个介质使用单独的RTSP会话。
For aggregated sessions where the initial SETUP request (creating a session) is followed by one or more additional SETUP requests, a PLAY request MAY be pipelined (Section 12) after those additional SETUP requests without awaiting their responses. This procedure can reduce the delay from the start of session establishment until media playout has started with one RTT. However, a client needs to be aware that using this procedure will result in the playout of the server state established at the time of processing the PLAY, i.e., after the processing of all the requests prior to the PLAY request in the pipeline. This state may not be the intended one due to failure of any of the prior requests. A client can easily determine this based on the responses from those requests. In case of failure, the client can halt the media playout using PAUSE and try to establish the intended state again before issuing another PLAY request.
对于初始设置请求（创建会话）后接一个或多个附加设置请求的聚合会话，可以在这些附加设置请求之后管道化播放请求（第12节），而不等待它们的响应。此过程可以减少从会话建立开始到媒体播放开始（使用一个RTT）之间的延迟。然而，客户机需要知道，使用此过程将导致在处理播放时建立的服务器状态的播放，即，在处理管道中播放请求之前的所有请求之后。由于任何先前请求的失败，该状态可能不是预期状态。客户机可以根据这些请求的响应轻松确定这一点。如果出现故障，客户端可以使用“暂停”停止媒体播放，并在发出另一个播放请求之前再次尝试建立预期状态。
Clients can issue PLAY requests while the stream is in Play state and thus updating their request.
客户端可以在流处于播放状态时发出播放请求，从而更新其请求。
The important difference compared to a PLAY request in Ready state is the handling of the current play point and how the Range header in the request is constructed. The session is actively playing media and the play point will be moving, making the exact time a request will take effect hard to predict. Depending on how the PLAY header appears, two different cases exist: total replacement or continuation. A total replacement is signaled by having the first range specification have an explicit start value, e.g., "npt=45-" or "npt=45-60", in which case the server stops playout at the current playout point and then starts delivering media according to the Range header. This is equivalent to having the client first send a PAUSE and then a new PLAY request that isn't based on the pause point. In the case of continuation, the first range specifier has an implicit start point and an explicit stop value (Z), e.g., "npt=-60", which indicate that it MUST convert the range specifier being played prior to this PLAY request (X to Y) into (X to Z) and continue as if this was the request originally played. If the current delivery point is beyond the stop point, the server SHALL immediately pause delivery. As the request has been completed successfully, it shall be responded to with a 200 OK response. A PLAY_NOTIFY with end-of-stream is also sent to indicate the actual stop point. The pause point is set to the requested stop point.
与就绪状态下的播放请求相比，重要的区别在于当前播放点的处理以及请求中范围标头的构造方式。会话正在积极播放媒体，播放点将移动，因此很难预测请求生效的确切时间。根据播放标题的显示方式，存在两种不同的情况：完全替换或继续。通过使第一个范围规范具有明确的开始值（例如，“npt=45-”或“npt=45-60”）来表示完全替换，在这种情况下，服务器在当前播放点停止播放，然后根据范围标头开始传送媒体。这相当于让客户端先发送暂停，然后发送不基于暂停点的新播放请求。在继续的情况下，第一个范围说明符有一个隐式的起始点和一个显式的停止值（Z），例如“npt=-60”，这表明它必须将在该播放请求（X到Y）之前播放的范围说明符转换为（X到Z），并像最初播放的请求一样继续。如果当前交付点超出停止点，服务器应立即暂停交付。由于请求已成功完成，应以200 OK响应进行响应。还将发送带有流结束的播放通知，以指示实际停止点。暂停点设置为请求的停止点。
The following is an example of this behavior: The server has received requests to play ranges 10 to 15. If the new PLAY request arrives at the server 4 seconds after the previous one, it will take effect
以下是此行为的示例：服务器已收到播放范围10到15的请求。如果新的播放请求在前一个播放请求之后4秒到达服务器，则该请求将生效
while the server still plays the first range (10-15). The server changes the current play to continue to 25 seconds, i.e., the equivalent single request would be PLAY with "range: npt=10-25".
而服务器仍在播放第一个音域（10-15）。服务器将当前播放更改为继续25秒，即，等效的单个请求将在“范围：npt=10-25”的情况下播放。
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=10-15
User-Agent: PhonyClient/1.2
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=10-15
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0
Range: npt=10-15
Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193
S->C: RTSP/2.0 200 OK
CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0
Range: npt=10-15
Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835
Session: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=-25
User-Agent: PhonyClient/1.2
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835
Session: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=-25
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 835
Date: Thu, 23 Jan 1997 15:35:09 GMT
Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0
Range: npt=14-25
Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193
S->C: RTSP/2.0 200 OK
CSeq: 835
Date: Thu, 23 Jan 1997 15:35:09 GMT
Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0
Range: npt=14-25
Seek-Style: Next
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193
A common use of a PLAY request while in Play state is changing the scale of the media, i.e., entering or leaving fast forward or fast rewind. The client can issue an updating PLAY request that is either a continuation or a complete replacement, as discussed above this section. Below is an example of a client that is requesting a fast forward (scale = 2) without giving a stop point and then a change from fast forward to regular playout (scale = 1). In the second PLAY
在播放状态下，播放请求的常见用途是改变媒体的比例，即进入或离开快进或快退。客户机可以发出更新播放请求，该请求可以是继续或完全替换，如本节上文所述。下面是一个客户机的示例，该客户机在不给出停止点的情况下请求快进（比例=2），然后从快进更改为常规播放（比例=1）。在第二出戏里
request, the time is set explicitly to be wherever the server currently plays out (npt=now-) and the server responds with the actual playback point where the new scale actually takes effect (npt=02:17:27.144-).
请求时，时间显式设置为服务器当前播放的位置（npt=now-），服务器用实际播放点响应，新音阶实际生效的位置（npt=02:17:27.144-）。
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2034
Session: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=now-
Scale: 2.0
User-Agent: PhonyClient/1.2
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2034
Session: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=now-
Scale: 2.0
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 2034
Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0
Range: npt=02:17:21.394-
Seek-Style: Next
Scale: 2.0
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193
S->C: RTSP/2.0 200 OK
CSeq: 2034
Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0
Range: npt=02:17:21.394-
Seek-Style: Next
Scale: 2.0
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193
[playing in fast forward and now returning to scale = 1]
[快进，现在回到音阶=1]
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2035
Session: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=now-
Scale: 1.0
User-Agent: PhonyClient/1.2
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2035
Session: apzA8LnjQ5KWTdw0kUkiRh
Range: npt=now-
Scale: 1.0
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 2035
Date: Thu, 23 Jan 1997 15:35:09 GMT
Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0
Range: npt=02:17:27.144-
Seek-Style: Next
Scale: 1.0
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193
S->C: RTSP/2.0 200 OK
CSeq: 2035
Date: Thu, 23 Jan 1997 15:35:09 GMT
Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0
Range: npt=02:17:27.144-
Seek-Style: Next
Scale: 1.0
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193
On-demand media is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29):
在以下情况下，按需介质由设置响应中介质属性标题的内容指示（另见第18.29节）：
o the Random Access property is set to Random-Access;
o 随机访问属性设置为随机访问；
o the Content Modifications property is set to Immutable;
o 内容修改属性设置为不可变；
o the Retention property is set to Unlimited or Time-Limited.
o 保留属性设置为无限或有时间限制。
Playing on-demand media follows the general usage as described in Section 13.4.1.
按需播放媒体遵循第13.4.1节所述的一般用法。
Dynamic on-demand media is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29):
动态按需介质由设置响应中的介质属性标题的内容指示（另见第18.29节）：
o the Random Access property is set to Random-Access;
o 随机访问属性设置为随机访问；
o the Content Modifications property is set to Dynamic;
o “内容修改”属性设置为“动态”；
o the Retention property is set to Unlimited or Time-Limited.
o 保留属性设置为无限或有时间限制。
Playing on-demand media follows the general usage as described in Section 13.4.1 as long as the media has not been changed.
只要媒体没有改变，按需播放媒体应遵循第13.4.1节所述的一般用法。
There are two ways for the client to be informed about changes of media resources in Play state. The first being that the client will receive a PLAY_NOTIFY request with the Notify-Reason header set to media-properties-update (see Section 13.5.2). The client can use the value of the Media-Range header to decide further actions, if the Media-Range header is present in the PLAY_NOTIFY request. The second way is that the client issues a GET_PARAMETER request without a body but including a Media-Range header. The 200 OK response MUST include the current Media-Range header (see Section 18.30).
在播放状态下，有两种方式可以通知客户端媒体资源的更改。首先，客户端将收到一个PLAY_NOTIFY请求，其中NOTIFY Reason标头设置为media properties update（媒体属性更新）（参见第13.5.2节）。如果PLAY_NOTIFY请求中存在媒体范围标头，则客户端可以使用媒体范围标头的值来决定进一步的操作。第二种方法是，客户端发出GET_参数请求，该请求没有正文，但包含媒体范围标头。200 OK响应必须包括当前媒体范围标题（参见第18.30节）。
Live media is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29):
在以下情况下，实时媒体由设置响应中媒体属性标题的内容指示（另请参见第18.29节）：
o the Random Access property is set to No-Seeking;
o 将随机访问属性设置为不查找；
o the Content Modifications property is set to Time-Progressing;
o 内容修改属性设置为时间进度；
o the Retention property's Time-Duration is set to 0.0.
o 保留属性的持续时间设置为0.0。
For live media, the SETUP 200 OK response MUST include the Media-Range header (see Section 18.30).
对于实时媒体，SETUP 200 OK响应必须包括媒体范围标题（参见第18.30节）。
A client MAY send PLAY requests without the Range header. If the request includes the Range header, it MUST use a symbolic value representing "now". For NPT, that range specification is "npt=now-". The server MUST include the Range header in the response, and it MUST indicate an explicit time value and not a symbolic value. In other words, "npt=now-" cannot be used in the response. Instead, the time since session start is recommended, expressed as an open interval, e.g., "npt=96.23-". An absolute time value (clock) for the corresponding time MAY be given, i.e., "clock=20030213T143205Z-". The Absolute Time format can only be used if the client has shown support for it using the Accept-Ranges header.
客户端可以发送不带范围标头的播放请求。如果请求包含范围标头，则必须使用表示“now”的符号值。对于NPT，该范围规格为“NPT=now-”。服务器必须在响应中包含Range头，并且它必须指示一个显式的时间值，而不是符号值。换句话说，“npt=now-”不能用于响应。相反，建议使用会话开始后的时间，以开放间隔表示，例如“npt=96.23-”。可给出对应时间的绝对时间值（时钟），即“时钟=20030213T143205Z-”。只有当客户端使用Accept Ranges标头表示支持绝对时间格式时，才能使用绝对时间格式。
Certain media servers may offer recording services of live sessions to their clients. This recording would normally be from the beginning of the media session. Clients can randomly access the media between now and the beginning of the media session. This live media with recording is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29):
某些媒体服务器可能会向其客户端提供实时会话的录制服务。此录制通常从媒体会话开始。从现在到媒体会话开始，客户端可以随机访问媒体。当出现以下情况时（另请参见第18.29节），设置响应中的“介质属性”标题的内容将指示此带录制的实时介质：
o the Random Access property is set to Random-Access;
o 随机访问属性设置为随机访问；
o the Content Modifications property is set to Time-Progressing;
o 内容修改属性设置为时间进度；
o the Retention property is set to Time-Limited or Unlimited
o 保留属性设置为“时间限制”或“无限制”
The SETUP 200 OK response MUST include the Media-Range header (see Section 18.30) for this type of media. For live media with recording, the Range header indicates the current delivery point in the media and the Media-Range header indicates the currently available media window around the current time. This window can cover recorded content in the past (seen from current time in the media) or recorded content in the future (seen from current time in the media). The server adjusts the delivery point to the requested border of the window. If the client requests a delivery point that is located outside the recording window, e.g., if the requested point is too far in the past, the server selects the oldest point in the recording. The considerations in Section 13.5.3 apply if a client requests delivery with scale (Section 18.46) values other than 1.0 (normal playback rate) while delivering live media with recording.
SETUP 200 OK（设置200正常）响应必须包括该类型介质的介质范围标题（见第18.30节）。对于带有录制功能的实时介质，范围标头表示介质中的当前传送点，介质范围标头表示当前时间周围的当前可用介质窗口。此窗口可以覆盖过去录制的内容（从媒体当前时间查看）或将来录制的内容（从媒体当前时间查看）。服务器将传递点调整为窗口的请求边框。如果客户端请求位于录制窗口之外的传送点，例如，如果请求的点过去太远，服务器将选择录制中最早的点。如果客户在交付带录制的实时媒体时，要求使用1.0（正常播放速率）以外的缩放（第18.46节）值交付，则第13.5.3节中的注意事项适用。
Certain media servers may offer time-shift services to their clients. This time shift records a fixed interval in the past, i.e., a sliding window recording mechanism, but not past this interval. Clients can randomly access the media between now and the interval. This live media with recording is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29):
某些媒体服务器可能会向其客户端提供时移服务。该时移记录过去的固定间隔，即滑动窗口记录机制，但不超过该间隔。从现在到间隔期间，客户端可以随机访问媒体。当出现以下情况时（另请参见第18.29节），设置响应中的“介质属性”标题的内容将指示此带录制的实时介质：
o the Random Access property is set to Random-Access;
o 随机访问属性设置为随机访问；
o the Content Modifications property is set to Time-Progressing;
o 内容修改属性设置为时间进度；
o the Retention property is set to Time-Duration and a value indicating the recording interval (>0).
o Retention属性设置为Time Duration和一个指示录制间隔（>0）的值。
The SETUP 200 OK response MUST include the Media-Range header (see Section 18.30) for this type of media. For live media with recording, the Range header indicates the current time in the media and the Media-Range header indicates a window around the current time. This window can cover recorded content in the past (seen from current time in the media) or recorded content in the future (seen from current time in the media). The server adjusts the play point to the requested border of the window, if the client requests a play point that is located outside the recording windows, e.g., if requested too far in the past, the server selects the oldest range in the recording. The considerations in Section 13.5.3 apply if a client requests delivery using a scale (Section 18.46) value other than 1.0 (normal playback rate) while delivering live media with time-shift.
SETUP 200 OK（设置200正常）响应必须包括该类型介质的介质范围标题（见第18.30节）。对于带有录制功能的实时媒体，范围标头表示媒体中的当前时间，媒体范围标头表示当前时间周围的窗口。此窗口可以覆盖过去录制的内容（从媒体当前时间查看）或将来录制的内容（从媒体当前时间查看）。如果客户端请求位于录制窗口之外的播放点（例如，如果过去请求的播放点太远），服务器会将播放点调整为请求的窗口边框，服务器会选择录制中最旧的范围。如果客户在交付带时移的实时媒体时，要求使用除1.0（正常播放速率）以外的刻度（第18.46节）值交付，则第13.5.3节中的注意事项适用。
The PLAY_NOTIFY method is issued by a server to inform a client about an asynchronous event for a session in Play state. The Session header MUST be presented in a PLAY_NOTIFY request and indicates the scope of the request. Sending of PLAY_NOTIFY requests requires a persistent connection between server and client; otherwise, there is no way for the server to send this request method to the client.
PLAY_NOTIFY方法由服务器发出，用于通知客户端处于播放状态的会话的异步事件。会话头必须在PLAY_NOTIFY请求中显示，并指示请求的范围。发送PLAY_NOTIFY请求需要服务器和客户端之间的持久连接；否则，服务器无法将此请求方法发送到客户端。
PLAY_NOTIFY requests have an end-to-end (i.e., server-to-client) scope, as they carry the Session header, and apply only to the given session. The client SHOULD immediately return a response to the server.
PLAY_NOTIFY请求具有端到端（即服务器到客户端）作用域，因为它们携带会话头，并且仅适用于给定会话。客户端应立即向服务器返回响应。
PLAY_NOTIFY requests MAY use both an aggregate control URI and individual media resource URIs, depending on the scope of the notification. This scope may have important distinctions for aggregated sessions, and each reason for a PLAY_NOTIFY request needs to specify the interpretation as well as if aggregated control URIs or individual URIs may be used in requests.
PLAY_NOTIFY请求可能同时使用聚合控件URI和单个媒体资源URI，具体取决于通知的范围。对于聚合会话，此范围可能有重要区别，PLAY_NOTIFY请求的每个原因都需要指定解释，以及请求中是否可以使用聚合控制URI或单个URI。
PLAY_NOTIFY requests can be used with a message body, depending on the value of the Notify-Reason header. It is described in the particular section for each Notify-Reason if a message body is used. However, currently there is no Notify-Reason that allows the use of a message body. In this case, there is a need to obey some limitations when adding new Notify-Reasons that intend to use a message body: the server can send any type of message body, but it is not ensured that the client can understand the received message body. This is related to DESCRIBE (see Section 13.2 ); but, in this particular case, the client can state its acceptable message bodies by using the Accept header. In the case of PLAY_NOTIFY, the server does not know which message bodies are understood by the client.
PLAY_NOTIFY请求可与消息正文一起使用，具体取决于NOTIFY Reason标头的值。如果使用消息正文，则在特定部分中针对每个通知原因进行描述。但是，目前没有允许使用消息正文的通知原因。在这种情况下，在添加打算使用消息正文的新通知原因时，需要遵守一些限制：服务器可以发送任何类型的消息正文，但不能确保客户端能够理解接收到的消息正文。这与描述有关（见第13.2节）；但是，在这种特殊情况下，客户机可以使用Accept头声明其可接受的消息体。在PLAY_NOTIFY的情况下，服务器不知道客户端理解哪些消息体。
The Notify-Reason header (see Section 18.32) specifies the reason why the server sends the PLAY_NOTIFY request. This is extensible and new reasons can be added in the future (see Section 22.8). In case the client does not understand the reason for the notification, it MUST respond with a 465 (Notification Reason Unknown) (Section 17.4.29) error code. This document defines how servers can send PLAY_NOTIFY with Notify-Reason values of these types:
Notify Reason标头（参见第18.32节）指定服务器发送PLAY_Notify请求的原因。这是可扩展的，将来可以添加新的原因（参见第22.8节）。如果客户不理解通知的原因，则必须使用465（通知原因未知）（第17.4.29节）错误代码进行响应。本文档定义了服务器如何发送具有以下类型的NOTIFY Reason值的PLAY_NOTIFY：
o end-of-stream (see Section 13.5.1);
o 河流末端（见第13.5.1节）；
o media-properties-update (see Section 13.5.2);
o 介质属性更新（见第13.5.2节）；
o scale-change (see Section 13.5.3).
o 刻度变化（见第13.5.3节）。
A PLAY_NOTIFY request with the Notify-Reason header set to end-of-stream indicates the completion or near completion of the PLAY request and the ending delivery of the media stream(s). The request MUST NOT be issued unless the server is in the Play state. The end of the media stream delivery notification may be used either to indicate a successful completion of the PLAY request currently being served or to indicate some error resulting in failure to complete the request. The Request-Status header (Section 18.42) MUST be included to indicate which request the notification is for and its completion status. The message response status codes (Section 8.1.1) are used to indicate how the PLAY request concluded. The sender of a PLAY_NOTIFY MAY issue an updated PLAY_NOTIFY, in the case of a
将NOTIFY Reason标头设置为end of stream的PLAY_NOTIFY请求表示播放请求的完成或接近完成以及媒体流的结束交付。除非服务器处于播放状态，否则不得发出请求。媒体流递送通知的结束可用于指示当前正在服务的播放请求的成功完成或指示导致未能完成请求的某个错误。必须包括请求状态标题（第18.42节），以指示通知针对的请求及其完成状态。消息响应状态代码（第8.1.1节）用于指示播放请求的结束方式。播放通知的发送方可在以下情况下发出更新的播放通知：
PLAY_NOTIFY sent with wrong information. For instance, a PLAY_NOTIFY was issued before reaching the end-of-stream, but some error occurred resulting in that the previously sent PLAY_NOTIFY contained a wrong time when the stream will end. In this case, a new PLAY_NOTIFY MUST be sent including the correct status for the completion and all additional information.
播放用错误信息发送的通知。例如，在到达流结束之前发出了播放通知，但出现了一些错误，导致先前发送的播放通知包含流结束的错误时间。在这种情况下，必须发送新的播放通知，包括正确的完成状态和所有附加信息。
PLAY_NOTIFY requests with the Notify-Reason header set to end-of-stream MUST include a Range header and the Scale header if the scale value is not 1. The Range header indicates the point in the stream or streams where delivery is ending with the timescale that was used by the server in the PLAY response for the request being fulfilled. The server MUST NOT use the "now" constant in the Range header; it MUST use the actual numeric end position in the proper timescale. When end-of-stream notifications are issued prior to having sent the last media packets, this is made evident because the end time in the Range header is beyond the current time in the media being received by the client, e.g., "npt=-15", if npt is currently at 14.2 seconds. The Scale header is to be included so that it is evident if the media timescale is moving backwards or has a non-default pace. The end-of-stream notification does not prevent the client from sending a new PLAY request.
如果比例值不是1，则将NOTIFY Reason标头设置为end of stream的PLAY_NOTIFY请求必须包括范围标头和比例标头。范围标头指示流中的一个或多个点，其中传递以服务器在播放响应中用于满足请求的时间刻度结束。服务器不得在范围标头中使用“now”常量；它必须使用正确时间刻度中的实际数字结束位置。当在发送最后一个媒体数据包之前发出流结束通知时，这是显而易见的，因为范围标头中的结束时间超出了客户端接收的媒体中的当前时间，例如，“npt=-15”，如果npt当前为14.2秒。应包括刻度头，以便在媒体时间刻度向后移动或具有非默认速度时可以清楚地看到。流结束通知不会阻止客户端发送新的播放请求。
If RTP is used as media transport, an RTP-Info header MUST be included, and the RTP-Info header MUST indicate the last sequence number in the sequence parameter.
如果将RTP用作媒体传输，则必须包含RTP Info标头，并且RTP Info标头必须指示sequence参数中的最后一个序列号。
For an RTSP Session where media resources are under aggregated control, the media resources will normally end at approximately the same time, although some small differences may exist, on the scale of a few hundred milliseconds. In those cases, an RTSP session under aggregated control SHOULD send only a single PLAY_NOTIFY request. By using the aggregate control URI in the PLAY_NOTIFY request, the RTSP server indicates that this applies to all media resources within the session. In cases in which RTP is used for media delivery, corresponding RTP-Info needs to be included for all media resources. In cases where one or more media resources have a significantly shorter duration than some other resources in the aggregated session, the server MAY send end-of-stream notifications using individual media resource URIs to indicate to agents that there will be no more media for this particular media resource related to the current active PLAY request. In such cases, when the remaining media resources come to the end of the stream, they MUST send a PLAY_NOTIFY request using the aggregate control URI to indicate that no more resources remain.
对于媒体资源处于聚合控制下的RTSP会话，媒体资源通常会在大约相同的时间结束，尽管可能存在一些小的差异，规模为几百毫秒。在这些情况下，聚合控制下的RTSP会话应仅发送一个PLAY_NOTIFY请求。通过在PLAY_NOTIFY请求中使用聚合控制URI，RTSP服务器指示这适用于会话中的所有媒体资源。在RTP用于媒体交付的情况下，所有媒体资源都需要包含相应的RTP信息。如果一个或多个媒体资源的持续时间明显短于聚合会话中的一些其他资源，服务器可以使用单个媒体资源uri发送流结束通知，以向代理指示与当前活动播放请求相关的该特定媒体资源将不再有媒体。在这种情况下，当剩余的媒体资源到达流的末尾时，它们必须使用聚合控制URI发送PLAY_NOTIFY请求，以指示没有剩余的资源。
A PLAY_NOTIFY request with Notify-Reason header set to end-of-stream MUST NOT carry a message body.
将NOTIFY Reason标头设置为流末尾的PLAY_NOTIFY请求不得包含消息正文。
This example request notifies the client about a future end-of-stream event:
此示例请求通知客户端未来的流结束事件：
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 854
Notify-Reason: end-of-stream
Request-Status: cseq=853 status=200 reason="OK"
Range: npt=-145
RTP-Info:url="rtsp://example.com/fizzle/foo/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545,
url="rtsp://example.com/fizzle/video"
ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: CDtUJfDQXJWtJ7Iqua2xOi
Date: Mon, 08 Mar 2010 13:37:16 GMT
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 854
Notify-Reason: end-of-stream
Request-Status: cseq=853 status=200 reason="OK"
Range: npt=-145
RTP-Info:url="rtsp://example.com/fizzle/foo/audio"
ssrc=0D12F123:seq=14783;rtptime=2345962545,
url="rtsp://example.com/fizzle/video"
ssrc=789DAF12:seq=57654;rtptime=2792482193
Session: CDtUJfDQXJWtJ7Iqua2xOi
Date: Mon, 08 Mar 2010 13:37:16 GMT
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
Session: CDtUJfDQXJWtJ7Iqua2xOi
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
Session: CDtUJfDQXJWtJ7Iqua2xOi
A PLAY_NOTIFY request with a Notify-Reason header set to media-properties-update indicates an update of the media properties for the given session (see Section 18.29) or the available media range that can be played as indicated by the Media-Range header (Section 18.30). PLAY_NOTIFY requests with Notify-Reason header set to media-properties-update MUST include a Media-Properties and Date header and SHOULD include a Media-Range header. The Media-Properties header has session scope; thus, for aggregated sessions, the PLAY_NOTIFY request MUST use the aggregated control URI.
将“通知原因”标题设置为“媒体属性更新”的“播放通知”请求表示给定会话的媒体属性更新（参见第18.29节）或可用媒体范围的更新（参见第18.30节）。将NOTIFY Reason标头设置为media properties update的PLAY_NOTIFY请求必须包含media properties和Date标头，并且应包含media Range标头。媒体属性标头具有会话范围；因此，对于聚合会话，PLAY_NOTIFY请求必须使用聚合控件URI。
This notification MUST be sent for media that are time-progressing every time an event happens that changes the basis for making estimates on how the available for play-back media range will progress with wall clock time. In addition, it is RECOMMENDED that the server send these notifications approximately every 5 minutes for time-progressing content to ensure the long-term stability of the client estimation and allow for clock skew detection by the client. The time between notifications should be greater than 1 minute and less than 2 hours. For the reasons just explained, requests MUST include a Media-Range header to provide current Media duration and a Range header to indicate the current playing point and any remaining parts of the requested range.
每次事件发生时，必须为正在进行时间处理的介质发送此通知，该事件改变了评估可供播放介质范围将如何随挂钟时间进行处理的依据。此外，建议服务器大约每5分钟发送一次时间进度内容通知，以确保客户端估计的长期稳定性，并允许客户端进行时钟偏移检测。通知之间的时间间隔应大于1分钟，小于2小时。出于刚才解释的原因，请求必须包括一个媒体范围标头以提供当前媒体持续时间，以及一个范围标头以指示当前播放点和请求范围的任何剩余部分。
The recommendation for sending updates every 5 minutes is due to any clock skew issues. In 5 minutes, the clock skew should not become too significant as this is not used for media playback and synchronization, it is only for determining which content is available to the user.
建议每5分钟发送一次更新，这是因为存在任何时钟偏移问题。在5分钟内，时钟偏差不应变得太大，因为它不用于媒体播放和同步，它仅用于确定哪些内容可供用户使用。
A PLAY_NOTIFY request with Notify-Reason header set to media-properties-update MUST NOT carry a message body.
将“通知原因”标题设置为“媒体属性更新”的播放通知请求不得包含消息正文。
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854
Notify-Reason: media-properties-update
Session: CDtUJfDQXJWtJ7Iqua2xOi
Media-Properties: Time-Progressing,
Time-Limited=20080415T153919.36Z, Random-Access=5.0
Media-Range: npt=00:00:00-01:37:21.394
Range: npt=01:15:49.873-
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854
Notify-Reason: media-properties-update
Session: CDtUJfDQXJWtJ7Iqua2xOi
Media-Properties: Time-Progressing,
Time-Limited=20080415T153919.36Z, Random-Access=5.0
Media-Range: npt=00:00:00-01:37:21.394
Range: npt=01:15:49.873-
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
Session: CDtUJfDQXJWtJ7Iqua2xOi
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
Session: CDtUJfDQXJWtJ7Iqua2xOi
The server may be forced to change the rate of media time per playback time when a client requests delivery using a scale (Section 18.46) value other than 1.0 (normal playback rate). For time-progressing media with some retention, i.e., the server stores already-sent content, a client requesting to play with scale values larger than 1 may catch up with the front end of the media. The server will then be unable to continue to provide content at scale larger than 1 as content is only made available by the server at scale = 1. Another case is when scale < 1 and the media retention is Time-Duration limited. In this case, the delivery point can reach the oldest media unit available, and further playback at this scale becomes impossible as there will be no media available. To avoid having the client lose any media, the scale will need to be adjusted to the same rate at which the media is removed from the storage buffer, commonly scale = 1.0.
当客户端使用1.0（正常播放速率）以外的刻度（第18.46节）值请求传输时，服务器可能会被迫更改每次播放时间的媒体时间速率。对于保留时间较长的介质，即服务器存储已发送的内容，请求播放大于1的缩放值的客户端可能会赶上介质前端。然后，服务器将无法继续以大于1的比例提供内容，因为内容仅由服务器在比例=1时提供。另一种情况是当刻度<1且介质保留时间有限时。在这种情况下，传送点可以到达可用的最旧媒体单元，并且由于没有可用媒体，因此无法以这种比例进一步播放。为避免客户端丢失任何介质，需要将比例调整为从存储缓冲区中移除介质的相同速率，通常比例为1.0。
Another case is when the content itself consists of spliced pieces or is dynamically updated. In these cases, the server may be required to change from one supported scale value (different than scale = 1.0) to another. In this case, the server will pick the closest value and
另一种情况是，内容本身由拼接的片段组成或动态更新。在这些情况下，服务器可能需要从一个支持的比例值（不同于比例=1.0）更改为另一个。在这种情况下，服务器将选择最接近的值并
inform the client of what it has picked. In these cases, the media properties will also be sent, updating the supported scale values. This enables a client to adjust the scale value used.
告知客户已挑选的物品。在这些情况下，还将发送介质属性，更新支持的比例值。这使客户端能够调整使用的比例值。
To minimize impact on playback in any of the above cases, the server MUST modify the playback properties, set scale to a supportable value, and continue delivery of the media. When doing this modification, it MUST send a PLAY_NOTIFY message with the Notify-Reason header set to "scale-change". The request MUST contain a Range header with the media time when the change took effect, a Scale header with the new value in use, a Session header with the identifier for the session to which it applies, and a Date header with the server wallclock time of the change. For time-progressing content, the Media-Range and the Media-Properties headers at this point in time also MUST be included. The Media-Properties header MUST be included if the scale change was due to the content changing what scale values ("Scales") are supported.
若要将上述任何情况下对播放的影响降至最低，服务器必须修改播放属性，将“缩放”设置为可支持的值，并继续传送媒体。进行此修改时，它必须发送一条PLAY_NOTIFY消息，其中NOTIFY Reason标头设置为“scale change”。请求必须包含一个带有更改生效时的媒体时间的范围标头、一个带有正在使用的新值的缩放标头、一个带有其应用的会话标识符的会话标头，以及一个带有更改的服务器挂钟时间的日期标头。对于时间进度内容，还必须包括此时的媒体范围和媒体属性标题。如果缩放更改是由于内容更改了支持的缩放值（“缩放”），则必须包括媒体属性标题。
For media streams delivered using RTP, an RTP-Info header MUST also be included. It MUST contain the rtptime parameter with a value corresponding to the point of change in that media and optionally the sequence number.
对于使用RTP交付的媒体流，还必须包括RTP信息头。它必须包含rtptime参数，该参数的值对应于该介质中的变化点，并且可以选择序列号。
PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated control URI in the request. The scale change for any aggregated session applies to all media streams that are part of the aggregate.
聚合会话的PLAY_NOTIFY请求必须在请求中使用聚合控件URI。任何聚合会话的缩放更改都适用于作为聚合一部分的所有媒体流。
A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change" MUST NOT carry a message body.
通知原因标题设置为“缩放更改”的播放通知请求不得包含消息正文。
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854
Notify-Reason: scale-change
Session: CDtUJfDQXJWtJ7Iqua2xOi
Media-Properties: Time-Progressing,
Time-Limited=20080415T153919.36Z, Random-Access=5.0
Media-Range: npt=00:00:00-01:37:21.394
Range: npt=01:37:21.394-
Scale: 1
RTP-Info: url="rtsp://example.com/fizzle/foo/audio"
ssrc=0D12F123:rtptime=2345962545,
url="rtsp://example.com/fizzle/foo/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193
S->C: PLAY_NOTIFY rtsp://example.com/fizzle/foo RTSP/2.0
Date: Tue, 14 Apr 2008 15:48:06 GMT
CSeq: 854
Notify-Reason: scale-change
Session: CDtUJfDQXJWtJ7Iqua2xOi
Media-Properties: Time-Progressing,
Time-Limited=20080415T153919.36Z, Random-Access=5.0
Media-Range: npt=00:00:00-01:37:21.394
Range: npt=01:37:21.394-
Scale: 1
RTP-Info: url="rtsp://example.com/fizzle/foo/audio"
ssrc=0D12F123:rtptime=2345962545,
url="rtsp://example.com/fizzle/foo/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792482193
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
Session: CDtUJfDQXJWtJ7Iqua2xOi
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
Session: CDtUJfDQXJWtJ7Iqua2xOi
The PAUSE request causes the stream delivery to immediately be interrupted (halted). A PAUSE request MUST be made either with the aggregated control URI for aggregated sessions, resulting in all media being halted, or with the media URI for non-aggregated sessions. Any attempt to mute a single media with a PAUSE request in an aggregated session MUST be responded to with a 460 (Only Aggregate Operation Allowed) error. After resuming playback, synchronization of the tracks MUST be maintained. Any server resources are kept, though servers MAY close the session and free resources after being paused for the duration specified with the timeout parameter of the Session header in the SETUP message.
暂停请求导致流传递立即中断（暂停）。必须使用聚合会话的聚合控制URI（导致所有媒体暂停）或非聚合会话的媒体URI发出暂停请求。在聚合会话中，如果试图通过暂停请求使单个媒体静音，则必须以460（仅允许聚合操作）错误进行响应。恢复播放后，必须保持曲目的同步。保留所有服务器资源，但服务器可能会关闭会话，并在暂停设置消息中会话头超时参数指定的持续时间后释放资源。
Example:
例子：
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: OoOUPyUwt0VeY9fFRHuZ6L
User-Agent: PhonyClient/1.2
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: OoOUPyUwt0VeY9fFRHuZ6L
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: OoOUPyUwt0VeY9fFRHuZ6L
Range: npt=45.76-75.00
S->C: RTSP/2.0 200 OK
CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: OoOUPyUwt0VeY9fFRHuZ6L
Range: npt=45.76-75.00
The PAUSE request causes stream delivery to be interrupted immediately on receipt of the message, and the pause point is set to the current point in the presentation. That pause point in the media stream needs to be maintained. A subsequent PLAY request without a Range header resumes from the pause point and plays until media end.
暂停请求导致在收到消息时立即中断流传递，并且暂停点设置为演示文稿中的当前点。需要维护媒体流中的暂停点。没有范围标头的后续播放请求将从暂停点继续播放，直到媒体结束。
The pause point after any PAUSE request MUST be returned to the client by adding a Range header with what remains unplayed of the PLAY request's range. For media with random access properties, if one desires to resume playing a ranged request, one simply includes the Range header from the PAUSE response and includes the Seek-Style header with the Next policy in the PLAY request. For media that is time-progressing and has retention duration=0, the follow-up PLAY request to start media delivery again MUST use "npt=now-" and not the answer given in the response to PAUSE.
任何暂停请求后的暂停点必须通过添加一个范围标头返回给客户端，其中包含播放请求范围中未显示的内容。对于具有随机访问属性的媒体，如果希望继续播放范围请求，只需在暂停响应中包含范围标头，并在播放请求中包含带有下一个策略的Seek Style标头。对于正在进行时间处理且保留时间为0的介质，再次开始介质传送的后续播放请求必须使用“npt=now-”而不是暂停响应中给出的答案。
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=10-30
User-Agent: PhonyClient/1.2
C->S: PLAY rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=10-30
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.0
Range: npt=10-30
Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=4FAD8726:seq=57654;rtptime=2792482193
Session: OccldOFFq23KwjYpAnBbUr
S->C: RTSP/2.0 200 OK
CSeq: 834
Date: Thu, 23 Jan 1997 15:35:06 GMT
Server: PhonyServer/1.0
Range: npt=10-30
Seek-Style: First-Prior
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934207921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=4FAD8726:seq=57654;rtptime=2792482193
Session: OccldOFFq23KwjYpAnBbUr
After 11 seconds, i.e., at 21 seconds into the presentation:
11秒后，即演示21秒时：
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835
Session: OccldOFFq23KwjYpAnBbUr
User-Agent: PhonyClient/1.2
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835
Session: OccldOFFq23KwjYpAnBbUr
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 835
Date: 23 Jan 1997 15:35:17 GMT
Server: PhonyServer/1.0
Range: npt=21-30
Session: OccldOFFq23KwjYpAnBbUr
S->C: RTSP/2.0 200 OK
CSeq: 835
Date: 23 Jan 1997 15:35:17 GMT
Server: PhonyServer/1.0
Range: npt=21-30
Session: OccldOFFq23KwjYpAnBbUr
If a client issues a PAUSE request and the server acknowledges and enters the Ready state, the proper server response, if the player issues another PAUSE, is still 200 OK. The 200 OK response MUST include the Range header with the current pause point. See examples below:
如果客户端发出暂停请求，服务器确认并进入就绪状态，则如果播放机再次发出暂停，则正确的服务器响应仍然正常。200 OK响应必须包括带有当前暂停点的范围标头。见以下示例：
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: OccldOFFq23KwjYpAnBbUr
User-Agent: PhonyClient/1.2
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 834
Session: OccldOFFq23KwjYpAnBbUr
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 834
Session: OccldOFFq23KwjYpAnBbUr
Date: Thu, 23 Jan 1997 15:35:06 GMT
Range: npt=45.76-98.36
S->C: RTSP/2.0 200 OK
CSeq: 834
Session: OccldOFFq23KwjYpAnBbUr
Date: Thu, 23 Jan 1997 15:35:06 GMT
Range: npt=45.76-98.36
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835
Session: OccldOFFq23KwjYpAnBbUr
User-Agent: PhonyClient/1.2
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 835
Session: OccldOFFq23KwjYpAnBbUr
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 835
Session: OccldOFFq23KwjYpAnBbUr
Date: 23 Jan 1997 15:35:07 GMT
Range: npt=45.76-98.36
S->C: RTSP/2.0 200 OK
CSeq: 835
Session: OccldOFFq23KwjYpAnBbUr
Date: 23 Jan 1997 15:35:07 GMT
Range: npt=45.76-98.36
The TEARDOWN client-to-server request stops the stream delivery for the given URI, freeing the resources associated with it. A TEARDOWN request can be performed on either an aggregated or a media control URI. However, some restrictions apply depending on the current state. The TEARDOWN request MUST contain a Session header indicating to what session the request applies. The TEARDOWN request MUST NOT include a Terminate-Reason header.
拆卸客户端到服务器请求停止给定URI的流传递，释放与其关联的资源。拆卸请求可以在聚合URI或媒体控件URI上执行。但是，根据当前状态，会应用一些限制。拆卸请求必须包含一个会话头，指示请求应用于哪个会话。拆卸请求不得包含终止原因标头。
A TEARDOWN using the aggregated control URI or the media URI in a session under non-aggregated control (single media session) MAY be done in any state (Ready and Play). A successful request MUST result in that media delivery being immediately halted and the session state being destroyed. This MUST be indicated through the lack of a Session header in the response.
在非聚合控制下的会话（单个媒体会话）中使用聚合控制URI或媒体URI的拆卸可以在任何状态（就绪并播放）下完成。成功的请求必须导致媒体传送立即停止，会话状态被破坏。这必须通过响应中缺少会话头来表示。
A TEARDOWN using a media URI in an aggregated session can only be done in Ready state. Such a request only removes the indicated media stream and associated resources from the session. This may result in a session returning to non-aggregated control, because it only contains a single media after the request's completion. A session that will exist after the processing of the TEARDOWN request MUST, in the response to that TEARDOWN request, contain a Session header.
在聚合会话中使用媒体URI的拆卸只能在就绪状态下完成。这样的请求仅从会话中移除所指示的媒体流和相关资源。这可能导致会话返回到非聚合控制，因为在请求完成后它只包含一个媒体。处理拆卸请求后将存在的会话必须在对该拆卸请求的响应中包含会话头。
Thus, the presence of the Session header indicates to the receiver of the response if the session is still extant or has been removed.
因此，会话报头的存在向响应的接收器指示会话是否仍然存在或已被移除。
Example:
例子：
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 892
Session: OccldOFFq23KwjYpAnBbUr
User-Agent: PhonyClient/1.2
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 892
Session: OccldOFFq23KwjYpAnBbUr
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 892
Server: PhonyServer/1.0
S->C: RTSP/2.0 200 OK
CSeq: 892
Server: PhonyServer/1.0
The server can send TEARDOWN requests in the server-to-client direction to indicate that the server has been forced to terminate the ongoing session. This may happen for several reasons, such as server maintenance without available backup, or that the session has been inactive for extended periods of time. The reason is provided in the Terminate-Reason header (Section 18.52).
服务器可以在服务器到客户端的方向上发送拆卸请求，以指示服务器已被强制终止正在进行的会话。出现这种情况可能有多种原因，例如在没有可用备份的情况下维护服务器，或者会话长时间处于非活动状态。终止原因标题中提供了原因（第18.52节）。
When an RTSP client has maintained an RTSP session that otherwise is inactive for an extended period of time, the server may reclaim the resources. That is done by issuing a TEARDOWN request with the Terminate-Reason set to "Session-Timeout". This MAY be done when the client has been inactive in the RTSP session for more than one Session Timeout period (Section 18.49). However, the server is NOT RECOMMENDED to perform this operation until an extended period of inactivity of 10 times the Session-Timeout period has passed. It is up to the operator of the RTSP server to actually configure how long this extended period of inactivity is. An operator should take into account, when doing this configuration, what the served content is and what this means for the extended period of inactivity.
当RTSP客户端维护了一个RTSP会话，而该会话在其他情况下长时间处于非活动状态时，服务器可能会回收资源。这是通过发出将终止原因设置为“会话超时”的拆卸请求来完成的。当客户端在RTSP会话中处于非活动状态超过一个会话超时时间（第18.49节）时，可以执行此操作。但是，在经过会话超时时间10倍的延长不活动期之前，不建议服务器执行此操作。由RTSP服务器的操作员实际配置此延长的非活动期的长度。在进行此配置时，运营商应考虑所服务的内容是什么，以及在较长的非活动期内这意味着什么。
In case the server needs to stop providing service to the established sessions and there is no server to point at in a REDIRECT request, then TEARDOWN SHALL be used to terminate the session. This method can also be used when non-recoverable internal errors have happened and the server has no other option than to terminate the sessions.
如果服务器需要停止向已建立的会话提供服务，并且重定向请求中没有可指向的服务器，则应使用拆卸来终止会话。如果发生了不可恢复的内部错误，并且服务器除了终止会话之外别无选择，也可以使用此方法。
The TEARDOWN request MUST be made only on the session aggregate control URI (i.e., it is not allowed to terminate individual media streams, if it is a session aggregate), and it MUST include the following headers: Session and Terminate-Reason. The request only applies to the session identified in the Session header. The server may include a message to the client's user with the "user-msg" parameter.
拆卸请求必须仅在会话聚合控制URI上发出（即，如果是会话聚合，则不允许终止单个媒体流），并且必须包括以下标题：会话和终止原因。该请求仅适用于会话头中标识的会话。服务器可以包括发送给客户端用户的带有“user msg”参数的消息。
The TEARDOWN request may alternatively be done on the wildcard URI "*" and without any session header. The scope of such a request is limited to the next-hop (i.e., the RTSP agent in direct communication with the server) and applies, as well, to the RTSP connection between the next-hop RTSP agent and the server. This request indicates that all sessions and pending requests being managed via the connection are terminated. Any intervening proxies SHOULD do all of the following in the order listed:
也可以在通配符URI“*”上执行拆卸请求，而不使用任何会话头。此类请求的范围限于下一跳（即，与服务器直接通信的RTSP代理），并且也适用于下一跳RTSP代理和服务器之间的RTSP连接。此请求表示通过连接管理的所有会话和挂起的请求都已终止。任何介入代理应按所列顺序执行以下所有操作：
1. respond to the TEARDOWN request
1. 响应拆卸请求
2. disconnect the control channel from the requesting server
2. 断开控制通道与请求服务器的连接
3. pass the TEARDOWN request to each applicable client (typically those clients with an active session or an unanswered request)
3. 将拆卸请求传递给每个适用的客户端（通常是具有活动会话或未响应请求的客户端）
Note: The proxy is responsible for accepting TEARDOWN responses from its clients; these responses MUST NOT be passed on to either the original server or the target server in the redirect.
注意：代理负责接受其客户的拆卸响应；这些响应不得传递到重定向中的原始服务器或目标服务器。
The GET_PARAMETER request retrieves the value of any specified parameter or parameters for a presentation or stream specified in the URI. If the Session header is present in a request, the value of a parameter MUST be retrieved in the specified session context. There are two ways of specifying the parameters to be retrieved.
GET_参数请求检索URI中指定的表示或流的任何指定参数的值。如果请求中存在会话头，则必须在指定的会话上下文中检索参数值。有两种方法可以指定要检索的参数。
The first approach includes headers that have been defined to be usable for this purpose. Headers for this purpose should allow empty, or stripped value parts to avoid having to specify bogus data when indicating the desire to retrieve a value. The successful completion of the request should also be evident from any filled out values in the response. The headers in this specification that MAY be used for retrieving their current value using GET_PARAMETER are listed below; additional headers MAY be specified in the future:
第一种方法包括定义为可用于此目的的头。用于此目的的标题应允许空的或剥离的值部分，以避免在指示检索值时必须指定虚假数据。从响应中填写的任何值也可以看出请求是否成功完成。下面列出了本规范中可用于使用GET_参数检索其当前值的标题；以后可能会指定其他标题：
o Accept-Ranges
o 接受范围
o Media-Range
o 媒体范围
o Media-Properties
o 媒体属性
o Range
o 范围
o RTP-Info
o RTP信息
The other way is to specify a message body that lists the parameter(s) that are desired to be retrieved. The Content-Type header (Section 18.19) is used to specify which format the message body has. If the receiver of the request does not support the media type used for the message body, it SHALL respond using the error code 415 (Unsupported Media Type). The responder to a GET_PARAMETER request MUST use the media type of the request for the response. For additional considerations regarding message body negotiation, see Section 9.3.
另一种方法是指定一个消息体，其中列出了需要检索的参数。内容类型标题（第18.19节）用于指定消息正文的格式。如果请求的接收器不支持用于消息正文的媒体类型，则其应使用错误代码415（不支持的媒体类型）进行响应。GET_参数请求的响应者必须使用响应请求的媒体类型。有关消息体协商的其他注意事项，请参见第9.3节。
RTSP agents implementing support for responding to GET_PARAMETER requests SHALL implement the "text/parameters" format (Appendix F). This to ensure that at least one known format for parameters is implemented and, thus, prevent parameter format negotiation failure.
支持响应GET_参数请求的RTSP代理应采用“文本/参数”格式（附录F）。这是为了确保实现至少一种已知的参数格式，从而防止参数格式协商失败。
Parameters specified within the body of the message must all be understood by the request-receiving agent. If one or more parameters are not understood a 451 (Parameter Not Understood) MUST be sent including a body listing the parameters that weren't understood. If all parameters are understood, their values are filled in and returned in the response message body.
请求接收代理必须理解消息体中指定的所有参数。如果一个或多个参数未被理解，则必须发送451（参数未被理解），包括列出未被理解参数的正文。如果理解了所有参数，则在响应消息体中填写并返回它们的值。
The method can also be used without a message body or any header that requests parameters for keep-alive purposes. The keep-alive timer has been updated for any request that is successful, i.e., a 200 OK response is received. Any non-required header present in such a request may or may not have been processed. Normally, the presence of filled-out values in the header will be indication that the header has been processed. However, for cases when this is difficult to determine, it is recommended to use a feature tag and the Require header. For this reason, it is usually easier if any parameters to be retrieved are sent in the body, rather than using any header.
该方法也可以在没有消息体或任何请求参数以保持活动状态的头的情况下使用。已针对任何成功的请求更新保持活动计时器，即，收到200 OK响应。此类请求中存在的任何非必需标头可能已处理，也可能尚未处理。通常，标题中填写的值表示标题已被处理。但是，对于难以确定的情况，建议使用功能标签和Require标题。因此，如果在正文中发送要检索的任何参数，而不是使用任何标题，通常会更容易。
Example:
例子：
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 431
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
Content-Length: 26
Content-Type: text/parameters
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 431
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
Content-Length: 26
Content-Type: text/parameters
packets_received jitter
接收到的数据包抖动
C->S: RTSP/2.0 200 OK
CSeq: 431
Session: OccldOFFq23KwjYpAnBbUr
Server: PhonyServer/1.1
Date: Mon, 08 Mar 2010 13:43:23 GMT
Content-Length: 38
Content-Type: text/parameters
C->S: RTSP/2.0 200 OK
CSeq: 431
Session: OccldOFFq23KwjYpAnBbUr
Server: PhonyServer/1.1
Date: Mon, 08 Mar 2010 13:43:23 GMT
Content-Length: 38
Content-Type: text/parameters
packets_received: 10 jitter: 0.3838
接收到的数据包：10抖动：0.3838
This method requests the setting of the value of a parameter or a set of parameters for a presentation or stream specified by the URI. If the Session header is present in a request, the value of a parameter MUST be retrieved in the specified session context. The method MAY also be used without a message body. It is the RECOMMENDED method to be used in a request sent for the sole purpose of updating the keep-alive timer. If this request is successful, i.e., a 200 OK response is received, then the keep-alive timer has been updated. Any non-required header present in such a request may or may not have been processed. To allow a client to determine if any such header has been processed, it is necessary to use a feature tag and the Require header. Due to this reason it is RECOMMENDED that any parameters are sent in the body rather than using any header.
此方法请求设置URI指定的表示或流的一个参数或一组参数的值。如果请求中存在会话头，则必须在指定的会话上下文中检索参数值。该方法也可以在没有消息体的情况下使用。建议在仅用于更新保持活动计时器的请求中使用此方法。如果该请求成功，即收到200 OK响应，则保持活动计时器已更新。此类请求中存在的任何非必需标头可能已处理，也可能尚未处理。为了让客户机确定是否已经处理了任何这样的头，有必要使用feature标记和Require头。因此，建议在正文中发送任何参数，而不是使用任何标题。
When using a message body to list the parameter(s) desired to be set, the Content-Type header (Section 18.19) is used to specify which format the message body has. If the receiver of the request is not supporting the media type used for the message body, it SHALL respond using the error code 415 (Unsupported Media Type). For additional considerations regarding message body negotiation, see Section 9.3. The responder to a SET_PARAMETER request MUST use the media type of the request for the response. For additional considerations regarding message body negotiation, see Section 9.3.
当使用消息正文列出需要设置的参数时，内容类型标题（第18.19节）用于指定消息正文的格式。如果请求的接收器不支持用于消息正文的媒体类型，则其应使用错误代码415（不支持的媒体类型）进行响应。有关消息体协商的其他注意事项，请参见第9.3节。SET_参数请求的响应者必须使用请求的媒体类型进行响应。有关消息体协商的其他注意事项，请参见第9.3节。
RTSP agents implementing support for responding to SET_PARAMETER requests SHALL implement the text/parameters format (Appendix F). This is to ensure that at least one known format for parameters is implemented and, thus, prevent parameter format negotiation failure.
支持响应SET_参数请求的RTSP代理应采用文本/参数格式（附录F）。这是为了确保实现至少一种已知的参数格式，从而防止参数格式协商失败。
A request is RECOMMENDED to only contain a single parameter to allow the client to determine why a particular request failed. If the request contains several parameters, the server MUST only act on the request if all of the parameters can be set successfully. A server MUST allow a parameter to be set repeatedly to the same value, but it MAY disallow changing parameter values. If the receiver of the request does not understand or cannot locate a parameter, error 451 (Parameter Not Understood) MUST be used. When a parameter is not allowed to change, the error code is 458 (Parameter Is Read-Only). The response body MUST contain only the parameters that have errors. Otherwise, a body MUST NOT be returned. The response body MUST use the media type of the request for the response.
建议请求只包含一个参数，以便客户端确定特定请求失败的原因。如果请求包含多个参数，则只有在所有参数都可以成功设置的情况下，服务器才能对请求执行操作。服务器必须允许将参数重复设置为相同的值，但可能不允许更改参数值。如果请求的接收者不理解或无法定位参数，则必须使用错误451（参数未理解）。不允许更改参数时，错误代码为458（参数为只读）。响应正文必须仅包含有错误的参数。否则，不得退回实体。响应主体必须使用响应请求的媒体类型。
Note: transport parameters for the media stream MUST only be set with the SETUP command.
注意：只能使用SETUP命令设置媒体流的传输参数。
Restricting setting transport parameters to SETUP is for the benefit of firewalls connected to border RTSP proxies.
限制将传输参数设置为SETUP是为了连接到边界RTSP代理的防火墙。
The parameters are split in a fine-grained fashion so that there can be more meaningful error indications. However, it may make sense to allow the setting of several parameters if an atomic setting is desirable. Imagine device control where the client does not want the camera to pan unless it can also tilt to the right angle at the same time.
这些参数以细粒度的方式进行分割，以便出现更有意义的错误指示。但是，如果需要原子设置，则允许设置多个参数可能是有意义的。想象一下，在设备控制中，客户端不希望相机平移，除非它同时也可以倾斜到直角。
Example:
例子：
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 421
User-Agent: PhonyClient/1.2
Session: iixT43KLc
Date: Mon, 08 Mar 2010 14:45:04 GMT
Content-length: 20
Content-type: text/parameters
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 421
User-Agent: PhonyClient/1.2
Session: iixT43KLc
Date: Mon, 08 Mar 2010 14:45:04 GMT
Content-length: 20
Content-type: text/parameters
barparam: barstuff
barparam:barstuff
S->C: RTSP/2.0 451 Parameter Not Understood
CSeq: 421
Session: iixT43KLc
Server: PhonyServer/1.0
Date: Mon, 08 Mar 2010 14:44:56 GMT
Content-length: 20
Content-type: text/parameters
S->C: RTSP/2.0 451 Parameter Not Understood
CSeq: 421
Session: iixT43KLc
Server: PhonyServer/1.0
Date: Mon, 08 Mar 2010 14:44:56 GMT
Content-length: 20
Content-type: text/parameters
barparam: barstuff
barparam:barstuff
The REDIRECT method is issued by a server to inform a client that the service provided will be terminated and where a corresponding service can be provided instead. This may happen for different reasons. One is that the server is being administered such that it must stop providing service. Thus, the client is required to connect to another server location to access the resource indicated by the Request-URI.
重定向方法是由服务器发出的，用于通知客户端所提供的服务将被终止，以及在哪里可以提供相应的服务。这可能是由于不同的原因。一种是服务器正在被管理，因此它必须停止提供服务。因此，客户机需要连接到另一个服务器位置以访问请求URI指示的资源。
The REDIRECT request SHALL contain a Terminate-Reason header (Section 18.52) to inform the client of the reason for the request. Additional parameters related to the reason may also be included. The intention here is to allow a server administrator to do a controlled shutdown of the RTSP server. That requires sufficient time to inform all entities having associated state with the server and for them to perform a controlled migration from this server to a fall-back server.
重定向请求应包含终止原因标题（第18.52节），以通知客户请求的原因。还可能包括与原因相关的其他参数。此处的目的是允许服务器管理员控制RTSP服务器的关闭。这需要足够的时间通知所有与服务器关联状态的实体，并让它们执行从该服务器到备用服务器的受控迁移。
A REDIRECT request with a Session header has end-to-end (i.e., server-to-client) scope and applies only to the given session. Any intervening proxies SHOULD NOT disconnect the control channel while there are other remaining end-to-end sessions. The REQUIRED Location header MUST contain a complete absolute URI pointing to the resource to which the client SHOULD reconnect. Specifically, the Location
具有会话头的重定向请求具有端到端（即服务器到客户端）作用域，并且仅适用于给定会话。当存在其他剩余的端到端会话时，任何介入代理都不应断开控制通道。所需的位置标头必须包含一个完整的绝对URI，该URI指向客户端应重新连接到的资源。具体来说，位置
MUST NOT contain just the host and port. A client may receive a REDIRECT request with a Session header, if and only if, an end-to-end session has been established.
不能仅包含主机和端口。当且仅当建立了端到端会话时，客户端可能会收到带有会话头的重定向请求。
A client may receive a REDIRECT request without a Session header at any time when it has communication or a connection established with a server. The scope of such a request is limited to the next-hop (i.e., the RTSP agent in direct communication with the server) and applies to all sessions controlled, as well as the connection between the next-hop RTSP agent and the server. A REDIRECT request without a Session header indicates that all sessions and pending requests being managed via the connection MUST be redirected. The Location header, if included in such a request, SHOULD contain an absolute URI with only the host address and the OPTIONAL port number of the server to which the RTSP agent SHOULD reconnect. Any intervening proxies SHOULD do all of the following in the order listed:
当客户机与服务器建立通信或连接时，它可以随时接收不带会话头的重定向请求。此类请求的范围限于下一跳（即，与服务器直接通信的RTSP代理），并适用于所有受控会话，以及下一跳RTSP代理与服务器之间的连接。没有会话头的重定向请求表示必须重定向通过连接管理的所有会话和挂起的请求。如果此类请求中包含位置标头，则该标头应包含一个绝对URI，其中仅包含RTSP代理应重新连接到的服务器的主机地址和可选端口号。任何介入代理应按所列顺序执行以下所有操作：
1. respond to the REDIRECT request
1. 响应重定向请求
2. disconnect the control channel from the requesting server
2. 断开控制通道与请求服务器的连接
3. connect to the server at the given host address
3. 在给定的主机地址连接到服务器
4. pass the REDIRECT request to each applicable client (typically those clients with an active session or an unanswered request)
4. 将重定向请求传递给每个适用的客户端（通常是具有活动会话或未响应请求的客户端）
Note: The proxy is responsible for accepting REDIRECT responses from its clients; these responses MUST NOT be passed on to either the original server or the redirected server.
注意：代理负责接受来自其客户端的重定向响应；这些响应不能传递到原始服务器或重定向服务器。
A server that needs to terminate a session or all its sessions and lacks an alternative server to redirect to, SHALL instead use TEARDOWN requests.
需要终止会话或其所有会话且缺少可重定向到的备用服务器的服务器应改为使用拆卸请求。
When no Terminate-Reason "time" parameter is included in a REDIRECT request, the client SHALL perform the redirection immediately and return a response to the server. The server shall consider the session to be terminated and can free any associated state after it receives the successful (2xx) response. The server MAY close the signaling connection upon receiving the response, and the client SHOULD close the signaling connection after sending the 2xx response. The exception to this is when the client has several sessions on the server being managed by the given signaling connection. In this case, the client SHOULD close the connection when it has received and responded to REDIRECT requests for all the sessions managed by the signaling connection.
当重定向请求中未包含终止原因“时间”参数时，客户端应立即执行重定向并向服务器返回响应。服务器应考虑终止会话，并在收到成功的（2xx）响应后，可以释放任何关联状态。服务器可以在收到响应后关闭信令连接，客户端应该在发送2xx响应后关闭信令连接。例外情况是，客户端在服务器上有多个会话由给定的信令连接管理。在这种情况下，当客户端收到并响应由信令连接管理的所有会话的重定向请求时，它应该关闭连接。
The Terminate-Reason header "time" parameter MAY be used to indicate the wallclock time by which the redirection MUST have taken place. To allow a client to determine that redirect time without being time synchronized with the server, the server MUST include a Date header in the request. The client should have terminated the session and closed the connection before the redirection time-line terminated. The server MAY simply cease to provide service when the deadline time has been reached, or it can issue a TEARDOWN requests to the remaining sessions.
Terminate Reason header“time”参数可用于指示必须发生重定向的wallclock时间。要允许客户端在不与服务器进行时间同步的情况下确定重定向时间，服务器必须在请求中包含日期头。客户端应在重定向时间线终止之前终止会话并关闭连接。服务器可能会在截止时间到达时停止提供服务，也可能会向其余会话发出拆卸请求。
If the REDIRECT request times out following the rules in Section 10.4, the server MAY terminate the session or transport connection that would be redirected by the request. This is a safeguard against misbehaving clients that refuse to respond to a REDIRECT request. This action removes any incentive of not acknowledging the reception of a REDIRECT request.
如果重定向请求按照第10.4节中的规则超时，服务器可以终止将由该请求重定向的会话或传输连接。这是针对拒绝响应重定向请求的行为不端的客户端的一种保护措施。此操作消除了不确认收到重定向请求的任何动机。
After a REDIRECT request has been processed, a client that wants to continue to receive media for the resource identified by the Request-URI will have to establish a new session with the designated host. If the URI given in the Location header is a valid resource URI, a client SHOULD issue a DESCRIBE request for the URI.
处理重定向请求后，希望继续接收请求URI标识的资源的媒体的客户端必须与指定主机建立新会话。如果Location头中给出的URI是有效的资源URI，那么客户端应该发出对该URI的descripe请求。
Note: The media resource indicated by the Location header can be identical, slightly different, or totally different. This is the reason why a new DESCRIBE request SHOULD be issued.
注意：位置标头指示的媒体资源可以相同、略有不同或完全不同。这就是为什么应该发出新的descripe请求的原因。
If the Location header contains only a host address, the client may assume that the media on the new server is identical to the media on the old server, i.e., all media configuration information from the old session is still valid except for the host address. However, the usage of conditional SETUP using MTag identifiers is RECOMMENDED as a means to verify the assumption.
如果位置标头仅包含主机地址，则客户端可能认为新服务器上的介质与旧服务器上的介质相同，即，除主机地址外，旧会话中的所有介质配置信息仍然有效。但是，建议使用使用MTag标识符的条件设置作为验证假设的方法。
This example request redirects traffic for this session to the new server at the given absolute time:
此示例请求在给定的绝对时间将此会话的通信重定向到新服务器：
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 732
Location: rtsp://s2.example.com:8001/fizzle/foo
Terminate-Reason: Server-Admin ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M
Date: Thu, 13 Feb 1996 14:30:43 GMT
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 732
Location: rtsp://s2.example.com:8001/fizzle/foo
Terminate-Reason: Server-Admin ;time=19960213T143205Z
Session: uZ3ci0K+Ld-M
Date: Thu, 13 Feb 1996 14:30:43 GMT
C->S: RTSP/2.0 200 OK
CSeq: 732
User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M
C->S: RTSP/2.0 200 OK
CSeq: 732
User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M
In order to fulfill certain requirements on the network side, e.g., in conjunction with network address translators that block RTP traffic over UDP, it may be necessary to interleave RTSP messages and media-stream data. This interleaving should generally be avoided unless necessary since it complicates client and server operation and imposes additional overhead. Also, head-of-line blocking may cause problems. Interleaved binary data SHOULD only be used if RTSP is carried over TCP. Interleaved data is not allowed inside RTSP messages.
为了满足网络端的某些要求，例如，与阻止UDP上RTP通信的网络地址转换器结合，可能需要交错RTSP消息和媒体流数据。除非必要，否则通常应避免这种交错，因为它使客户机和服务器操作复杂化并带来额外开销。此外，线路头部堵塞可能会导致问题。只有RTSP通过TCP传输时，才应使用交错二进制数据。RTSP消息内不允许交错数据。
Stream data, such as RTP packets, is encapsulated by an ASCII dollar sign (36 decimal) followed by a one-octet channel identifier and the length of the encapsulated binary data as a binary, two-octet unsigned integer in network octet order (Appendix B of [RFC791]). The stream data follows immediately afterwards, without a CRLF, but including the upper-layer protocol headers. Each dollar sign block MUST contain exactly one upper-layer protocol data unit, e.g., one RTP packet.
流数据（如RTP数据包）由ASCII美元符号（36十进制）封装，后跟一个八位字节通道标识符，封装的二进制数据的长度为网络八位字节顺序的二进制、两个八位字节无符号整数（RFC791的附录B）。流数据紧跟其后，没有CRLF，但包括上层协议头。每个美元符号块必须正好包含一个上层协议数据单元，例如一个RTP数据包。
Note that this mechanism does not support PDUs larger than 65535 octets, which matches the maximum payload size of regular, non-jumbo IPv4 and IPv6 packets. If the media delivery protocol intended to be used has larger PDUs than that, a definition of a PDU fragmentation mechanism will be required to support embedded binary data.
请注意，此机制不支持大于65535个八位字节的PDU，这与常规、非巨型IPv4和IPv6数据包的最大有效负载大小相匹配。如果拟使用的媒体交付协议的PDU大于此值，则需要定义PDU分段机制以支持嵌入式二进制数据。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "$" = 36 | Channel ID | Length in octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Binary data (Length according to Length field) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "$" = 36 | Channel ID | Length in octets |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Binary data (Length according to Length field) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Embedded Interleaved Binary Data Format
图1：嵌入式交错二进制数据格式
The channel identifier is defined in the Transport header with the interleaved parameter (Section 18.54).
信道标识符在传输报头中用交织参数定义（第18.54节）。
When the transport choice is RTP, RTCP messages are also interleaved by the server over the TCP connection. The usage of RTCP messages is indicated by including an interval containing a second channel in the interleaved parameter of the Transport header (see Section 18.54). If RTCP is used, packets MUST be sent on the first available channel
当传输选择为RTP时，RTCP消息也由服务器通过TCP连接进行交织。RTCP消息的使用通过在传输报头的交织参数中包含包含第二个信道的间隔来表示（参见第18.54节）。如果使用RTCP，则必须在第一个可用通道上发送数据包
that is higher than the RTP channel. The channels are bidirectional, using the same Channel ID in both directions; therefore, RTCP traffic is sent on the second channel in both directions.
这高于RTP通道。信道是双向的，在两个方向上使用相同的信道ID；因此，RTCP流量在两个方向的第二个通道上发送。
RTCP is sometimes needed for synchronization when two or more streams are interleaved in such a fashion. Also, this provides a convenient way to tunnel RTP/RTCP packets through the RTSP connection (TCP or TCP/TLS) when required by the network configuration and to transfer them onto UDP when possible.
当两个或多个流以这种方式交织时，有时需要RTCP进行同步。此外，这还提供了一种方便的方法，可以在网络配置需要时通过RTSP连接（TCP或TCP/TLS）对RTP/RTCP数据包进行隧道传输，并在可能时将其传输到UDP。
C->S: SETUP rtsp://example.com/bar.file RTSP/2.0
CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2
C->S: SETUP rtsp://example.com/bar.file RTSP/2.0
CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 2
Date: Thu, 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;unicast;interleaved=5-6
Session: OccldOFFq23KwjYpAnBbUr
Accept-Ranges: npt
Media-Properties: Random-Access=0.2, Immutable, Unlimited
S->C: RTSP/2.0 200 OK
CSeq: 2
Date: Thu, 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;unicast;interleaved=5-6
Session: OccldOFFq23KwjYpAnBbUr
Accept-Ranges: npt
Media-Properties: Random-Access=0.2, Immutable, Unlimited
C->S: PLAY rtsp://example.com/bar.file RTSP/2.0
CSeq: 3
Session: OccldOFFq23KwjYpAnBbUr
User-Agent: PhonyClient/1.2
C->S: PLAY rtsp://example.com/bar.file RTSP/2.0
CSeq: 3
Session: OccldOFFq23KwjYpAnBbUr
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 3
Session: OccldOFFq23KwjYpAnBbUr
Date: Thu, 05 Jun 1997 18:57:19 GMT
RTP-Info: url="rtsp://example.com/bar.file"
ssrc=0D12F123:seq=232433;rtptime=972948234
Range: npt=0-56.8
Seek-Style: RAP
S->C: RTSP/2.0 200 OK
CSeq: 3
Session: OccldOFFq23KwjYpAnBbUr
Date: Thu, 05 Jun 1997 18:57:19 GMT
RTP-Info: url="rtsp://example.com/bar.file"
ssrc=0D12F123:seq=232433;rtptime=972948234
Range: npt=0-56.8
Seek-Style: RAP
S->C: $005{2 octet length}{"length" octets data, w/RTP header}
S->C: $005{2 octet length}{"length" octets data, w/RTP header}
S->C: $006{2 octet length}{"length" octets RTCP packet}
S->C: $005{2 octet length}{"length" octets data, w/RTP header}
S->C: $005{2 octet length}{"length" octets data, w/RTP header}
S->C: $006{2 octet length}{"length" octets RTCP packet}
RTSP Proxies are RTSP agents that are located in between a client and a server. A proxy can take on the roles of both client and server depending on what it tries to accomplish. RTSP proxies use two transport-layer connections: one from the RTSP client to the RTSP proxy and a second from the RTSP proxy to the RTSP server. Proxies are introduced for several different reasons; those listed below are often combined.
RTSP代理是位于客户端和服务器之间的RTSP代理。代理可以同时扮演客户端和服务器的角色，这取决于它试图完成的任务。RTSP代理使用两个传输层连接：一个从RTSP客户端到RTSP代理，另一个从RTSP代理到RTSP服务器。引入代理有几个不同的原因；下面列出的这些通常是组合在一起的。
Caching Proxy: This type of proxy is used to reduce the workload on servers and connections. By caching the description and media streams, i.e., the presentation, the proxy can serve a client with content, but without requesting it from the server once it has been cached and has not become stale. See Section 16. This type of proxy is also expected to understand RTSP endpoint functionality, i.e., functionality identified in the Require header in addition to what Proxy-Require demands.
缓存代理：这种类型的代理用于减少服务器和连接上的工作负载。通过缓存描述和媒体流，即表示，代理可以向客户机提供内容，但在缓存内容且未过时后，无需向服务器请求内容。见第16节。这种类型的代理还需要了解RTSP端点功能，即除了代理需要什么之外，还需要在Require头中标识的功能。
Translator Proxy: This type of proxy is used to ensure that an RTSP client gets access to servers and content on an external network or gets access by 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 also to understand RTSP endpoint functionality, i.e., functionality identified in the Require header in addition to what Proxy-Require demands.
转换器代理：这种类型的代理用于确保RTSP客户端可以访问外部网络上的服务器和内容，或者使用客户端不支持的内容编码进行访问。代理执行地址、协议或编码的必要转换。这种类型的代理还需要了解RTSP端点功能，即除了代理所需的功能之外，还需要在Require头中标识的功能。
Access Proxy: This type of proxy is used to ensure that an RTSP client gets access to servers on an external network. Thus, this proxy is placed on the border between two domains, e.g., a private address space and the public Internet. The proxy performs the necessary translation, usually addresses. This type of proxy is required to redirect the media to itself or a controlled gateway that performs the translation before the media can reach the client.
访问代理：这种类型的代理用于确保RTSP客户端能够访问外部网络上的服务器。因此，该代理被放置在两个域之间的边界上，例如，私有地址空间和公共互联网。代理执行必要的转换，通常是地址转换。在媒体到达客户端之前，需要使用这种类型的代理将媒体重定向到自身或执行翻译的受控网关。
Security Proxy: This type of proxy is used to help facilitate security functions around RTSP. For example, in the case of a firewalled network, the security proxy requests that the necessary pinholes in the firewall are opened when a client in the protected network wants to access media streams on the external side. This proxy can perform its function without redirecting the media between the server and client. However, in deployments with private address spaces, this proxy is likely to be combined with the access proxy. The functionality of this proxy is usually closely tied into understanding all aspects of the media transport.
安全代理：这种类型的代理用于帮助简化RTSP的安全功能。例如，在防火墙网络的情况下，当受保护网络中的客户端想要访问外部的媒体流时，安全代理请求打开防火墙中必要的针孔。此代理可以执行其功能，而无需在服务器和客户端之间重定向媒体。但是，在具有专用地址空间的部署中，此代理可能会与访问代理结合使用。该代理的功能通常与理解媒体传输的各个方面紧密相关。
Auditing Proxy: RTSP proxies can also provide network owners with a logging and auditing point for RTSP sessions, e.g., for corporations that track their employees usage of the network. 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.
审计代理：RTSP代理还可以为网络所有者提供RTSP会话的日志记录和审计点，例如，为跟踪其员工网络使用情况的公司。这种类型的代理可以执行其功能，而无需在媒体传输中插入自身或任何其他节点。此代理类型还可以接受未知方法，因为它不会干扰客户端的请求。
All types of proxies can also be used when using secured communication 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. However, that trust model may not be suitable for all types of deployment. In those cases, the secured sessions do bypass the proxies.
当使用与TLS的安全通信时，也可以使用所有类型的代理，因为RTSP 2.0允许客户端批准用于从代理建立连接的证书链；见第19.3.2节。但是，该信任模型可能并不适用于所有类型的部署。在这些情况下，安全会话确实会绕过代理。
Access proxies SHOULD NOT be used in equipment like NATs and firewalls that aren't expected to be regularly maintained, like home or small office equipment. In these cases, it is better to use the NAT traversal procedures defined for RTSP 2.0 [RFC7825]. The reason for these recommendations is that any extensions of RTSP resulting in new media-transport protocols or profiles, new parameters, etc., may fail in a proxy that isn't maintained. This would impede RTSP's future development and usage.
访问代理不应用于NAT和防火墙等不需要定期维护的设备，如家庭或小型办公设备。在这些情况下，最好使用为RTSP 2.0定义的NAT遍历过程[RFC7825]。这些建议的原因是，导致新媒体传输协议或配置文件、新参数等的任何RTSP扩展都可能在未维护的代理中失败。这将阻碍RTSP的未来发展和使用。
The existence of proxies must always be considered when developing new RTSP extensions. Most types of proxies will need to implement any new method to operate correctly in the presence of that extension. New headers can be introduced and will not be blocked by older proxies. However, it is important to consider if this header and its function are required to be understood by the proxy or if it can be simply forwarded. If the header needs to be understood, a feature tag representing the functionality MUST be included in the Proxy-Require header. Below are guidelines for analysis whether the header needs to be understood. The Transport header and its parameters are extensible, which requires handling rules for a proxy in order to ensure a correct interpretation.
在开发新的RTSP扩展时，必须始终考虑代理的存在。大多数类型的代理都需要实现任何新方法，才能在该扩展存在的情况下正确运行。可以引入新的头，并且不会被旧的代理阻止。然而，重要的是要考虑该报头及其功能是否需要被代理理解，或者是否可以简单地转发。如果需要理解头，则必须在代理请求头中包含表示功能的功能标签。下面是分析是否需要理解标题的指南。传输头及其参数是可扩展的，这需要代理的处理规则，以确保正确的解释。
Whether or not a proxy needs to understand a header is not easy to determine as they serve a broad variety of functions. When evaluating if a header needs to be understood, one can divide the functionality into three main categories:
代理是否需要理解头并不容易确定，因为它们服务于各种各样的功能。在评估是否需要理解标题时，可以将功能分为三大类：
Media modifying: The caching and translator proxies modify the actual media and therefore need also to understand the request directed to the server that affects how the media is rendered. Thus, this type of proxy also needs to understand the server-side functionality.
介质修改：缓存和转换器代理修改实际介质，因此还需要了解指向服务器的请求，该请求会影响介质的呈现方式。因此，这种类型的代理还需要了解服务器端功能。
Transport modifying: The access and the security proxy both need to understand how the media transport is performed, either for opening pinholes or translating the outer headers, e.g., IP and UDP or TCP.
传输修改：访问和安全代理都需要了解媒体传输是如何执行的，无论是打开针孔还是转换外部头，例如IP和UDP或TCP。
Non-modifying: The audit proxy is special in that it does not modify the messages in other ways than to insert the Via header. That makes it possible for this type to forward RTSP messages that contain different types of unknown methods, headers, or header parameters.
非修改：审核代理的特殊之处在于它不会以插入Via头以外的其他方式修改消息。这使得该类型可以转发包含不同类型的未知方法、头或头参数的RTSP消息。
An extension has to be classified as mandatory to be implemented for a proxy, if an extension has to be understood by a "Transport modifying" type of proxy.
如果扩展必须被“传输修改”类型的代理所理解，那么扩展必须被分类为必须为代理实现的扩展。
RTSP proxies may have to multiplex several RTSP sessions from their clients towards RTSP servers. This requires that RTSP requests from multiple clients be multiplexed onto a common connection for requests outgoing to an RTSP server, and, on the way back, the responses be demultiplexed from the server to per-client responses. On the protocol level, this requires that request and response messages be handled in both directions, requiring that there be a mechanism to correlate which request/response pair exchanged between proxy and server is mapped to which client (or client request).
RTSP代理可能必须将多个RTSP会话从其客户端多路传输到RTSP服务器。这需要将来自多个客户端的RTSP请求多路复用到一个公共连接上，以便将请求传出RTSP服务器，并且在返回的过程中，将响应从服务器解复用到每个客户端响应。在协议级别上，这需要在两个方向上处理请求和响应消息，需要有一种机制来关联代理和服务器之间交换的请求/响应对映射到哪个客户端（或客户端请求）。
This multiplexing of requests and demultiplexing of responses is done by using the CSeq header field. The proxy has to rewrite the CSeq in requests to the server and responses from the server and remember which CSeq is mapped to which client. The proxy also needs to ensure that the order of the message related to each client is maintained. Section 18.20 defines the handling of how requests and responses are rewritten.
请求的多路复用和响应的解多路复用是通过使用CSeq头字段完成的。代理必须在对服务器的请求和来自服务器的响应中重写CSeq，并记住哪个CSeq映射到哪个客户端。代理还需要确保维护与每个客户端相关的消息顺序。第18.20节定义了如何重写请求和响应。
In HTTP, request/response pairs are cached. RTSP differs significantly in that respect. Responses are not cacheable, with the exception of the presentation description returned by DESCRIBE. (Since the responses for anything but DESCRIBE and GET_PARAMETER do not return any data, caching is not really an issue for these requests.) However, it is desirable for the continuous media data, typically delivered out-of-band with respect to RTSP, to be cached, as well as the session description.
在HTTP中，请求/响应对被缓存。RTSP在这方面有很大不同。响应不可缓存，由descripe返回的演示文稿描述除外。（由于除descripe和GET_参数外的任何响应都不会返回任何数据，因此缓存对于这些请求来说并不是一个真正的问题。）但是，需要缓存连续媒体数据（通常在RTSP带外传输）以及会话描述。
On receiving a SETUP or PLAY request, a proxy ascertains whether it has an up-to-date copy of the continuous media content and its description. It can determine whether the copy is up to date by issuing a SETUP or DESCRIBE request, respectively, and comparing the Last-Modified header with that of the cached copy. If the copy is not up to date, it modifies the SETUP transport parameters as appropriate and forwards the request to the origin server. Subsequent control commands such as PLAY or PAUSE then pass the proxy unmodified. The proxy delivers the continuous media data to the client, while possibly making a local copy for later reuse. The exact allowed behavior of the cache is given by the cache-response directives described in Section 18.11. A cache MUST answer any DESCRIBE requests if it is currently serving the stream to the requester, as it is possible that low-level details of the stream description may have changed on the origin server.
在收到设置或播放请求时，代理确定其是否具有连续媒体内容及其描述的最新副本。它可以通过分别发出SETUP或Descripte请求并将上次修改的头与缓存副本的头进行比较来确定副本是否是最新的。如果副本不是最新的，它会根据需要修改设置传输参数，并将请求转发给源服务器。随后的控制命令（如播放或暂停）会在未修改的情况下传递代理。代理将连续媒体数据传送到客户端，同时可能制作一个本地副本供以后重用。第18.11节中描述的缓存响应指令给出了缓存的确切允许行为。如果缓存当前正在向请求者提供流，那么它必须回答任何descripe请求，因为源服务器上流描述的低级细节可能已经更改。
Note that an RTSP cache is of the "cut-through" variety. Rather than retrieving the whole resource from the origin server, the cache simply copies the streaming data as it passes by on its way to the client. Thus, it does not introduce additional latency.
请注意，RTSP缓存属于“直通”类型。缓存不会从源服务器检索整个资源，而是在流数据传递到客户端时简单地复制流数据。因此，它不会引入额外的延迟。
To the client, an RTSP proxy cache appears like a regular media server. To the media origin server, an RTSP proxy cache appears like a client. Just as an HTTP cache has to store the content type, content language, and so on for the objects it caches, a media cache has to store the presentation description. Typically, a cache eliminates all transport references (e.g., multicast information) from the presentation description, since these are independent of the data delivery from the cache to the client. Information on the encodings remains the same. If the cache is able to translate the cached media data, it would create a new presentation description with all the encoding possibilities it can offer.
对于客户端来说，RTSP代理缓存看起来就像普通的媒体服务器。对于媒体源服务器，RTSP代理缓存看起来像客户端。正如HTTP缓存必须存储其缓存对象的内容类型、内容语言等，媒体缓存也必须存储表示描述。通常，缓存从表示描述中消除所有传输引用（例如，多播信息），因为这些传输引用独立于从缓存到客户端的数据交付。有关编码的信息保持不变。如果缓存能够转换缓存的媒体数据，它将创建一个新的表示描述，并提供所有可能的编码。
When a cache has a stale entry that it would like to use as a response to a client's request, it first has to check with the origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. This is called "validating" the cache entry. To avoid having to pay the overhead of retransmitting the full response if the cached entry is good, and at the same time avoiding having to pay the overhead of an extra round trip if the cached entry is invalid, RTSP supports the use of conditional methods.
当缓存有一个过时的条目要用作对客户端请求的响应时，它首先必须与源服务器（或者可能是具有新响应的中间缓存）检查其缓存条目是否仍然可用。这称为“验证”缓存项。为了避免在缓存项良好时必须支付重新传输完整响应的开销，同时避免在缓存项无效时必须支付额外往返的开销，RTSP支持使用条件方法。
The key protocol features for supporting conditional methods are those concerned with "cache validators." When an origin server generates a full response, it attaches some sort of validator to it, which is kept with the cache entry. When a client (user agent or proxy cache) makes a conditional request for a resource for which it has a cache entry, it includes the associated validator in the request.
支持条件方法的关键协议特性与“缓存验证器”有关。当源服务器生成完整响应时，它会向其附加某种验证器，该验证器与缓存条目一起保存。当客户端（用户代理或代理缓存）对其具有缓存项的资源发出有条件请求时，它会在请求中包含关联的验证器。
The server then checks that validator against the current validator for the requested resource, and, if they match (see Section 16.1.3), it responds with a special status code (usually, 304 (Not Modified)) and no message body. Otherwise, it returns a full response (including message body). Thus, avoiding transmitting the full response if the validator matches and avoiding an extra round trip if it does not match.
然后，服务器根据请求的资源的当前验证器检查该验证器，如果它们匹配（请参见第16.1.3节），它将使用特殊的状态代码（通常为304（未修改））和无消息正文进行响应。否则，它将返回完整响应（包括消息体）。因此，避免在验证程序匹配时发送完整响应，并避免在不匹配时发送额外的往返。
In RTSP, a conditional request looks exactly the same as a normal request for the same resource, except that it carries a special header (which includes the validator) that implicitly turns the method (usually DESCRIBE or SETUP) into a conditional.
在RTSP中，条件请求看起来与对相同资源的正常请求完全相同，只是它带有一个特殊的头（包括验证器），该头隐式地将方法（通常是描述或设置）转换为条件请求。
The protocol includes both positive and negative senses of cache-validating conditions. That is, it is possible to request that a method be performed either if and only if a validator matches or if and only if no validators match.
该协议包括缓存验证条件的积极意义和消极意义。也就是说，当且仅当验证器匹配或当且仅当没有验证器匹配时，可以请求执行方法。
Note: a response that lacks a validator may still be cached, and served from cache until it expires, unless this is explicitly prohibited by a cache directive (see Section 18.11). However, a cache cannot perform a conditional retrieval if it does not have a validator for the resource, which means it will not be refreshable after it expires.
注意：缺少验证器的响应仍然可以被缓存，并从缓存中服务，直到过期，除非缓存指令明确禁止（参见第18.11节）。但是，如果缓存没有资源的验证程序，则无法执行条件检索，这意味着它在过期后将无法刷新。
Media streams that are being adapted based on the transport capacity between the server and the cache make caching more difficult. A server needs to consider how it views the caching of media streams that it adapts and potentially instruct any caches not to cache such streams.
根据服务器和缓存之间的传输容量调整的媒体流使缓存更加困难。服务器需要考虑它如何看待它所适应的媒体流的缓存，并可能指示任何缓存不缓存这些流。
The Last-Modified header (Section 18.27) value is often used as a cache validator. In simple terms, a cache entry is considered to be valid if the cache entry was created after the Last-Modified time.
最后修改的标头（第18.27节）值通常用作缓存验证程序。简单来说，如果缓存项是在上次修改时间之后创建的，则认为缓存项有效。
The MTag response-header field-value, a message body tag, provides for an "opaque" cache validator. This might allow more reliable validation in situations where it is inconvenient to store modification dates, where the one-second resolution of RTSP-date values is not sufficient, or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification dates.
MTag响应头字段值（消息正文标记）提供“不透明”缓存验证器。在不方便存储修改日期、RTSP日期值的1秒分辨率不够、或者源服务器希望避免由于使用修改日期而产生的某些矛盾的情况下，这可能允许更可靠的验证。
Message body tags are described in Section 4.6
第4.6节描述了消息正文标记
Since both origin servers and caches will compare two validators to decide if they represent the same or different entities, one normally would expect that if the message body (i.e., the presentation description) or any associated message body headers changes in any way, then the associated validator would change as well. If this is true, then this validator is a "strong validator". The Message body (i.e., the presentation description) or any associated message body headers is named an entity for a better understanding.
由于源服务器和缓存都将比较两个验证器，以确定它们代表的是相同的还是不同的实体，因此人们通常认为，如果消息体（即表示描述）或任何关联的消息体标头以任何方式发生更改，则关联的验证器也将发生更改。如果这是真的，那么这个验证器就是一个“强验证器”。为了更好地理解，将消息体（即表示描述）或任何关联的消息体头命名为实体。
However, there might be cases when a server prefers to change the validator only on semantically significant changes and not when insignificant aspects of the entity change. A validator that does not always change when the resource changes is a "weak validator".
但是，可能存在这样的情况：服务器只希望在语义上发生重大更改时更改验证器，而不希望在实体的不重要方面发生更改时更改验证器。当资源更改时不总是更改的验证器是“弱验证器”。
Message body tags are normally strong validators, but the protocol provides a mechanism to tag a message body tag as "weak". One can think of a strong validator as one that changes whenever the bits of an entity changes, while a weak value changes whenever the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific entity, while a weak validator is part of an identifier for a set of semantically equivalent entities.
消息体标记通常是强验证器，但该协议提供了一种将消息体标记标记为“弱”的机制。我们可以将强验证器视为在实体的位发生变化时进行更改的验证器，而弱值在实体的含义发生变化时进行更改。或者，可以将强验证器视为特定实体标识符的一部分，而弱验证器是语义等价实体集合标识符的一部分。
Note: One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed.
注意：强验证器的一个例子是一个整数，它在稳定存储中每次更改实体时都会递增。
An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible that the resource might be modified twice during a single second.
一个实体的修改时间，如果用1秒的分辨率表示，可能是一个弱验证器，因为可能在一秒钟内修改两次资源。
Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects.
对弱验证器的支持是可选的。但是，弱验证器允许更有效地缓存等效对象。
A "use" of a validator is either when a client generates a request and includes the validator in a validating header field or when a server compares two validators.
验证程序的“使用”是指客户端生成请求并将验证程序包含在验证头字段中，或者服务器比较两个验证程序。
Strong validators are usable in any context. Weak validators are only usable in contexts that do not depend on exact equality of an entity. For example, either kind is usable for a conditional DESCRIBE of a full entity. However, only a strong validator is usable for a subrange retrieval, since otherwise the client might end up with an internally inconsistent entity.
强验证器在任何上下文中都是可用的。弱验证器仅在不依赖于实体完全相等的上下文中可用。例如，任何一种都可用于完整实体的条件描述。但是，只有强验证器可用于子范围检索，因为否则客户端可能最终会得到一个内部不一致的实体。
Clients MAY issue DESCRIBE requests with either weak or strong validators. Clients MUST NOT use weak validators in other forms of requests.
客户端可以使用弱验证器或强验证器发出描述请求。客户端不得在其他形式的请求中使用弱验证器。
The only function that RTSP defines on validators is comparison. There are two validator comparison functions, depending on whether or not the comparison context allows the use of weak validators:
RTSP在验证器上定义的唯一功能是比较。根据比较上下文是否允许使用弱验证器，有两个验证器比较函数：
o The strong comparison function: in order to be considered equal, both validators MUST be identical in every way, and both MUST NOT be weak.
o 强比较函数：为了被认为是相等的，两个验证器在各个方面都必须是相同的，并且都不能是弱的。
o The weak comparison function: in order to be considered equal, both validators MUST be identical in every way, but either or both of them MAY be tagged as "weak" without affecting the result.
o 弱比较函数：为了被认为是相等的，两个验证器在各个方面都必须相同，但其中一个或两个都可以标记为“弱”，而不影响结果。
A message body tag is strong unless it is explicitly tagged as weak.
消息正文标记是强的，除非它被显式标记为弱。
A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is strong, using the following rules:
当在请求中用作验证器时，上一次修改的时间隐式弱，除非可以使用以下规则推断它是强的：
o The validator is being compared by an origin server to the actual current validator for the entity and,
o 源服务器正在将验证程序与实体的实际当前验证程序进行比较，
o That origin server reliably knows that the associated entity did not change more than once during the second covered by the presented validator.
o 该源服务器可靠地知道，关联实体在当前验证器覆盖的第二个过程中没有多次更改。
OR
或
o The validator is about to be used by a client in an If-Modified-Since, because the client has a cache entry for the associated entity, and
o 验证程序将由客户机在If-Modified-Since中使用，因为客户机具有关联实体的缓存项，并且
o That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
o 该缓存条目包含一个日期值，该值给出源服务器发送原始响应的时间，以及
o The presented Last-Modified time is at least 60 seconds before the Date value.
o 显示的上次修改时间至少比日期值早60秒。
OR
或
o The validator is being compared by an intermediate cache to the validator stored in its cache entry for the entity, and
o 中间缓存正在将验证程序与存储在实体缓存项中的验证程序进行比较，以及
o That cache entry includes a Date value, which gives the time when the origin server sent the original response, and
o 该缓存条目包含一个日期值，该值给出源服务器发送原始响应的时间，以及
o The presented Last-Modified time is at least 60 seconds before the Date value.
o 显示的上次修改时间至少比日期值早60秒。
This method relies on the fact that if two different responses were sent by the origin server during the same second, but both had the same Last-Modified time, then at least one of those responses would have a Date value equal to its Last-Modified time. The arbitrary 60-second limit guards against the possibility that the Date and Last-Modified values are generated from different clocks or at somewhat different times during the preparation of the response. An implementation MAY use a value larger than 60 seconds, if it is believed that 60 seconds is too short.
此方法依赖于这样一个事实：如果源服务器在同一秒钟内发送了两个不同的响应，但都具有相同的上次修改时间，则这些响应中至少有一个的日期值等于其上次修改的时间。任意的60秒限制可以防止日期和最后修改的值是在响应准备期间从不同的时钟或在稍微不同的时间生成的。如果认为60秒太短，则实现可以使用大于60秒的值。
If a client wishes to perform a subrange retrieval on a value for which it has only a Last-Modified time and no opaque validator, it MAY do this only if the Last-Modified time is strong in the sense described here.
如果客户端希望对其只有上次修改时间且没有不透明验证器的值执行子范围检索，则仅当上次修改时间在此处描述的意义上很强时，它才可以执行此操作。
This document adopts a set of rules and recommendations for origin servers, clients, and caches regarding when various validator types ought to be used, and for what purposes.
本文档针对源服务器、客户机和缓存采用了一组规则和建议，这些规则和建议涉及何时应该使用各种验证器类型以及用于什么目的。
RTSP origin servers:
RTSP源服务器：
o SHOULD send a message body tag validator unless it is not feasible to generate one.
o 应发送消息正文标记验证器，除非生成消息正文标记验证器不可行。
o MAY send a weak message body tag instead of a strong message body tag, if performance considerations support the use of weak message body tags, or if it is unfeasible to send a strong message body tag.
o 如果性能考虑支持使用弱消息正文标记，或者如果无法发送强消息正文标记，则可以发送弱消息正文标记而不是强消息正文标记。
o SHOULD send a Last-Modified value if it is feasible to send one, unless the risk of a breakdown in semantic transparency that could result from using this date in an If-Modified-Since header would lead to serious problems. In other words, the preferred behavior for an RTSP origin server is to send both a strong message body tag and a Last-Modified value.
o 如果发送一个值是可行的，则应发送一个上次修改的值，除非在if-Modified-Since头中使用此日期可能导致语义透明度崩溃的风险会导致严重问题。换句话说，RTSP源服务器的首选行为是发送强消息体标记和上次修改的值。
In order to be legal, a strong message body tag MUST change whenever the associated entity value changes in any way. A weak message body tag SHOULD change whenever the associated entity changes in a semantically significant way.
为了合法，每当相关实体值以任何方式更改时，强消息体标记必须更改。弱消息体标记应该在关联实体以语义上重要的方式更改时更改。
Note: in order to provide semantically transparent caching, an origin server MUST avoid reusing a specific strong message body tag value for two different entities or reusing a specific weak message body tag value for two semantically different entities. Cache entries might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to expect that a cache will never again attempt to validate an entry using a validator that it obtained at some point in the past.
注意：为了提供语义透明的缓存，源服务器必须避免为两个不同的实体重用特定的强消息体标记值，或为两个语义不同的实体重用特定的弱消息体标记值。缓存项可能会持续任意长的时间，而不管过期时间如何，因此，期望缓存不会再次尝试使用在过去某个时间获得的验证器来验证项可能是不合适的。
RTSP clients:
RTSP客户端：
o If a message body tag has been provided by the origin server, MUST use that message body tag in any cache-conditional request (using If-Match or If-None-Match).
o 如果原始服务器提供了消息正文标记，则必须在任何缓存条件请求中使用该消息正文标记（使用If-Match或If-None-Match）。
o If only a Last-Modified value has been provided by the origin server, SHOULD use that value in non-subrange cache-conditional requests (using If-Modified-Since).
o 如果源服务器只提供了上次修改的值，则应在非子范围缓存条件请求中使用该值（使用If-Modified-Since）。
o If both a message body tag and a Last-Modified value have been provided by the origin server, SHOULD use both validators in cache-conditional requests.
o 如果源服务器同时提供了消息正文标记和上次修改的值，则应该在缓存条件请求中使用这两个验证器。
An RTSP origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since header) and one or more message body tags (e.g., in an If-Match,
RTSP源服务器在接收到包括最后修改日期（例如，在If Modified-Since标头中）和一个或多个消息正文标记（例如，在If匹配中）的条件请求时，
If-None-Match, or If-Range header field) as cache validators, MUST NOT return a response status of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields in the request.
如果不匹配，或者如果范围标头字段）作为缓存验证器，则不得返回304（未修改）的响应状态，除非这样做与请求中的所有条件标头字段一致。
Note: The general principle behind these rules is that RTSP servers and clients should transmit as much non-redundant information as is available in their responses and requests. RTSP systems receiving this information will make the most conservative assumptions about the validators they receive.
注意：这些规则背后的一般原则是RTSP服务器和客户端应传输其响应和请求中可用的尽可能多的非冗余信息。接收此信息的RTSP系统将对其接收的验证器做出最保守的假设。
The principle behind message body tags is that only the service author knows the semantics of a resource well enough to select an appropriate cache validation mechanism, and the specification of any validator comparison function more complex than octet equality would open up a can of worms. Thus, comparisons of any other headers are never used for purposes of validating a cache entry.
消息体标记背后的原理是，只有服务作者足够了解资源的语义，能够选择适当的缓存验证机制，并且任何比八位字节相等更复杂的验证器比较函数的规范都会引发一系列蠕虫。因此，任何其他头的比较都不会用于验证缓存项。
The effect of certain methods performed on a resource at the origin server might cause one or more existing cache entries to become non-transparently invalid. That is, although they might continue to be "fresh," they do not accurately reflect what the origin server would return for a new request on that resource.
对源服务器上的资源执行的某些方法可能会导致一个或多个现有缓存项变为非透明无效。也就是说，尽管它们可能仍然是“新鲜的”，但它们并不能准确地反映源服务器将为该资源上的新请求返回什么。
There is no way for RTSP to guarantee that all such cache entries are marked invalid. For example, the request that caused the change at the origin server might not have gone through the proxy where a cache entry is stored. However, several rules help reduce the likelihood of erroneous behavior.
RTSP无法保证所有此类缓存项都标记为无效。例如，在源服务器上导致更改的请求可能没有通过存储缓存项的代理。然而，一些规则有助于降低错误行为的可能性。
In this section, the phrase "invalidate an entity" means that the cache will either remove all instances of that entity from its storage or mark these as "invalid" and in need of a mandatory revalidation before they can be returned in response to a subsequent request.
在本节中，短语“使实体无效”表示缓存将从其存储中删除该实体的所有实例，或将这些实例标记为“无效”，并需要强制重新验证，然后才能返回这些实例以响应后续请求。
Some RTSP methods MUST cause a cache to invalidate an entity. This is either the entity referred to by the Request-URI or by the Location or Content-Location headers (if present). These methods are:
某些RTSP方法必须导致缓存使实体无效。这是请求URI或位置或内容位置头（如果存在）引用的实体。这些方法是：
o DESCRIBE
o 描述
o SETUP
o 设置
In order to prevent DoS attacks, an invalidation based on the URI in a Location or Content-Location header MUST only be performed if the host part is the same as in the Request-URI.
为了防止DoS攻击，只有在主机部分与请求URI相同时，才能基于位置或内容位置标头中的URI执行失效。
A cache that passes through requests for methods it does not understand SHOULD invalidate any entities referred to by the Request-URI.
通过对其不理解的方法的请求的缓存应该使请求URI引用的任何实体无效。
Where applicable, HTTP status codes (see Section 6 of [RFC7231]) are reused. See Table 4 in Section 8.1 for a listing of which status codes may be returned by which requests. All error messages, 4xx and 5xx, MAY return a body containing further information about the error.
在适用的情况下，HTTP状态代码（见[RFC7231]第6节）可重复使用。请参阅第8.1节中的表4，了解哪些请求可能返回哪些状态代码。所有错误消息（4xx和5xx）都可能返回一个正文，其中包含有关错误的更多信息。
The requesting agent SHOULD continue with its request. This interim response is used to inform the requesting agent that the initial part of the request has been received and has not yet been rejected by the responding agent. The requesting agent SHOULD continue by sending the remainder of the request or, if the request has already been completed, continue to wait for a final response (see Section 10.4). The responding agent MUST send a final response after the request has been completed.
请求代理应继续其请求。此临时响应用于通知请求代理，请求的初始部分已收到，且尚未被响应代理拒绝。请求代理应继续发送请求的其余部分，或者，如果请求已经完成，则继续等待最终响应（见第10.4节）。响应代理必须在请求完成后发送最终响应。
This class of status code indicates that the agent's request was successfully received, understood, and accepted.
此类状态代码表示代理的请求已成功接收、理解和接受。
The request has succeeded. The information returned with the response is dependent on the method used in the request.
请求已成功。随响应返回的信息取决于请求中使用的方法。
The notation "3xx" indicates response codes from 300 to 399 inclusive that are meant for redirection. We use the notation "3rr" to indicate all 3xx codes used for redirection, i.e., excluding 304. The 304 response code appears here, rather than a 2xx response code, which would have been appropriate; 304 has also been used in RTSP 1.0 [RFC2326].
符号“3xx”表示300到399（含300到399）之间用于重定向的响应代码。我们使用符号“3rr”表示用于重定向的所有3xx代码，即不包括304。此处显示的是304响应代码，而不是2xx响应代码，这是合适的；304还用于RTSP 1.0[RFC2326]。
Within RTSP, redirection may be used for load-balancing or redirecting stream requests to a server topologically closer to the agent. Mechanisms to determine topological proximity are beyond the scope of this specification.
在RTSP中，重定向可用于负载平衡或将流请求重定向到拓扑上更靠近代理的服务器。确定拓扑邻近性的机制超出了本规范的范围。
A 3rr code MAY be used to respond to any request. The Location header MUST be included in any 3rr response. It is RECOMMENDED that they are used if necessary before a session is established, i.e., in response to DESCRIBE or SETUP. However, in cases where a server is not able to send a REDIRECT request to the agent, the server MAY need to resort to using 3rr responses to inform an agent with an established session about the need for redirecting the session. If a 3rr response is received for a request in relation to an established session, the agent SHOULD send a TEARDOWN request for the session and MAY reestablish the session using the resource indicated by the Location.
3rr代码可用于响应任何请求。位置标头必须包含在任何3rr响应中。如有必要，建议在建立会话之前使用它们，即响应描述或设置。但是，在服务器无法向代理发送重定向请求的情况下，服务器可能需要使用3rr响应通知具有已建立会话的代理重定向会话的需要。如果收到与已建立会话相关的请求的3rr响应，则代理应发送会话的拆卸请求，并可使用位置指示的资源重新建立会话。
If the Location header is used in a response, it MUST contain an absolute URI pointing out the media resource the agent is redirected to; the URI MUST NOT only contain the hostname.
如果在响应中使用位置头，它必须包含一个绝对URI，指出代理重定向到的媒体资源；URI不能只包含主机名。
In the event that an unknown 3rr status code is received, the agent SHOULD behave as if a 302 response code had been received (Section 17.3.3).
如果收到未知的3rr状态代码，则代理应表现为收到302响应代码（第17.3.3节）。
The 300 response code is not used in RTSP 2.0.
RTSP 2.0中未使用300响应代码。
The requested resource is moved permanently and resides now at the URI given by the Location header. The user agent SHOULD redirect automatically to the given URI. This response MUST NOT contain a message body. The Location header MUST be included in the response.
请求的资源被永久移动，并且现在驻留在Location标头给定的URI上。用户代理应该自动重定向到给定的URI。此响应不得包含消息正文。响应中必须包含位置标头。
The requested resource resides temporarily at the URI given by the Location header. This response is intended to be used for many types of temporary redirects, e.g., load balancing. It is RECOMMENDED that the server set the reason phrase to something more meaningful than "Found" in these cases. The Location header MUST be included in the response. The user agent SHOULD redirect automatically to the given URI. This response MUST NOT contain a message body.
请求的资源临时驻留在Location标头给定的URI处。此响应用于许多类型的临时重定向，例如负载平衡。在这些情况下，建议服务器将原因短语设置为比“找到”更有意义的内容。响应中必须包含位置标头。用户代理应该自动重定向到给定的URI。此响应不得包含消息正文。
This example shows a client being redirected to a different server:
此示例显示将客户端重定向到其他服务器：
C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2
C->S: SETUP rtsp://example.com/fizzle/foo RTSP/2.0
CSeq: 2
Transport: RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 302 Try Other Server
CSeq: 2
Location: rtsp://s2.example.com:8001/fizzle/foo
S->C: RTSP/2.0 302 Try Other Server
CSeq: 2
Location: rtsp://s2.example.com:8001/fizzle/foo
This status code MUST NOT be used in RTSP 2.0. However, it was allowed in RTSP 1.0 [RFC2326].
RTSP 2.0中不得使用此状态代码。但是，RTSP 1.0[RFC2326]中允许使用此选项。
If the agent has performed a conditional DESCRIBE or SETUP (see Sections 18.25 and 18.26) and the requested resource has not been modified, the server SHOULD send a 304 response. This response MUST NOT contain a message body.
如果代理已执行条件描述或设置（请参阅第18.25和18.26节），且请求的资源尚未修改，则服务器应发送304响应。此响应不得包含消息正文。
The response MUST include the following header fields:
响应必须包括以下标题字段：
o Date
o 日期
o MTag or Content-Location, if the headers would have been sent in a 200 response to the same request.
o MTag或内容位置，前提是标题已在对同一请求的200响应中发送。
o Expires and Cache-Control if the field-value might differ from that sent in any previous response for the same variant.
o 如果字段值可能与之前针对同一变量的任何响应中发送的值不同，则过期并缓存控制。
This response is independent for the DESCRIBE and SETUP requests. That is, a 304 response to DESCRIBE does NOT imply that the resource content is unchanged (only the session description) and a 304 response to SETUP does NOT imply that the resource description is unchanged. The MTag and If-Match header (Section 18.24) may be used to link the DESCRIBE and SETUP in this manner.
此响应独立于描述和设置请求。也就是说，304对description的响应并不意味着资源内容没有改变（仅会话描述），304对SETUP的响应也不意味着资源描述没有改变。MTag和If Match标题（第18.24节）可用于以这种方式链接描述和设置。
The requested resource MUST be accessed through the proxy given by the Location header that MUST be included. The Location header field-value gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers.
请求的资源必须通过必须包含的Location标头提供的代理进行访问。Location header字段值给出代理的URI。收件人应通过代理重复此单个请求。305响应只能由源服务器生成。
The request could not be understood by the agent due to malformed syntax. The agent SHOULD NOT repeat the request without modifications. If the request does not have a CSeq header, the agent MUST NOT include a CSeq in the response.
由于语法错误，代理无法理解该请求。代理不应在没有修改的情况下重复请求。如果请求没有CSeq头，则代理不能在响应中包含CSeq。
The request requires user authentication using the HTTP authentication mechanism [RFC7235]. The usage of the error code is defined in [RFC7235] and any applicable HTTP authentication scheme, such as Digest [RFC7616]. The response is to include a WWW-Authenticate header (Section 18.58) field containing a challenge applicable to the requested resource. The agent can repeat the request with a suitable Authorization header field. If the request already included authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the message body that was given in the response, since that message body might include relevant diagnostic information.
请求需要使用HTTP身份验证机制[RFC7235]进行用户身份验证。错误代码的用法在[RFC7235]和任何适用的HTTP身份验证方案（如摘要[RFC7616]）中定义。响应包括一个WWW-Authenticate报头（第18.58节）字段，其中包含适用于请求资源的质询。代理可以使用合适的授权标头字段重复请求。如果请求已包括授权凭据，则401响应表示已拒绝这些凭据的授权。如果401响应包含与先前响应相同的质询，并且用户代理已至少尝试了一次身份验证，则应向用户呈现响应中给出的消息正文，因为该消息正文可能包括相关诊断信息。
This code is reserved for future use.
此代码保留供将来使用。
The agent understood the request, but is refusing to fulfill it. Authorization will not help, and the request SHOULD NOT be repeated. If the agent wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the message body. If the agent does not wish to make this information available to the agent, the status code 404 (Not Found) can be used instead.
代理理解该请求，但拒绝履行。授权没有帮助，请求不应重复。如果代理希望公开未满足请求的原因，则应在消息正文中说明拒绝的原因。如果代理不希望将此信息提供给代理，则可以使用状态代码404（未找到）。
The agent has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the agent knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.
代理未找到任何与请求URI匹配的内容。没有说明该情况是暂时的还是永久的。如果代理通过一些内部可配置的机制知道旧资源永久不可用且没有转发地址，则应使用410（Gone）状态代码。
This status code is commonly used when the agent does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
当代理不想透露请求被拒绝的确切原因或没有其他响应适用时，通常使用此状态代码。
The method specified in the request is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource. This status code is also to be used if a request attempts to use a method not indicated during SETUP.
请求URI标识的资源不允许使用请求中指定的方法。响应必须包含一个Allow标头，其中包含请求资源的有效方法列表。如果请求试图使用安装过程中未指示的方法，也将使用此状态代码。
The resource identified by the request is only capable of generating response message bodies that have content characteristics not acceptable according to the Accept headers sent in the request.
根据请求中发送的Accept标头，请求标识的资源只能生成具有不可接受内容特征的响应消息正文。
The response SHOULD include a message body containing a list of available message body characteristics and location(s) from which the user or user agent can choose the one most appropriate. The message body format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.
响应应包括消息正文，其中包含可用消息正文特征和位置的列表，用户或用户代理可从中选择最合适的消息正文特征和位置。消息正文格式由内容类型标头字段中给定的媒体类型指定。根据用户代理的格式和能力，可以自动执行最合适的选择。然而，本规范并未定义此类自动选择的任何标准。
If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.
如果响应可能不可接受，则用户代理应暂时停止接收更多数据，并向用户查询有关进一步操作的决定。
This code is similar to 401 (Unauthorized) (Section 17.4.2), but it indicates that the client must first authenticate itself with the proxy. The usage of this error code is defined in [RFC7235] and any applicable HTTP authentication scheme, such as Digest [RFC7616]. The proxy MUST return a Proxy-Authenticate header field (Section 18.34) containing a challenge applicable to the proxy for the requested resource.
此代码类似于401（未经授权）（第17.4.2节），但它表示客户端必须首先向代理进行身份验证。[RFC7235]和任何适用的HTTP身份验证方案（如摘要[RFC7616]）中定义了此错误代码的用法。代理必须返回一个代理身份验证标头字段（第18.34节），其中包含适用于所请求资源的代理的质询。
The agent did not produce a request within the time that the agent was prepared to wait. The agent MAY repeat the request without modifications at any later time.
代理在准备等待的时间内未生成请求。代理可以在以后的任何时间重复请求而不进行修改。
The requested resource is no longer available at the server and the forwarding address is not known. This condition is expected to be considered permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.
请求的资源在服务器上不再可用，转发地址未知。预计这种情况将被视为永久性的。如果服务器不知道或无法确定该状况是否为永久性，则应使用状态代码404（未找到）。除非另有说明，否则此响应是可缓存的。
The 410 response is primarily intended to assist the task of repository maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the owner of the server.
410响应主要用于通过通知接收者资源有意不可用以及服务器所有者希望删除指向该资源的远程链接来协助存储库维护任务。此类活动在有限的时间、促销服务和不再在服务器站点工作的个人资源中很常见。无需将所有永久不可用的资源标记为“已消失”，也无需将标记保留任何时间长度——这由服务器所有者自行决定。
The precondition given in one or more of the 'if-' request-header fields evaluated to false when it was tested on the agent. See these sections for the 'if-' headers: If-Match Section 18.24, If-Modified-Since Section 18.25, and If-None-Match Section 18.26. This response code allows the agent to place preconditions on the current resource meta-information (header field data) and, thus, prevent the requested method from being applied to a resource other than the one intended.
在代理上测试时，一个或多个“if-”请求标头字段中给定的前提条件被评估为false。有关“如果-”标题，请参见这些章节：如果与第18.24节匹配，如果自第18.25节以来进行了修改，如果没有与第18.26节匹配。此响应代码允许代理对当前资源元信息（头字段数据）设置前提条件，从而防止请求的方法应用于预期资源以外的资源。
The agent is refusing to process a request because the request message body is larger than the agent is willing or able to process. The agent MAY close the connection to prevent the requesting agent from continuing the request.
代理拒绝处理请求，因为请求消息正文比代理愿意或能够处理的要大。代理可以关闭连接以阻止请求代理继续请求。
If the condition is temporary, the agent SHOULD include a Retry-After header field to indicate that it is temporary and after what time the requesting agent MAY try again.
如果该条件是临时的，则代理应包括一个Retry After标头字段，以指示该条件是临时的，并且在请求代理可以重试的时间之后。
The responding agent is refusing to service the request because the Request-URI is longer than the agent is willing to interpret. This rare condition is only likely to occur when an agent has used a request with long query information, when the agent has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the agent is under attack
响应代理拒绝为请求提供服务，因为请求URI比代理愿意解释的长度长。只有当代理使用具有长查询信息的请求时，当代理陷入重定向的URI“黑洞”（例如，指向自身后缀的重定向URI前缀）时，或者当代理受到攻击时，才会出现这种罕见的情况
by an agent attempting to exploit security holes present in some agents using fixed-length buffers for reading or manipulating the Request-URI.
代理试图利用某些代理中存在的安全漏洞，使用固定长度的缓冲区读取或操作请求URI。
The server is refusing to service the request because the message body of the request is in a format not supported by the requested resource for the requested method.
服务器拒绝为请求提供服务，因为请求的消息体的格式不受请求方法的请求资源支持。
The recipient of the request does not support one or more parameters contained in the request. When returning this error message the agent SHOULD return a message body containing the offending parameter(s).
请求的收件人不支持请求中包含的一个或多个参数。返回此错误消息时，代理应返回包含有问题参数的消息正文。
This status code MUST NOT be used in RTSP 2.0. However, it was allowed in RTSP 1.0 [RFC2326].
RTSP 2.0中不得使用此状态代码。但是，RTSP 1.0[RFC2326]中允许使用此选项。
The request was refused because there was insufficient bandwidth. This may, for example, be the result of a resource reservation failure.
由于带宽不足，请求被拒绝。例如，这可能是资源保留失败的结果。
The RTSP session identifier in the Session header is missing, is invalid, or has timed out.
会话头中的RTSP会话标识符丢失、无效或已超时。
The agent cannot process this request in its current state. The response MUST contain an Allow header to make error recovery possible.
代理无法在其当前状态下处理此请求。响应必须包含允许标头，以使错误恢复成为可能。
The targeted agent could not act on a required request-header. For example, if PLAY request contains the Range header field but the stream does not allow seeking. This error message may also be used for specifying when the time format in Range is impossible for the resource. In that case, the Accept-Ranges header MUST be returned to inform the agent of which formats are allowed.
目标代理无法对所需的请求标头执行操作。例如，如果播放请求包含范围标头字段，但流不允许搜索。此错误消息还可用于指定资源何时无法使用范围内的时间格式。在这种情况下，必须返回Accept Ranges标头以通知代理允许哪些格式。
The Range value given is out of bounds, e.g., beyond the end of the presentation.
给定的范围值超出范围，例如，超出演示文稿的结尾。
The parameter to be set by SET_PARAMETER can be read but not modified. When returning this error message, the sender SHOULD return a message body containing the offending parameter(s).
set_参数设置的参数可以读取，但不能修改。返回此错误消息时，发件人应返回包含有问题参数的消息正文。
The requested method may not be applied on the URI in question since it is an aggregate (presentation) URI. The method may be applied on a media URI.
请求的方法可能不会应用于所讨论的URI，因为它是聚合（表示）URI。该方法可应用于媒体URI。
The requested method may not be applied on the URI in question since it is not an aggregate control (presentation) URI. The method may be applied on the aggregate control URI.
请求的方法可能不会应用于所讨论的URI，因为它不是聚合控件（表示）URI。该方法可应用于聚合控件URI。
The Transport field did not contain a supported transport specification.
传输字段不包含受支持的传输规范。
The data transmission channel could not be established because the agent address could not be reached. This error will most likely be the result of an agent attempt to place an invalid dest_addr parameter in the Transport field.
无法建立数据传输通道，因为无法访问代理地址。此错误很可能是代理试图在传输字段中放置无效的dest_addr参数的结果。
The data transmission channel was not established because the server prohibited access to the agent address. This error is most likely the result of an agent attempt to redirect media traffic to another destination with a dest_addr parameter in the Transport header.
未建立数据传输通道，因为服务器禁止访问代理地址。此错误很可能是由于代理试图使用传输标头中的dest_addr参数将媒体流量重定向到另一个目标而导致的。
The data transmission channel to the media destination is not yet ready for carrying data. However, the responding agent still expects that the data transmission channel will be established at some point in time. Note, however, that this may result in a permanent failure like 462 (Destination Unreachable).
到媒体目的地的数据传输信道尚未准备好承载数据。然而，响应代理仍然期望在某个时间点建立数据传输信道。然而，请注意，这可能会导致永久性故障，如462（无法到达目的地）。
An example of when this error may occur is in the case in which a client sends a PLAY request to a server prior to ensuring that the TCP connections negotiated for carrying media data were successfully established (in violation of this specification). The server would use this error code to indicate that the requested action could not be performed due to the failure of completing the connection establishment.
发生此错误的一个例子是，客户机在确保为传输媒体数据而协商的TCP连接成功建立之前（违反本规范），向服务器发送播放请求。服务器将使用此错误代码指示由于无法完成连接建立而无法执行请求的操作。
This indicates that the client has received a PLAY_NOTIFY (Section 13.5) with a Notify-Reason header (Section 18.32) unknown to the client.
这表示客户已收到一个播放通知（第13.5节），其通知原因标题（第18.32节）客户不知道。
This indicates that there has been an error in a Key Management function used in conjunction with a request. For example, usage of Multimedia Internet KEYing (MIKEY) [RFC3830] according to Appendix C.1.4.1 may result in this error.
这表示与请求一起使用的密钥管理功能中存在错误。例如，根据附录C.1.4.1使用多媒体互联网键控（MIKEY）[RFC3830]可能会导致此错误。
The secured connection attempt needs user or client authorization before proceeding. The next hop's certificate is included in this response in the Accept-Credentials header.
安全连接尝试需要用户或客户端授权才能继续。下一个跃点的证书包含在此响应中的Accept Credentials标头中。
When performing a secure connection over multiple connections, an intermediary has refused to connect to the next hop and carry out the request due to unacceptable credentials for the used policy.
在通过多个连接执行安全连接时，由于所用策略的凭据不可接受，中介已拒绝连接到下一个跃点并执行请求。
A proxy fails to establish a secure connection to the next-hop RTSP agent. This is primarily caused by a fatal failure at the TLS handshake, for example, due to the agent not accepting any cipher suites.
代理无法建立到下一跳RTSP代理的安全连接。这主要是由TLS握手时的致命故障造成的，例如，由于代理不接受任何密码套件。
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. The server SHOULD include a message body containing an explanation of the error situation and whether it is a temporary or permanent condition. User agents SHOULD display any included message body to the user. These response codes are applicable to any request method.
以数字“5”开头的响应状态代码表示服务器意识到出错或无法执行请求的情况。服务器应该包含一个消息体，其中包含对错误情况的解释，以及错误是暂时的还是永久的。用户代理应向用户显示任何包含的消息正文。这些响应代码适用于任何请求方法。
The agent encountered an unexpected condition that prevented it from fulfilling the request.
代理遇到意外情况，无法满足请求。
The agent does not support the functionality required to fulfill the request. This is the appropriate response when the agent does not recognize the request method and is not capable of supporting it for any resource.
代理不支持满足请求所需的功能。当代理无法识别请求方法并且无法为任何资源支持该方法时，这是适当的响应。
The agent, while acting as a gateway or proxy, received an invalid response from the upstream agent it accessed in attempting to fulfill the request.
代理在充当网关或代理时，从试图完成请求时访问的上游代理接收到无效响应。
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition that will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the agent SHOULD handle the response as it would for a 500 response. The agent MUST honor the length, if given, in the Retry-After header.
由于服务器临时过载或维护，服务器当前无法处理请求。其含义是，这是一种暂时的情况，经过一段时间的延迟后将得到缓解。如果已知，延迟的长度可以在Retry After标头中指示。如果没有在之后重试，代理应该像处理500响应一样处理响应。代理必须遵守Retry After标头中的长度（如果给定）。
Note: The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish to simply refuse the transport connection.
注意：503状态代码的存在并不意味着服务器在过载时必须使用它。有些服务器可能希望简单地拒绝传输连接。
The response scope is dependent on the request. If the request was in relation to an existing RTSP session, the scope of the overload response is to this individual RTSP session. If the request was not session specific or intended to form an RTSP session, it applies to the RTSP server identified by the hostname in the Request-URI.
响应范围取决于请求。如果请求与现有RTSP会话相关，则重载响应的范围是此单个RTSP会话。如果请求不是特定于会话的，或者不打算形成RTSP会话，那么它将应用于由请求URI中的主机名标识的RTSP服务器。
The agent, while acting as a proxy, did not receive a timely response from the upstream agent specified by the URI or some other auxiliary server (e.g., DNS) that it needed to access in attempting to complete the request.
代理在充当代理时，没有从URI指定的上游代理或它在尝试完成请求时需要访问的某些其他辅助服务器（例如DNS）收到及时响应。
The agent does not support, or refuses to support, the RTSP version that was used in the request message. The agent is indicating that it is unable or unwilling to complete the request using the same major version as the agent other than with this error message. The response SHOULD contain a message body describing why that version is not supported and what other protocols are supported by that agent.
代理不支持或拒绝支持请求消息中使用的RTSP版本。代理表示它无法或不愿意使用与代理相同的主版本完成请求，除了此错误消息。响应应该包含一个消息体，描述为什么不支持该版本以及该代理支持哪些其他协议。
A feature tag given in the Require or the Proxy-Require fields was not supported. The Unsupported header MUST be returned stating the feature for which there is no support.
不支持Require或Proxy Require字段中给定的功能标记。必须返回不支持的标题，说明不支持的功能。
The proxy is currently unable to handle the request due to a temporary overloading or maintenance of the proxy. The implication is that this is a temporary condition that will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the agent SHOULD handle the response as it would for a 500 response. The agent MUST honor the length, if given in the Retry-After header.
由于代理临时超载或维护，代理当前无法处理请求。其含义是，这是一种暂时的情况，经过一段时间的延迟后将得到缓解。如果已知，延迟的长度可以在Retry After标头中指示。如果没有在之后重试，代理应该像处理500响应一样处理响应。如果在Retry After标头中给出，则代理必须遵守长度。
Note: The existence of the 553 status code does not imply that a proxy must use it when becoming overloaded. Some proxies may wish to simply refuse the connection.
注意：553状态代码的存在并不意味着代理在过载时必须使用它。一些代理可能希望简单地拒绝连接。
The response scope is dependent on the Request. If the request was in relation to an existing RTSP session, the scope of the overload response is to this individual RTSP session. If the request was non-session specific or intended to form an RTSP session, it applies to all such requests to this proxy.
响应范围取决于请求。如果请求与现有RTSP会话相关，则重载响应的范围是此单个RTSP会话。如果请求是非会话特定的或旨在形成RTSP会话，则该请求适用于此代理的所有此类请求。
+---------------+----------------+--------+---------+------+
| method | direction | object | acronym | Body |
+---------------+----------------+--------+---------+------+
| DESCRIBE | C -> S | P,S | DES | r |
| | | | | |
| GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r |
| | | | | |
| OPTIONS | C -> S, S -> C | P,S | OPT | |
| | | | | |
| PAUSE | C -> S | P,S | PSE | |
| | | | | |
| PLAY | C -> S | P,S | PLY | |
| | | | | |
| PLAY_NOTIFY | S -> C | P,S | PNY | R |
| | | | | |
| REDIRECT | S -> C | P,S | RDR | |
| | | | | |
| SETUP | C -> S | S | STP | |
| | | | | |
| SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r |
| | | | | |
| TEARDOWN | C -> S | P,S | TRD | |
| | | | | |
| | S -> C | P | TRD | |
+---------------+----------------+--------+---------+------+
+---------------+----------------+--------+---------+------+
| method | direction | object | acronym | Body |
+---------------+----------------+--------+---------+------+
| DESCRIBE | C -> S | P,S | DES | r |
| | | | | |
| GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r |
| | | | | |
| OPTIONS | C -> S, S -> C | P,S | OPT | |
| | | | | |
| PAUSE | C -> S | P,S | PSE | |
| | | | | |
| PLAY | C -> S | P,S | PLY | |
| | | | | |
| PLAY_NOTIFY | S -> C | P,S | PNY | R |
| | | | | |
| REDIRECT | S -> C | P,S | RDR | |
| | | | | |
| SETUP | C -> S | S | STP | |
| | | | | |
| SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r |
| | | | | |
| TEARDOWN | C -> S | P,S | TRD | |
| | | | | |
| | S -> C | P | TRD | |
+---------------+----------------+--------+---------+------+
This table is an overview of RTSP methods, their direction, and what objects (P: presentation, S: stream) they operate on. "Body" denotes if a method is allowed to carry body and in which direction; R = request, r=response. Note: All error messages for statuses 4xx and 5xx are allowed to carry a body.
此表概述了RTSP方法、它们的方向以及它们操作的对象（P:presentation、S:stream）。“主体”表示是否允许一种方法承载主体以及承载主体的方向；R=请求，R=响应。注意：4xx和5xx状态的所有错误消息都允许携带正文。
Table 8: Overview of RTSP Methods
表8：RTSP方法概述
The general syntax for header fields is covered in Section 5.2. This section lists the full set of header fields along with notes on meaning and usage. The syntax definitions for header fields are present in Section 20.2.3. Examples of each header field are given.
标题字段的一般语法见第5.2节。本节列出了完整的标题字段集以及有关含义和用法的注释。标题字段的语法定义见第20.2.3节。给出了每个标题字段的示例。
Information about header fields in relation to methods and proxy processing is summarized in Figures 2, 3, 4, and 5.
图2、3、4和5总结了与方法和代理处理相关的头字段信息。
The "where" column describes the request and response types in which the header field can be used. Values in this column are:
“where”列描述了可以使用header字段的请求和响应类型。此列中的值为：
R: header field may only appear in requests;
R：标题字段只能出现在请求中；
r: header field may only appear in responses;
r：标题字段只能出现在响应中；
2xx, 4xx, etc.: numerical value or range indicates response codes with which the header field can be used;
2xx、4xx等：数值或范围表示可以使用表头字段的响应代码；
c: header field is copied from the request to the response.
c：头字段从请求复制到响应。
G: header field is a general-header and may be present in both requests and responses.
G:header字段是一个通用的头，可以出现在请求和响应中。
Note: General headers do not always use the "G" value in the "where" column. This is due to differences when the header may be applied in requests compared to responses. When such differences exist, they are expressed using two different rows: one with "where" being "R" and one with it being "r".
注意：常规标题并不总是在“where”列中使用“G”值。这是由于与响应相比，在请求中应用报头时存在差异。当这些差异存在时，它们使用两个不同的行来表示：一个“where”表示为“R”，另一个表示为“R”。
The "proxy" column describes the operations a proxy may perform on a header field. An empty proxy column indicates that the proxy MUST NOT make any changes to that header, all allowed operations are explicitly stated:
“代理”列描述代理可以对标题字段执行的操作。空代理列表示代理不得对该标头进行任何更改，所有允许的操作均明确说明：
a: A proxy can add or concatenate the header field if not present.
答：代理可以添加或连接标题字段（如果不存在）。
m: A proxy can modify an existing header field value.
m：代理可以修改现有的头字段值。
d: A proxy can delete a header field-value.
d：代理可以删除标题字段值。
r: A proxy needs to be able to read the header field; thus, this header field cannot be encrypted.
r：代理需要能够读取头字段；因此，此标头字段无法加密。
The rest of the columns relate to the presence of a header field in a method. The method names when abbreviated, are according to Table 8:
其余的列与方法中是否存在标头字段有关。缩写后的方法名称如表8所示：
c: Conditional; requirements on the header field depend on the context of the message.
c：有条件的；标题字段的要求取决于消息的上下文。
m: The header field is mandatory.
m：标题字段是必需的。
m*: The header field SHOULD be sent, but agents need to be prepared to receive messages without that header field.
m*：应该发送头字段，但代理需要准备接收没有该头字段的消息。
o: The header field is optional.
o：标题字段是可选的。
*: The header field MUST be present if the message body is not empty. See Sections 18.17, 18.19 and 5.3 for details.
*：如果消息正文不是空的，则标题字段必须存在。详见第18.17、18.19和5.3节。
-: The header field is not applicable.
-：标题字段不适用。
"Optional" means that an agent MAY include the header field in a request or response. The agent behavior when receiving such headers varies; for some, it may ignore the header field. In other cases, it is a request to process the header. This is regulated by the method and header descriptions. Examples of headers that require processing are the Require and Proxy-Require header fields discussed in Sections 18.43 and 18.37. A "mandatory" header field MUST be present in a request, and it MUST be understood by the agent receiving the request. A mandatory response-header field MUST be present in the response, and the header field MUST be understood by the processing the response. "Not applicable" means that the header field MUST NOT be present in a request. If one is placed in a request by mistake, it MUST be ignored by the agent receiving the request. Similarly, a header field labeled "not applicable" for a response means that the agent MUST NOT place the header field in the response, and the agent MUST ignore the header field in the response.
“可选”意味着代理可以在请求或响应中包含头字段。当接收到这样的报头时，代理的行为会发生变化；对于某些情况，它可能会忽略标题字段。在其他情况下，它是处理标头的请求。这是由方法和标题描述规定的。需要处理的报头示例包括第18.43节和第18.37节中讨论的require和Proxy require报头字段。请求中必须存在一个“强制”标题字段，并且接收请求的代理必须理解该字段。响应中必须存在一个强制响应头字段，并且处理响应时必须理解该头字段。“不适用”表示请求中不得存在标题字段。如果一个错误地放入请求中，则接收请求的代理必须忽略它。类似地，响应的标题字段标记为“不适用”，这意味着代理不能在响应中放置标题字段，并且代理必须忽略响应中的标题字段。
An RTSP agent MUST ignore extension headers that are not understood.
RTSP代理必须忽略无法理解的扩展标头。
The From and Location header fields contain a URI. If the URI contains a comma (') or semicolon (;), the URI MUST be enclosed in double quotes ("). Any URI parameters are contained within these quotes. If the URI is not enclosed in double quotes, any semicolon-delimited parameters are header-parameters, not URI parameters.
“发件人”和“位置”标题字段包含URI。如果URI包含逗号（'）或分号（；），则URI必须用双引号（“）括起来。任何URI参数都包含在这些引号内。如果URI未用双引号括起来，则任何分号分隔的参数都是标头参数，而不是URI参数。
+-------------------+------+------+----+----+-----+-----+-----+-----+
| Header |Where |Proxy |DES | OPT| STP | PLY | PSE | TRD |
+-------------------+------+------+----+----+-----+-----+-----+-----+
| Accept | R | | o | - | - | - | - | - |
| Accept- | R | rm | o | o | o | o | o | o |
| Credentials | | | | | | | | |
| Accept-Encoding | R | r | o | - | - | - | - | - |
| Accept-Language | R | r | o | - | - | - | - | - |
| Accept-Ranges | G | r | - | - | m | - | - | - |
| Accept-Ranges | 456 | r | - | - | - | m | - | - |
| Allow | r | am | c | c | c | - | - | - |
| Allow | 405 | am | m | m | m | m | m | m |
| Authentication- | r | | o | o | o | o | o | o/- |
| Info | | | | | | | | |
| Authorization | R | | o | o | o | o | o | o/- |
| Bandwidth | R | | o | o | o | o | - | - |
| Blocksize | R | | o | - | o | o | - | - |
| Cache-Control | G | r | o | - | o | - | - | - |
| Connection | G | ad | o | o | o | o | o | o |
| Connection- | 470, | ar | o | o | o | o | o | o |
| Credentials | 407 | | | | | | | |
| Content-Base | r | | o | - | - | - | - | - |
| Content-Base | 4xx, | | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Encoding | R | r | - | - | - | - | - | - |
| Content-Encoding | r | r | o | - | - | - | - | - |
| Content-Encoding | 4xx, | r | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Language | R | r | - | - | - | - | - | - |
| Content-Language | r | r | o | - | - | - | - | - |
| Content-Language | 4xx, | r | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Length | r | r | * | - | - | - | - | - |
| Content-Length | 4xx, | r | * | * | * | * | * | * |
| | 5xx | | | | | | | |
| Content-Location | r | r | o | - | - | - | - | - |
| Content-Location | 4xx, | r | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Type | r | r | * | - | - | - | - | - |
| Content-Type | 4xx, | ar | * | * | * | * | * | * |
| | 5xx | | | | | | | |
| CSeq | Gc | rm | m | m | m | m | m | m |
| Date | G | am | o/*| o/*| o/* | o/* | o/* | o/* |
| Expires | r | r | o | - | o | - | - | - |
| From | R | r | o | o | o | o | o | o |
| If-Match | R | r | - | - | o | - | - | - |
| If-Modified-Since | R | r | o | - | o | - | - | - |
| If-None-Match | R | r | o | - | o | - | - | - |
+-------------------+------+------+----+----+-----+-----+-----+-----+
| Header |Where |Proxy |DES | OPT| STP | PLY | PSE | TRD |
+-------------------+------+------+----+----+-----+-----+-----+-----+
| Accept | R | | o | - | - | - | - | - |
| Accept- | R | rm | o | o | o | o | o | o |
| Credentials | | | | | | | | |
| Accept-Encoding | R | r | o | - | - | - | - | - |
| Accept-Language | R | r | o | - | - | - | - | - |
| Accept-Ranges | G | r | - | - | m | - | - | - |
| Accept-Ranges | 456 | r | - | - | - | m | - | - |
| Allow | r | am | c | c | c | - | - | - |
| Allow | 405 | am | m | m | m | m | m | m |
| Authentication- | r | | o | o | o | o | o | o/- |
| Info | | | | | | | | |
| Authorization | R | | o | o | o | o | o | o/- |
| Bandwidth | R | | o | o | o | o | - | - |
| Blocksize | R | | o | - | o | o | - | - |
| Cache-Control | G | r | o | - | o | - | - | - |
| Connection | G | ad | o | o | o | o | o | o |
| Connection- | 470, | ar | o | o | o | o | o | o |
| Credentials | 407 | | | | | | | |
| Content-Base | r | | o | - | - | - | - | - |
| Content-Base | 4xx, | | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Encoding | R | r | - | - | - | - | - | - |
| Content-Encoding | r | r | o | - | - | - | - | - |
| Content-Encoding | 4xx, | r | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Language | R | r | - | - | - | - | - | - |
| Content-Language | r | r | o | - | - | - | - | - |
| Content-Language | 4xx, | r | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Length | r | r | * | - | - | - | - | - |
| Content-Length | 4xx, | r | * | * | * | * | * | * |
| | 5xx | | | | | | | |
| Content-Location | r | r | o | - | - | - | - | - |
| Content-Location | 4xx, | r | o | o | o | o | o | o |
| | 5xx | | | | | | | |
| Content-Type | r | r | * | - | - | - | - | - |
| Content-Type | 4xx, | ar | * | * | * | * | * | * |
| | 5xx | | | | | | | |
| CSeq | Gc | rm | m | m | m | m | m | m |
| Date | G | am | o/*| o/*| o/* | o/* | o/* | o/* |
| Expires | r | r | o | - | o | - | - | - |
| From | R | r | o | o | o | o | o | o |
| If-Match | R | r | - | - | o | - | - | - |
| If-Modified-Since | R | r | o | - | o | - | - | - |
| If-None-Match | R | r | o | - | o | - | - | - |
| Last-Modified | r | r | o | - | o | - | - | - |
| Location | 3rr | | m | m | m | m | m | m |
+-------------------+------+------+----+----+-----+-----+-----+-----+
| Header |Where |Proxy |DES | OPT| STP | PLY | PSE | TRD |
+-------------------+------+------+----+----+-----+-----+-----+-----+
| Last-Modified | r | r | o | - | o | - | - | - |
| Location | 3rr | | m | m | m | m | m | m |
+-------------------+------+------+----+----+-----+-----+-----+-----+
| Header |Where |Proxy |DES | OPT| STP | PLY | PSE | TRD |
+-------------------+------+------+----+----+-----+-----+-----+-----+
Figure 2: Overview of RTSP Header Fields (A-L) Related to Methods DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN
图2：与方法描述、选项、设置、播放、暂停和拆卸相关的RTSP头字段（A-L）概述
+------------------+---------+-----+----+----+----+-----+-----+-----+
| Header | Where |Proxy|DES |OPT |STP | PLY | PSE | TRD |
+------------------+---------+-----+----+----+----+-----+-----+-----+
| Media-Properties | r | | - | - | m | o | o | - |
| Media-Range | r | | - | - | c | c | c | - |
| MTag | r | r | o | - | o | - | - | - |
| Pipelined- | G | amd | - | o | o | o | o | o |
| Requests | | r | | | | | | |
| Proxy- | 407 | amr | m | m | m | m | m | m |
| Authenticate | | | | | | | | |
| Proxy- | r | amd | o | o | o | o | o | o/- |
| Authentication- | | r | | | | | | |
| Info | | | | | | | | |
| Proxy- | R | rd | o | o | o | o | o | o |
| Authorization | | | | | | | | |
| Proxy-Require | R | ar | o | o | o | o | o | o |
| Proxy-Require | r | r | c | c | c | c | c | c |
| Proxy-Supported | R | amr | c | c | c | c | c | c |
| Proxy-Supported | r | | c | c | c | c | c | c |
| Public | r | amr | - | m | - | - | - | - |
| Public | 501 | amr | m | m | m | m | m | m |
| Range | R | | - | - | - | o | - | - |
| Range | r | | - | - | c | m | m | - |
| Referrer | R | | o | o | o | o | o | o |
| Request-Status | R | | - | - | - | - | - | - |
| Require | R | | o | o | o | o | o | o |
| Retry-After | 3rr,503 | | o | o | o | o | o | - |
| | ,553 | | | | | | | |
| Retry-After | 413 | | o | - | - | - | - | - |
| RTP-Info | r | | - | - | c | c | - | - |
| Scale | R | r | - | - | - | o | - | - |
| Scale | r | amr | - | - | c | c | c | - |
| Seek-Style | R | | - | - | - | o | - | - |
| Seek-Style | r | | - | - | - | m | - | - |
| Server | R | r | - | o | - | - | - | o |
| Server | r | r | o | o | o | o | o | o |
| Session | R | r | - | o | o | m | m | m |
| Session | r | r | - | c | m | m | m | o |
| Speed | R | admr| - | - | - | o | - | - |
| Speed | r | admr| - | - | - | c | - | - |
| Supported | R | r | o | o | o | o | o | o |
| Supported | r | r | c | c | c | c | c | c |
| Terminate-Reason | R | r | - | - | - | - | - | -/o |
| Timestamp | R | admr| o | o | o | o | o | o |
| Timestamp | c | admr| m | m | m | m | m | m |
| Transport | G | mr | - | - | m | - | - | - |
| Unsupported | r | | c | c | c | c | c | c |
| User-Agent | R | | m* | m* | m* | m* | m* | m* |
+------------------+---------+-----+----+----+----+-----+-----+-----+
| Header | Where |Proxy|DES |OPT |STP | PLY | PSE | TRD |
+------------------+---------+-----+----+----+----+-----+-----+-----+
| Media-Properties | r | | - | - | m | o | o | - |
| Media-Range | r | | - | - | c | c | c | - |
| MTag | r | r | o | - | o | - | - | - |
| Pipelined- | G | amd | - | o | o | o | o | o |
| Requests | | r | | | | | | |
| Proxy- | 407 | amr | m | m | m | m | m | m |
| Authenticate | | | | | | | | |
| Proxy- | r | amd | o | o | o | o | o | o/- |
| Authentication- | | r | | | | | | |
| Info | | | | | | | | |
| Proxy- | R | rd | o | o | o | o | o | o |
| Authorization | | | | | | | | |
| Proxy-Require | R | ar | o | o | o | o | o | o |
| Proxy-Require | r | r | c | c | c | c | c | c |
| Proxy-Supported | R | amr | c | c | c | c | c | c |
| Proxy-Supported | r | | c | c | c | c | c | c |
| Public | r | amr | - | m | - | - | - | - |
| Public | 501 | amr | m | m | m | m | m | m |
| Range | R | | - | - | - | o | - | - |
| Range | r | | - | - | c | m | m | - |
| Referrer | R | | o | o | o | o | o | o |
| Request-Status | R | | - | - | - | - | - | - |
| Require | R | | o | o | o | o | o | o |
| Retry-After | 3rr,503 | | o | o | o | o | o | - |
| | ,553 | | | | | | | |
| Retry-After | 413 | | o | - | - | - | - | - |
| RTP-Info | r | | - | - | c | c | - | - |
| Scale | R | r | - | - | - | o | - | - |
| Scale | r | amr | - | - | c | c | c | - |
| Seek-Style | R | | - | - | - | o | - | - |
| Seek-Style | r | | - | - | - | m | - | - |
| Server | R | r | - | o | - | - | - | o |
| Server | r | r | o | o | o | o | o | o |
| Session | R | r | - | o | o | m | m | m |
| Session | r | r | - | c | m | m | m | o |
| Speed | R | admr| - | - | - | o | - | - |
| Speed | r | admr| - | - | - | c | - | - |
| Supported | R | r | o | o | o | o | o | o |
| Supported | r | r | c | c | c | c | c | c |
| Terminate-Reason | R | r | - | - | - | - | - | -/o |
| Timestamp | R | admr| o | o | o | o | o | o |
| Timestamp | c | admr| m | m | m | m | m | m |
| Transport | G | mr | - | - | m | - | - | - |
| Unsupported | r | | c | c | c | c | c | c |
| User-Agent | R | | m* | m* | m* | m* | m* | m* |
| Via | R | amr | c | c | c | c | c | c |
| Via | r | amr | c | c | c | c | c | c |
| WWW-Authenticate | 401 | | m | m | m | m | m | m |
+------------------+---------+-----+----+----+----+-----+-----+-----+
| Header | Where |Proxy|DES |OPT |STP | PLY | PSE | TRD |
+------------------+---------+-----+----+----+----+-----+-----+-----+
| Via | R | amr | c | c | c | c | c | c |
| Via | r | amr | c | c | c | c | c | c |
| WWW-Authenticate | 401 | | m | m | m | m | m | m |
+------------------+---------+-----+----+----+----+-----+-----+-----+
| Header | Where |Proxy|DES |OPT |STP | PLY | PSE | TRD |
+------------------+---------+-----+----+----+----+-----+-----+-----+
Figure 3: Overview of RTSP Header Fields (M-W) Related to Methods DESCRIBE, OPTIONS, SETUP, PLAY, PAUSE, and TEARDOWN
图3：与方法描述、选项、设置、播放、暂停和拆卸相关的RTSP头字段（M-W）概述
+---------------------------+-------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY |
+---------------------------+-------+-------+-----+-----+-----+-----+
| Accept-Credentials | R | rm | o | o | o | - |
| Accept-Encoding | R | r | o | o | o | - |
| Accept-Language | R | r | o | o | o | - |
| Accept-Ranges | G | rm | o | - | - | - |
| Allow | 405 | amr | m | m | m | m |
| Authentication-Info | r | | o/- | o/- | - | - |
| Authorization | R | | o | o | o | - |
| Bandwidth | R | | - | o | - | - |
| Blocksize | R | | - | o | - | - |
| Cache-Control | G | r | o | o | - | - |
| Connection | G | | o | o | o | o |
| Connection-Credentials | 470, | ar | o | o | o | - |
| | 407 | | | | | |
| Content-Base | R | | o | o | - | o |
| Content-Base | r | | o | o | - | - |
| Content-Base | 4xx, | | o | o | o | o |
| | 5xx | | | | | |
| Content-Encoding | R | r | o | o | - | o |
| Content-Encoding | r | r | o | o | - | - |
| Content-Encoding | 4xx, | r | o | o | o | o |
| | 5xx | | | | | |
| Content-Language | R | r | o | o | - | o |
| Content-Language | r | r | o | o | - | - |
| Content-Language | 4xx, | r | o | o | o | o |
| | 5xx | | | | | |
| Content-Length | R | r | * | * | - | * |
| Content-Length | r | r | * | * | - | - |
| Content-Length | 4xx, | r | * | * | * | * |
| | 5xx | | | | | |
| Content-Location | R | | o | o | - | o |
| Content-Location | r | | o | o | - | - |
| Content-Location | 4xx, | | o | o | o | o |
| | 5xx | | | | | |
| Content-Type | R | | * | * | - | * |
| Content-Type | r | | * | * | - | - |
| Content-Type | 4xx, | | * | * | * | * |
| | 5xx | | | | | |
| CSeq | R,c | mr | m | m | m | m |
| Date | R | a | o/* | o/* | m | o/* |
| Date | r | am | o/* | o/* | o/* | o/* |
| Expires | r | r | - | - | - | - |
| From | R | r | o | o | o | - |
| If-Match | R | r | - | - | - | - |
| If-Modified-Since | R | am | o | - | - | - |
| If-None-Match | R | am | o | - | - | - |
+---------------------------+-------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY |
+---------------------------+-------+-------+-----+-----+-----+-----+
| Accept-Credentials | R | rm | o | o | o | - |
| Accept-Encoding | R | r | o | o | o | - |
| Accept-Language | R | r | o | o | o | - |
| Accept-Ranges | G | rm | o | - | - | - |
| Allow | 405 | amr | m | m | m | m |
| Authentication-Info | r | | o/- | o/- | - | - |
| Authorization | R | | o | o | o | - |
| Bandwidth | R | | - | o | - | - |
| Blocksize | R | | - | o | - | - |
| Cache-Control | G | r | o | o | - | - |
| Connection | G | | o | o | o | o |
| Connection-Credentials | 470, | ar | o | o | o | - |
| | 407 | | | | | |
| Content-Base | R | | o | o | - | o |
| Content-Base | r | | o | o | - | - |
| Content-Base | 4xx, | | o | o | o | o |
| | 5xx | | | | | |
| Content-Encoding | R | r | o | o | - | o |
| Content-Encoding | r | r | o | o | - | - |
| Content-Encoding | 4xx, | r | o | o | o | o |
| | 5xx | | | | | |
| Content-Language | R | r | o | o | - | o |
| Content-Language | r | r | o | o | - | - |
| Content-Language | 4xx, | r | o | o | o | o |
| | 5xx | | | | | |
| Content-Length | R | r | * | * | - | * |
| Content-Length | r | r | * | * | - | - |
| Content-Length | 4xx, | r | * | * | * | * |
| | 5xx | | | | | |
| Content-Location | R | | o | o | - | o |
| Content-Location | r | | o | o | - | - |
| Content-Location | 4xx, | | o | o | o | o |
| | 5xx | | | | | |
| Content-Type | R | | * | * | - | * |
| Content-Type | r | | * | * | - | - |
| Content-Type | 4xx, | | * | * | * | * |
| | 5xx | | | | | |
| CSeq | R,c | mr | m | m | m | m |
| Date | R | a | o/* | o/* | m | o/* |
| Date | r | am | o/* | o/* | o/* | o/* |
| Expires | r | r | - | - | - | - |
| From | R | r | o | o | o | - |
| If-Match | R | r | - | - | - | - |
| If-Modified-Since | R | am | o | - | - | - |
| If-None-Match | R | am | o | - | - | - |
| Last-Modified | R | r | - | - | - | - |
| Last-Modified | r | r | o | - | - | - |
| Location | 3rr | | m | m | m | - |
| Location | R | | - | - | m | - |
+---------------------------+-------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY |
+---------------------------+-------+-------+-----+-----+-----+-----+
| Last-Modified | R | r | - | - | - | - |
| Last-Modified | r | r | o | - | - | - |
| Location | 3rr | | m | m | m | - |
| Location | R | | - | - | m | - |
+---------------------------+-------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY |
+---------------------------+-------+-------+-----+-----+-----+-----+
Figure 4: Overview of RTSP Header Fields (A-L) Related to Methods GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY
图4:GET_参数、SET_参数、REDIRECT和PLAY_NOTIFY方法相关的RTSP头字段（A-L）概述
+---------------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY |
+---------------------------+---------+-------+-----+-----+-----+-----+
| Media-Properties | R | amr | o | - | - | c |
| Media-Properties | r | mr | c | - | - | - |
| Media-Range | R | | o | - | - | c |
| Media-Range | r | | c | - | - | - |
| MTag | r | r | o | - | - | - |
| Notify-Reason | R | | - | - | - | m |
| Pipelined-Requests | R | amdr | o | o | - | - |
| Proxy-Authenticate | 407 | amdr | m | m | m | - |
| Proxy-Authentication-Info | r | amdr | o/- | o/- | - | - |
| Proxy-Authorization | R | amdr | o | o | o | - |
| Proxy-Require | R | ar | o | o | o | - |
| Proxy-Supported | R | amr | c | c | c | - |
| Proxy-Supported | r | | c | c | c | - |
| Public | 501 | admr | m | m | m | - |
| Range | R | | o | - | - | m |
| Range | r | | c | - | - | - |
| Referrer | R | | o | o | o | - |
| Request-Status | R | mr | - | - | - | c |
| Require | R | r | o | o | o | o |
| Retry-After | 3rr,503,| | o | o | - | - |
| | 553 | | | | | |
| Retry-After | 413 | | o | o | - | - |
| RTP-Info | R | r | o | - | - | C |
| RTP-Info | r | r | c | - | - | - |
| Scale | G | | c | - | c | c |
| Seek-Style | G | | - | - | - | - |
| Server | R | r | o | o | o | o |
| Server | r | r | o | o | - | - |
| Session | R | r | o | o | o | m |
| Session | r | r | c | c | o | m |
| Speed | G | | - | - | - | - |
| Supported | R | r | o | o | o | - |
| Supported | r | r | c | c | c | - |
| Terminate-Reason | R | r | - | - | m | - |
| Timestamp | R | adrm | o | o | o | o |
| Timestamp | c | adrm | m | m | m | m |
| Transport | G | mr | - | - | - | - |
| Unsupported | r | arm | c | c | c | c |
| User-Agent | R | r | m* | m* | - | - |
| User-Agent | r | r | m* | m* | m* | m* |
| Via | R | amr | c | c | c | c |
+---------------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY |
+---------------------------+---------+-------+-----+-----+-----+-----+
| Media-Properties | R | amr | o | - | - | c |
| Media-Properties | r | mr | c | - | - | - |
| Media-Range | R | | o | - | - | c |
| Media-Range | r | | c | - | - | - |
| MTag | r | r | o | - | - | - |
| Notify-Reason | R | | - | - | - | m |
| Pipelined-Requests | R | amdr | o | o | - | - |
| Proxy-Authenticate | 407 | amdr | m | m | m | - |
| Proxy-Authentication-Info | r | amdr | o/- | o/- | - | - |
| Proxy-Authorization | R | amdr | o | o | o | - |
| Proxy-Require | R | ar | o | o | o | - |
| Proxy-Supported | R | amr | c | c | c | - |
| Proxy-Supported | r | | c | c | c | - |
| Public | 501 | admr | m | m | m | - |
| Range | R | | o | - | - | m |
| Range | r | | c | - | - | - |
| Referrer | R | | o | o | o | - |
| Request-Status | R | mr | - | - | - | c |
| Require | R | r | o | o | o | o |
| Retry-After | 3rr,503,| | o | o | - | - |
| | 553 | | | | | |
| Retry-After | 413 | | o | o | - | - |
| RTP-Info | R | r | o | - | - | C |
| RTP-Info | r | r | c | - | - | - |
| Scale | G | | c | - | c | c |
| Seek-Style | G | | - | - | - | - |
| Server | R | r | o | o | o | o |
| Server | r | r | o | o | - | - |
| Session | R | r | o | o | o | m |
| Session | r | r | c | c | o | m |
| Speed | G | | - | - | - | - |
| Supported | R | r | o | o | o | - |
| Supported | r | r | c | c | c | - |
| Terminate-Reason | R | r | - | - | m | - |
| Timestamp | R | adrm | o | o | o | o |
| Timestamp | c | adrm | m | m | m | m |
| Transport | G | mr | - | - | - | - |
| Unsupported | r | arm | c | c | c | c |
| User-Agent | R | r | m* | m* | - | - |
| User-Agent | r | r | m* | m* | m* | m* |
| Via | R | amr | c | c | c | c |
| Via | r | amr | c | c | c | c |
| WWW-Authenticate | 401 | | m | m | m | - |
+---------------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY |
+---------------------------+---------+-------+-----+-----+-----+-----+
| Via | r | amr | c | c | c | c |
| WWW-Authenticate | 401 | | m | m | m | - |
+---------------------------+---------+-------+-----+-----+-----+-----+
| Header | Where | Proxy | GPR | SPR | RDR | PNY |
+---------------------------+---------+-------+-----+-----+-----+-----+
Figure 5: Overview of RTSP Header Fields (M-W) Related to Methods GET_PARAMETER, SET_PARAMETER, REDIRECT, and PLAY_NOTIFY
图5:GET_参数、SET_参数、REDIRECT和PLAY_NOTIFY方法相关的RTSP头字段（M-W）概述
The Accept request-header field can be used to specify certain presentation description and parameter media types [RFC6838] that are acceptable for the response to the DESCRIBE request.
Accept request header字段可用于指定特定的表示说明和参数媒体类型[RFC6838]，这些类型可用于对描述请求的响应。
See Section 20.2.3 for the syntax.
语法见第20.2.3节。
The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all subtypes of that type. The range MAY include media type parameters that are generally applicable to that range.
星号“*”字符用于将媒体类型分为不同的范围，“*/*”表示所有媒体类型，“type/*”表示该类型的所有子类型。该范围可包括通常适用于该范围的介质类型参数。
Each media type or range MAY be followed by one or more accept-params, beginning with the "q" parameter to indicate a relative quality factor. The first "q" parameter (if any) separates the media type or range's parameters from the accept-params. Quality factors allow the user or user agent to indicate the relative degree of preference for that media type, using the qvalue scale from 0 to 1 (Section 5.3.1 of [RFC7231]). The default value is q=1.
每种媒体类型或范围后面都可能有一个或多个accept参数，以“q”参数开头，表示相对质量因数。第一个“q”参数（如果有）将介质类型或范围的参数与接受参数分开。质量因素允许用户或用户代理使用0到1的qvalue量表（RFC7231第5.3.1节）指示该媒体类型的相对偏好程度。默认值为q=1。
Example of use:
使用示例：
Accept: application/example ;q=0.7, application/sdp
Accept: application/example ;q=0.7, application/sdp
Indicates that the requesting agent prefers the media type application/sdp through the default 1.0 rating but also accepts the application/example media type with a 0.7 quality rating.
指示请求代理通过默认的1.0评级更喜欢媒体类型application/sdp，但也接受质量评级为0.7的应用程序/示例媒体类型。
If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field is present, and if the server cannot send a response that is acceptable according to the combined Accept field-value, then the server SHOULD send a 406 (Not Acceptable) response.
如果不存在Accept标头字段，则假定客户端接受所有媒体类型。如果存在Accept标头字段，并且如果服务器无法发送根据组合Accept字段值可接受的响应，则服务器应发送406（不可接受）响应。
The Accept-Credentials header is a request-header used to indicate to any trusted intermediary how to handle further secured connections to proxies or servers. It MUST NOT be included in server-to-client requests. See Section 19 for the usage of this header
Accept Credentials标头是一个请求标头，用于向任何受信任的中介机构指示如何处理到代理或服务器的进一步安全连接。它不能包含在服务器到客户端的请求中。有关此标题的用法，请参见第19节
In a request, the header MUST contain the method (User, Proxy, or Any) for approving credentials selected by the requester. The method MUST 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 further hop. If the method is "User", the header contains zero or more of the credentials that the client accepts. The header may contain zero credentials in the first RTSP request to an RTSP server via a proxy when using the "User" method. This is because the client has not yet received any credentials to accept. Each credential MUST consist of one URI identifying the proxy or server, the hash algorithm identifier, and the hash over that agent's ASN.1 DER-encoded certificate [RFC5280] in Base64, according to Section 4 of [RFC4648] and where the padding bits are set to zero. All RTSP clients and proxies MUST implement the SHA-256 [FIPS180-4] algorithm for computation of the hash of the DER-encoded certificate. The SHA-256 algorithm is identified by the token "sha-256".
在请求中，标头必须包含用于批准请求者选择的凭据的方法（用户、代理或任何方法）。任何代理都不能更改该方法，除非该方法是“代理”，此时代理可以将其更改为“用户”，以担任用户批准每个进一步跃点的角色。如果方法为“User”，则标头包含客户端接受的零个或多个凭据。当使用“用户”方法时，头在通过代理向RTSP服务器发出的第一个RTSP请求中可能包含零凭据。这是因为客户端尚未收到任何要接受的凭据。根据[RFC4648]第4节，每个凭证必须包含一个URI，用于标识代理或服务器、哈希算法标识符以及Base64中该代理的ASN.1 DER编码证书[RFC5280]上的哈希，其中填充位设置为零。所有RTSP客户端和代理必须实现SHA-256[FIPS180-4]算法，以计算DER编码证书的哈希值。SHA-256算法由标记“SHA-256”标识。
The intention of allowing for other hash algorithms is to enable the future retirement of algorithms that are not implemented somewhere other than here. Thus, the definition of future algorithms for this purpose is intended to be extremely limited. A feature tag can be used to ensure that support for the replacement algorithm exists.
允许使用其他哈希算法的目的是为了使未在此处以外的其他地方实现的算法能够在将来退役。因此，用于此目的的未来算法的定义是非常有限的。可以使用功能标签来确保存在对替换算法的支持。
Example:
例子：
Accept-Credentials:User
"rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=,
"rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M=
Accept-Credentials:User
"rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=,
"rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M=
The Accept-Encoding request-header field is similar to Accept, but it restricts the content-codings (see Section 18.15), i.e., transformation codings of the message body, such as gzip compression, that are acceptable in the response.
Accept Encoding request header字段类似于Accept，但它限制了响应中可接受的内容编码（参见第18.15节），即消息体的转换编码，如gzip压缩。
A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules:
服务器根据接受编码字段，使用以下规则测试内容编码是否可接受：
1. If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it is accompanied by a qvalue of 0. (As defined in Section 5.3.1 of [RFC7231], a qvalue of 0 means "not acceptable.")
1. 如果内容编码是Accept Encoding（接受编码）字段中列出的内容编码之一，则它是可接受的，除非它附带Q值0。（如[RFC7231]第5.3.1节所定义，Q值为0表示“不可接受”。）
2. The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header field.
2. 接受编码字段中的特殊“*”符号与头字段中未明确列出的任何可用内容编码匹配。
3. If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.
3. 如果可接受多个内容编码，则首选具有最高非零Q值的可接受内容编码。
4. The "identity" content-coding is always acceptable, i.e., no transformation at all, unless specifically refused because the Accept-Encoding field includes "identity;q=0" or because the field includes "*;q=0" and does not explicitly include the "identity" content-coding. If the Accept-Encoding field-value is empty, then only the "identity" encoding is acceptable.
4. “身份”内容编码始终是可接受的，即根本不进行转换，除非因为接受编码字段包含“身份；q=0”或因为该字段包含“*；q=0”且未明确包含“身份”内容编码而被明确拒绝。如果接受编码字段值为空，则仅接受“标识”编码。
If an Accept-Encoding field is present in a request, and if the server cannot send a response that is acceptable according to the Accept-Encoding header, then the server SHOULD send an error response with the 406 (Not Acceptable) status code.
如果请求中存在接受编码字段，并且根据接受编码标头，服务器无法发送可接受的响应，则服务器应发送带有406（不可接受）状态代码的错误响应。
If no Accept-Encoding field is present in a request, the server MAY assume that the client will accept any content-coding. In this case, if "identity" is one of the available content-codings, then the server SHOULD use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the client.
如果请求中不存在接受编码字段，服务器可能会假定客户端将接受任何内容编码。在这种情况下，如果“标识”是可用的内容编码之一，那么服务器应该使用“标识”内容编码，除非它有其他信息表明不同的内容编码对客户端有意义。
The Accept-Language request-header field is similar to Accept, but restricts the set of natural languages that are preferred as a response to the request. Note that the language specified applies to the presentation description (response message body) and any reason phrases, but not the media content.
Accept Language request header字段类似于Accept，但限制了作为请求响应首选的自然语言集。请注意，指定的语言适用于演示文稿描述（响应消息正文）和任何原因短语，但不适用于媒体内容。
A language tag identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to other human beings. Computer languages are explicitly excluded. The syntax and registry of RTSP 2.0 language tags are the same as those defined by [RFC5646].
语言标签标识人类所说、所写或以其他方式传达的自然语言，用于向其他人类传达信息。计算机语言被明确排除在外。RTSP 2.0语言标记的语法和注册表与[RFC5646]定义的语法和注册表相同。
Each language-range MAY be given an associated quality value that represents an estimate of the user's preference for the languages specified by that range. The quality value defaults to "q=1". For example:
每个语言范围可被赋予相关联的质量值，该质量值表示用户对该范围指定的语言的偏好的估计。质量值默认为“q=1”。例如：
Accept-Language: da, en-gb;q=0.8, en;q=0.7
Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and other types of English." A language-range matches a language tag if it exactly equals the full tag or if it exactly equals a prefix of the tag, i.e., the primary-tag in the ABNF, such that the character following primary-tag is "-". The special range "*", if present in the Accept-Language field, matches every tag not matched by any other range present in the Accept-Language field.
意思是：“我更喜欢丹麦语，但会接受英式英语和其他类型的英语。”如果语言范围完全等于完整标记或完全等于标记的前缀（即ABNF中的主标记），则该语言范围与语言标记匹配，因此主标记后面的字符为“-”。特殊范围“*”如果存在于Accept Language字段中，则与Accept Language字段中任何其他范围都不匹配的每个标记相匹配。
Note: This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always true that if a user understands a language with a certain tag, then this user will also understand all languages with tags for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case.
注意：前缀匹配规则的这种使用并不意味着语言标记分配给语言的方式总是正确的，即如果用户理解具有特定标记的语言，那么该用户也将理解具有该标记作为前缀的标记的所有语言。在这种情况下，前缀规则只允许使用前缀标记。
In the process of selecting a language, each language tag is assigned a qualification factor, i.e., if a language being supported by the client is actually supported by the server and what "preference" level the language achieves. The quality value (q-value) of the longest language-range in the field that matches the language tag is assigned as the qualification factor for a particular language tag. If no language-range in the field matches the tag, the language qualification factor assigned is 0. If no Accept-Language header is present in the request, the server SHOULD assume that all languages are equally acceptable. If an Accept-Language header is present, then all languages that are assigned a qualification factor greater than 0 are acceptable.
在选择语言的过程中，为每个语言标记分配一个限定因子，即，如果客户端支持的语言实际上由服务器支持，以及该语言达到的“首选”级别。字段中与语言标记匹配的最长语言范围的质量值（q值）被指定为特定语言标记的限定因子。如果字段中没有与标记匹配的语言范围，则指定的语言限定因子为0。如果请求中不存在Accept Language标头，则服务器应假定所有语言都是同等可接受的。如果存在Accept Language标头，则分配的限定因子大于0的所有语言都是可接受的。
The Accept-Ranges general-header field allows indication of the format supported in the Range header. The client MUST include the header in SETUP requests to indicate which formats are acceptable when received in PLAY and PAUSE responses and REDIRECT requests. The server MUST include the header in SETUP responses and 456 (Header Field Not Valid for Resource) error responses to indicate the formats supported for the resource indicated by the Request-URI. The header MAY be included in GET_PARAMETER request and response pairs. The GET_PARAMETER request MUST contain a Session header to identify the
Accept Ranges general header字段允许指示范围标头中支持的格式。客户端必须在设置请求中包含标题，以指示在播放、暂停响应和重定向请求中接收时可接受的格式。服务器必须在设置响应和456（header字段对资源无效）错误响应中包含标头，以指示请求URI所指示的资源支持的格式。报头可以包含在GET_参数请求和响应对中。GET_参数请求必须包含一个会话头以标识
session context the request is related to. The requester and responder will indicate their capabilities regarding Range formats respectively.
与请求相关的会话上下文。请求者和响应者将分别说明其关于范围格式的能力。
Accept-Ranges: npt, smpte, clock
接受范围：npt、smpte、时钟
The syntax is defined in Section 20.2.3.
第20.2.3节对语法进行了定义。
The Allow message body header field lists the methods supported by the resource identified by the Request-URI. The purpose of this field is to inform the recipient of the complete set of valid methods associated with the resource. An Allow header field MUST be present in a 405 (Method Not Allowed) response. The Allow header MUST also be present in all OPTIONS responses where the content of the header will not include exactly the same methods as listed in the Public header.
Allow message body header字段列出由请求URI标识的资源支持的方法。此字段的目的是通知收件人与资源关联的一整套有效方法。405（方法不允许）响应中必须存在允许标头字段。Allow标头还必须出现在所有选项响应中，其中标头的内容不包括与Public标头中列出的方法完全相同的方法。
The Allow message body header MUST also be included in SETUP and DESCRIBE responses, if the methods allowed for the resource are different from the complete set of methods defined in this memo.
如果资源允许的方法不同于此备忘录中定义的完整方法集，则设置和描述响应中还必须包含允许消息正文标题。
Example of use:
使用示例：
Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE
允许：设置、播放、设置参数、描述
The Authentication-Info response-header is used by the server to communicate some information regarding the successful HTTP authentication [RFC7235] in the response message. The definition of the header is in [RFC7615], and any applicable HTTP authentication schemes appear in other RFCs, such as Digest [RFC7616]. This header MUST only be used in response messages related to client to server requests.
服务器使用Authentication Info响应头在响应消息中传递有关成功HTTP身份验证[RFC7235]的一些信息。头的定义在[RFC7615]中，任何适用的HTTP身份验证方案都出现在其他RFC中，如摘要[RFC7616]。此标头只能用于与客户端到服务器请求相关的响应消息。
An RTSP client that wishes to authenticate itself with a server using the authentication mechanism from HTTP [RFC7235], usually (but not necessarily) after receiving a 401 response, does so by including an Authorization request-header field with the request. The Authorization field-value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. The definition of the header is in
RTSP客户端希望使用HTTP[RFC7235]的身份验证机制向服务器进行身份验证，通常（但不一定）在收到401响应后，通过在请求中包含授权请求头字段来实现。Authorization字段值由包含所请求资源领域的用户代理的身份验证信息的凭据组成。标题的定义在中
[RFC7235], and any applicable HTTP authentication schemes appear in other RFCs, such as Digest [RFC7616] and Basic [RFC7617]. This header MUST only be used in client-to-server requests.
[RFC7235]和任何适用的HTTP身份验证方案出现在其他RFC中，如摘要[RFC7616]和基本[RFC7617]。此标头只能用于客户端到服务器的请求。
If a request is authenticated and a realm specified, the same credentials SHOULD be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks). Each client-to-server request MUST be individually authorized by including the Authorization header with the information.
如果对请求进行了身份验证并指定了域，则相同的凭据对于该域中的所有其他请求都应有效（假设身份验证方案本身不需要其他凭据，例如根据质询值或使用同步时钟而变化的凭据）。每个客户端到服务器的请求都必须通过包含授权标头和信息来单独授权。
When a shared cache (see Section 16) receives a request containing an Authorization field, it MUST NOT return the corresponding response as a reply to any other request, unless one of the following specific exceptions holds:
当共享缓存（参见第16节）接收到包含授权字段的请求时，它不得将相应的响应作为对任何其他请求的答复返回，除非存在以下特定异常之一：
1. If the response includes the "max-age" cache directive, the cache MAY use that response in replying to a subsequent request. But (if the specified maximum age has passed) a proxy cache MUST first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate the new request. (This is the defined behavior for max-age.) If the response includes "max-age=0", the proxy MUST always revalidate it before reusing it.
1. 如果响应包含“max age”cache指令，则缓存可以使用该响应来响应后续请求。但是（如果已超过指定的最长期限），代理缓存必须首先使用新请求的请求头与源服务器重新验证它，以允许源服务器对新请求进行身份验证。（这是为max age定义的行为。）如果响应包含“max age=0”，则代理必须始终在重用它之前重新验证它。
2. If the response includes the "must-revalidate" cache-control directive, the cache MAY use that response in replying to a subsequent request. But if the response is stale, all caches MUST first revalidate it with the origin server, using the request-headers from the new request to allow the origin server to authenticate the new request.
2. 如果响应包含“必须重新验证”缓存控制指令，则缓存可以在响应后续请求时使用该响应。但是，如果响应过时，所有缓存必须首先使用新请求的请求头与源服务器重新验证它，以允许源服务器对新请求进行身份验证。
3. If the response includes the "public" cache directive, it MAY be returned in reply to any subsequent request.
3. 如果响应包含“public”cache指令，则可以返回该指令以响应任何后续请求。
The Bandwidth request-header field describes the estimated bandwidth available to the client, expressed as a positive integer and measured in kilobits per second. The bandwidth available to the client may change during an RTSP session, e.g., due to mobility, congestion, etc.
带宽请求头字段描述客户端可用的估计带宽，表示为正整数，以千比特每秒为单位。在RTSP会话期间，客户端可用的带宽可能会改变，例如，由于移动性、拥塞等。
Clients may not be able to accurately determine the available bandwidth, for example, because the first hop is not a bottleneck. Such a case is when the local area network (LAN) is not the bottleneck, instead the LAN's Internet access link is, if the server
例如，客户端可能无法准确确定可用带宽，因为第一跳不是瓶颈。这种情况是当局域网（LAN）不是瓶颈时，而局域网的Internet访问链路是，如果服务器
is not in the same LAN. Thus, link speeds of WLAN or Ethernet networks are normally not a basis for estimating the available bandwidth. Cellular devices or other devices directly connected to a modem or connection-enabling device may more accurately estimate the bottleneck bandwidth and what is a reasonable share of it for RTSP-controlled media. The client will also need to take into account other traffic sharing the bottleneck. For example, by only assigning a certain fraction to RTSP and its media streams. It is RECOMMENDED that only clients that have accurate and explicit information about bandwidth bottlenecks use this header.
不在同一局域网中。因此，WLAN或以太网的链路速度通常不是估计可用带宽的基础。蜂窝设备或直接连接到调制解调器或连接启用设备的其他设备可以更准确地估计瓶颈带宽以及RTSP控制媒体的合理带宽份额。客户端还需要考虑共享瓶颈的其他流量。例如，仅将某一部分分配给RTSP及其媒体流。建议只有拥有关于带宽瓶颈的准确明确信息的客户端才使用此标头。
This header is not a substitute for proper congestion control. It is only a method providing an initial estimate and coarsely determines if the selected content can be delivered at all.
此标头不能替代适当的拥塞控制。这只是一种提供初始估计并粗略确定所选内容是否可以交付的方法。
Example:
例子：
Bandwidth: 62360
带宽：62360
The Blocksize request-header field is sent from the client to the media server asking the server for a particular media packet size. This packet size does not include lower-layer headers such as IP, UDP, or RTP. The server is free to use a blocksize that is lower than the one requested. The server MAY truncate this packet size to the closest multiple of the minimum, media-specific block size or override it with the media-specific size, if necessary. The block size MUST be a positive decimal number measured in octets. The server only returns an error (4xx) if the value is syntactically invalid.
Blocksize请求标头字段从客户端发送到媒体服务器，请求服务器提供特定的媒体数据包大小。此数据包大小不包括较低层的头，如IP、UDP或RTP。服务器可以自由使用低于请求的块大小的块。如有必要，服务器可将该数据包大小截断为最小媒体特定块大小的最接近倍数，或用媒体特定块大小覆盖它。块大小必须是以八位字节为单位的正十进制数。只有当值在语法上无效时，服务器才会返回错误（4xx）。
The Cache-Control general-header field is used to specify directives that MUST be obeyed by all caching mechanisms along the request/ response chain.
Cache Control general header字段用于指定请求/响应链上所有缓存机制必须遵守的指令。
Cache directives MUST be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives may be applicable to all recipients along the request/response chain. It is not possible to specify a cache-directive for a specific cache.
缓存指令必须由代理或网关应用程序传递，而不管它们对该应用程序的重要性如何，因为这些指令可能适用于请求/响应链上的所有收件人。无法为特定缓存指定缓存指令。
Cache-Control should only be specified in a DESCRIBE, GET_PARAMETER, SET_PARAMETER, and SETUP request and its response. Note: Cache-Control does not govern only the caching of responses for the RTSP messages, instead it also applies to the media stream identified by
缓存控制只能在descripe、GET_参数、SET_参数和SETUP请求及其响应中指定。注意：缓存控制不仅控制RTSP消息响应的缓存，它还适用于由
the SETUP request. The RTSP requests are generally not cacheable; for further information, see Section 16. Below are the descriptions of the cache directives that can be included in the Cache-Control header.
安装请求。RTSP请求通常不可缓存；有关更多信息，请参见第16节。以下是缓存控制标头中可以包含的缓存指令的说明。
no-cache: Indicates that the media stream or RTSP response MUST NOT be cached anywhere. This allows an origin server to prevent caching even by caches that have been configured to return stale responses to client requests. Note: there is no security function preventing the caching of content.
无缓存：表示媒体流或RTSP响应不能缓存在任何位置。这允许源服务器甚至通过已配置为向客户端请求返回过时响应的缓存来阻止缓存。注意：没有防止内容缓存的安全功能。
public: Indicates that the media stream or RTSP response is cacheable by any cache.
公共：表示媒体流或RTSP响应可由任何缓存缓存。
private: Indicates that the media stream or RTSP response is intended for a single user and MUST NOT be cached by a shared cache. A private (non-shared) cache may cache the media streams.
私有：表示媒体流或RTSP响应针对单个用户，不能由共享缓存缓存。私有（非共享）缓存可以缓存媒体流。
no-transform: An intermediate cache (proxy) may find it useful to convert the media type of a certain stream. A proxy might, for example, convert between video formats to save cache space or to reduce the amount of traffic on a slow link. Serious operational problems may occur, however, when these transformations have been applied to streams intended for certain kinds of applications. For example, applications for medical imaging, scientific data analysis and those using end-to-end authentication all depend on receiving a stream that is bit-for-bit identical to the original media stream or RTSP response. Therefore, if a response includes the no-transform directive, an intermediate cache or proxy MUST NOT change the encoding of the stream or response. Unlike HTTP, RTSP does not provide for partial transformation at this point, e.g., allowing translation into a different language.
不转换：中间缓存（代理）可能会发现转换特定流的媒体类型很有用。例如，代理可以在视频格式之间转换，以节省缓存空间或减少慢速链接上的流量。然而，当这些转换应用于特定类型应用程序的流时，可能会出现严重的操作问题。例如，用于医疗成像、科学数据分析和使用端到端认证的应用程序都依赖于接收与原始媒体流或RTSP响应完全相同的逐位流。因此，如果响应包含no transform指令，则中间缓存或代理不得更改流或响应的编码。与HTTP不同，RTSP此时不提供部分转换，例如，允许翻译成不同的语言。
only-if-cached: In some cases, such as times of extremely poor network connectivity, a client may want a cache to return only those media streams or RTSP responses that it currently has stored and not to receive these from the origin server. To do this, the client may include the only-if-cached directive in a request. If the cache receives this directive, it SHOULD either respond using a cached media stream or response that is consistent with the other constraints of the request or respond with a 504 (Gateway Timeout) status. However, if a group of caches is being operated as a unified system with good internal connectivity, such a request MAY be forwarded within that group of caches.
仅当缓存时：在某些情况下，例如网络连接极差时，客户端可能希望缓存仅返回其当前存储的媒体流或RTSP响应，而不从源服务器接收这些响应。为此，客户端可以在请求中包含only if cached指令。如果缓存接收到该指令，它应该使用缓存的媒体流或与请求的其他约束一致的响应进行响应，或者使用504（网关超时）状态进行响应。然而，如果一组缓存作为具有良好内部连接的统一系统运行，则可以在该组缓存内转发这样的请求。
max-stale: Indicates that the client is willing to accept a media stream or RTSP response that has exceeded its expiration time. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its expiration time by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept a stale response of any age.
max stale：表示客户端愿意接受超过其过期时间的媒体流或RTSP响应。如果为max stale分配了一个值，则客户端愿意接受超出其过期时间不超过指定秒数的响应。如果没有为max stale指定值，那么客户机愿意接受任何年龄的stale响应。
min-fresh: Indicates that the client is willing to accept a media stream or RTSP response whose freshness lifetime is no less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number of seconds.
min fresh：表示客户端愿意接受媒体流或RTSP响应，其新鲜度生存期不小于其当前时间加上指定的时间（以秒为单位）。也就是说，客户机希望响应至少在指定的秒数内保持新鲜。
must-revalidate: When the must-revalidate directive is present in a SETUP response received by a cache, that cache MUST NOT use the cache entry after it becomes stale to respond to a subsequent request without first revalidating it with the origin server. That is, the cache is required to do an end-to-end revalidation every time, if, based solely on the origin server's Expires, the cached response is stale.
必须重新验证：当缓存接收到的设置响应中存在必须重新验证指令时，该缓存在过时后不得使用缓存项来响应后续请求，而无需首先与源服务器重新验证它。也就是说，如果仅基于源服务器的过期，缓存响应过时，则每次都需要缓存进行端到端重新验证。
proxy-revalidate: The proxy-revalidate directive has the same meaning as the must-revalidate directive, except that it does not apply to non-shared user agent caches. It can be used on a response to an authenticated request to permit the user's cache to store and later return the response without needing to revalidate it (since it has already been authenticated once by that user), while still requiring proxies that service many users to revalidate each time (in order to make sure that each user has been authenticated). Note that such authenticated responses also need the "public" cache directive in order to allow them to be cached at all.
proxy revalidate：proxy revalidate指令与must revalidate指令的含义相同，只是它不适用于非共享用户代理缓存。它可以用于对经过身份验证的请求的响应，以允许用户的缓存存储并稍后返回响应，而无需重新验证它（因为它已经由该用户进行了一次身份验证），同时仍然要求每次为多个用户服务的代理重新验证（以确保每个用户都经过身份验证）。请注意，此类经过身份验证的响应还需要“public”cache指令，以便允许缓存它们。
max-age: When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate its own cache entry, and the client has supplied its own validator in the request, the supplied validator might differ from the validator currently stored with the cache entry. In this case, the cache MAY use either validator in making its own request without affecting semantic transparency.
max-age：当通过max-age=0指令强制中间缓存重新验证其自己的缓存项，并且客户端在请求中提供了自己的验证器时，提供的验证器可能与当前存储在缓存项中的验证器不同。在这种情况下，缓存可以使用任一验证器发出自己的请求，而不影响语义透明性。
However, the choice of validator might affect performance. The best approach is for the intermediate cache to use its own validator when making its request. If the server replies with 304 (Not Modified), then the cache can return its now validated copy to the client with a 200 (OK) response. If the server replies with a new message body and cache validator, however,
但是，验证器的选择可能会影响性能。最好的方法是中间缓存在发出请求时使用自己的验证器。如果服务器以304（未修改）进行回复，则缓存可以以200（确定）响应将其现在已验证的副本返回给客户端。但是，如果服务器使用新的邮件正文和缓存验证器进行答复，
the intermediate cache can compare the returned validator with the one provided in the client's request, using the strong comparison function. If the client's validator is equal to the origin server's, then the intermediate cache simply returns 304 (Not Modified). Otherwise, it returns the new message body with a 200 (OK) response.
中间缓存可以使用强比较功能将返回的验证器与客户端请求中提供的验证器进行比较。如果客户端的验证器等于源服务器的验证器，那么中间缓存只返回304（未修改）。否则，它将返回带有200（OK）响应的新消息体。
The Connection general-header field allows the sender to specify options that are desired for that particular connection. It MUST NOT be communicated by proxies over further connections.
Connection general header字段允许发件人指定特定连接所需的选项。不得通过代理通过进一步的连接进行通信。
RTSP 2.0 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional header field may not be sent if there are no parameters associated with that connection option.
RTSP 2.0代理必须在转发消息之前解析连接头字段，对于此字段中的每个连接令牌，从消息中删除与连接令牌同名的任何头字段。连接选项由连接头字段中存在的连接令牌发出信号，而不是由任何相应的附加头字段发出信号，因为如果没有与该连接选项相关联的参数，则可能不会发送附加头字段。
Message headers listed in the Connection header MUST NOT include end-to-end headers, such as Cache-Control.
连接标头中列出的消息标头不得包括端到端标头，例如缓存控制。
RTSP 2.0 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example, "Connection: close in either the request or the response-header fields" indicates that the connection SHOULD NOT be considered "persistent" (Section 10.2) after the current request/ response is complete.
RTSP 2.0为发送方定义了“关闭”连接选项，以表示响应完成后连接将关闭。例如，“请求或响应头字段中的连接：关闭”表示当前请求/响应完成后，连接不应被视为“持久”（第10.2节）。
The use of the connection option "close" in RTSP messages SHOULD be limited to error messages when the server is unable to recover and therefore sees it necessary to close the connection. The reason being that the client has the choice of continuing using a connection indefinitely, as long as it sends valid messages.
RTSP消息中连接选项“close”的使用应限于服务器无法恢复时的错误消息，因此认为有必要关闭连接。原因是客户端可以选择无限期地继续使用连接，只要它发送有效消息。
The Connection-Credentials response-header is used to carry the chain of credentials for any next hop that needs to be approved by the requester. It MUST only be used in server-to-client responses.
Connection Credentials response标头用于为需要请求者批准的任何下一个跃点携带凭据链。它只能用于服务器到客户端的响应。
The Connection-Credentials header in an RTSP response MUST, if included, contain the credential information (in the form of a list of certificates providing the chain of certification) of the next hop to which an intermediary needs to securely connect. The header MUST
RTSP响应中的Connection Credentials标头（如果包括）必须包含中介需要安全连接的下一跳的凭据信息（以提供证书链的证书列表的形式）。标题必须为空
include the URI of the next hop (proxy or server) and a Base64-encoded (according to Section 4 of [RFC4648] and where the padding bits are set to zero) binary structure containing a sequence of DER-encoded X.509v3 certificates [RFC5280].
包括下一跳（代理或服务器）的URI和Base64编码（根据[RFC4648]第4节，其中填充位设置为零）二进制结构，其中包含DER编码的X.509v3证书序列[RFC5280]。
The binary structure starts with the number of certificates (NR_CERTS) included as a 16-bit unsigned integer. This is followed by an NR_CERTS number of 16-bit unsigned integers providing the size, in octets, of each DER-encoded certificate. This is followed by an NR_CERTS number of DER-encoded X.509v3 certificates in a sequence (chain). This format is exemplified in Figure 6. The certificate of the proxy or server must come first in the structure. Each following certificate must directly certify the one preceding it. Because certificate validation requires that root keys be distributed independently, the self-signed certificate that specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.
二进制结构从包含为16位无符号整数的证书数（NR_证书）开始。然后是NR_CERTS数量的16位无符号整数，提供每个DER编码证书的大小（以八位字节为单位）。然后是序列（链）中DER编码的X.509v3证书的NR_CERTS编号。该格式如图6所示。代理或服务器的证书必须位于结构中的第一位。下列证书必须直接证明其前面的证书。由于证书验证要求独立分发根密钥，因此可以选择从链中省略指定根证书颁发机构的自签名证书，前提是远程端必须已经拥有该证书，以便在任何情况下对其进行验证。
Example:
例子：
Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC...
连接凭据：“rtsps://proxy2.example.com/";MIIDNTCC。。。
Where MIIDNTCC... is a Base64 encoding of the following structure:
MIIDNTCC在哪里。。。是以下结构的Base64编码：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of certificates | Size of certificate #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of certificate #2 | Size of certificate #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #3 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of certificates | Size of certificate #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Size of certificate #2 | Size of certificate #3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #1 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #2 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: DER Encoding of Certificate #3 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format Example of Connection-Credentials Header Certificate
图6：连接凭据头证书的格式示例
The Content-Base message body header field may be used to specify the base URI for resolving relative URIs within the message body.
基于内容的消息正文头字段可用于指定用于解析消息正文内的相对URI的基本URI。
Content-Base: rtsp://media.example.com/movie/twister/
Content-Base: rtsp://media.example.com/movie/twister/
If no Content-Base field is present, the base URI of a message body is defined by either its Content-Location (if that Content-Location URI is an absolute URI) or the URI used to initiate the request, in that order of precedence. Note, however, that the base URI of the contents within the message body may be redefined within that message body.
如果不存在内容基字段，则消息体的基URI由其内容位置（如果该内容位置URI是绝对URI）或用于启动请求的URI按照该优先级顺序定义。但是，请注意，消息体中内容的基本URI可以在该消息体中重新定义。
The Content-Encoding message body header field is used as a modifier of the media-type. When present, its value indicates what additional content-codings have been applied to the message body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type.
内容编码消息正文标题字段用作媒体类型的修饰符。当存在时，其值指示已将哪些附加内容编码应用于消息正文，因此必须应用哪些解码机制才能获得内容类型标头字段引用的媒体类型。内容编码主要用于压缩文档而不丢失其底层媒体类型的标识。
The content-coding is a characteristic of the message body identified by the Request-URI. Typically, the message body is stored with this encoding and is only decoded before rendering or analogous usage. However, an RTSP proxy MAY modify the content-coding if the new coding is known to be acceptable to the recipient, unless the "no-transform" cache directive is present in the message.
内容编码是由请求URI标识的消息体的特征。通常，消息体使用此编码存储，并且仅在呈现或类似使用之前解码。但是，如果收件人知道新编码是可接受的，则RTSP代理可以修改内容编码，除非消息中存在“no transform”缓存指令。
If the content-coding of a message body is not "identity", then the message MUST include a Content-Encoding message body header that lists the non-identity content-coding(s) used.
如果消息正文的内容编码不是“标识”，则消息必须包含一个内容编码消息正文标题，该标题列出了所使用的非标识内容编码。
If the content-coding of a message body in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type).
如果请求消息中的消息正文的内容编码不被源服务器接受，则服务器应以状态代码415（不支持的媒体类型）响应。
If multiple encodings have been applied to a message body, the content-codings MUST be listed in the order in which they were applied, first to last from left to right. Additional information about the encoding parameters MAY be provided by other header fields not defined by this specification.
如果对消息正文应用了多个编码，则必须按照应用的顺序列出内容编码，从左到右依次排列。关于编码参数的附加信息可由本规范未定义的其他标题字段提供。
The Content-Language message body header field describes the natural language(s) of the intended audience for the enclosed message body. Note that this might not be equivalent to all the languages used within the message body.
Content Language message body header（内容语言消息正文标题）字段描述所附消息正文的预期受众的自然语言。请注意，这可能并不等同于消息体中使用的所有语言。
Language tags are mentioned in Section 18.4. The primary purpose of Content-Language is to allow a user to identify and differentiate entities according to the user's own preferred language. Thus, if the body content is intended only for a Danish-literate audience, the appropriate field is
第18.4节中提到了语言标签。内容语言的主要目的是允许用户根据自己的首选语言识别和区分实体。因此，如果正文内容仅针对丹麦识字的观众，则适当的字段为
Content-Language: da
内容语言：da
If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean that the sender does not consider it to be specific to any natural language or that the sender does not know for which language it is intended.
如果未指定内容语言，则默认情况下，该内容适用于所有语言受众。这可能意味着发送者不认为它对任何自然语言是特定的，或者发送者不知道它打算使用哪种语言。
Multiple languages MAY be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented simultaneously in the original Maori and English versions, would call for
针对面向多个受众的内容，可以列出多种语言。例如，同时以毛利语和英语原版呈现的《怀唐伊条约》的译本将要求
Content-Language: mi, en
内容语言：mi，en
However, just because multiple languages are present within a message body does not mean that it is intended for multiple linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
然而，仅仅因为在一个消息体中存在多种语言并不意味着它是针对多种语言受众的。一个例子是初学者语言入门，例如“拉丁语第一课”，这显然是为了让懂英语的观众使用。在这种情况下，内容语言将正确地仅包括“en”。
Content-Language MAY be applied to any media type -- it is not limited to textual documents.
内容语言可以应用于任何媒体类型——它不限于文本文档。
The Content-Length message body header field contains the length of the message body of the RTSP message (i.e., after the double CRLF following the last header) in octets of bits. Unlike HTTP, it MUST be included in all messages that carry a message body beyond the header portion of the RTSP message. If it is missing, a default value of zero is assumed. Any Content-Length greater than or equal to zero is a valid value.
Content Length message body header（内容长度消息正文标题）字段包含RTSP消息正文的长度（即，在最后一个标题后面的双CRLF之后），以八位字节为单位。与HTTP不同，它必须包含在所有携带RTSP消息头部分之外的消息体的消息中。如果缺少，则假定默认值为零。任何大于或等于零的内容长度都是有效值。
The Content-Location message body header field MAY be used to supply the resource location for the message body enclosed in the message when that body is accessible from a location separate from the requested resource's URI. A server SHOULD provide a Content-Location for the variant corresponding to the response message body; especially in the case where a resource has multiple variants
当可从与所请求资源的URI分离的位置访问消息体时，可使用Content Location message body header字段为消息中包含的消息体提供资源位置。服务器应为对应于响应消息正文的变量提供内容位置；尤其是在资源具有多个变体的情况下
associated with it, and those entities actually have separate locations by which they might be individually accessed, the server SHOULD provide a Content-Location for the particular variant that is returned.
服务器应该为返回的特定变量提供一个内容位置。
As an example, if an RTSP client performs a DESCRIBE request on a given resource, e.g., "rtsp://a.example.com/movie/ Plan9FromOuterSpace", then the server may use additional information, such as the User-Agent header, to determine the capabilities of the agent. The server will then return a media description tailored to that class of RTSP agents. To indicate which specific description the agent receives, the resource identifier ("rtsp://a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp") is provided in Content-Location, while the description is still a valid response for the generic resource identifier, thus enabling both debugging and cache operation as discussed below.
例如，如果RTSP客户端对给定资源执行描述请求，例如“rtsp://a.example.com/movie/ Plan9FromOuterSpace”，则服务器可以使用其他信息（如用户代理标头）来确定代理的功能。然后，服务器将返回针对该类RTSP代理定制的媒体描述。要指示代理接收的特定描述，请使用资源标识符（“rtsp://a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp），而描述仍然是通用资源标识符的有效响应，因此启用调试和缓存操作，如下所述。
The Content-Location value is not a replacement for the original requested URI; it is only a statement of the location of the resource corresponding to this particular variant at the time of the request. Future requests MAY specify the Content-Location URI as the Request-URI if the desire is to identify the source of that particular variant. This is useful if the RTSP agent desires to verify if the resource variant is current through a conditional request.
内容位置值不是原始请求URI的替换；它只是请求时对应于此特定变量的资源位置的语句。如果希望识别该特定变体的源，则将来的请求可以将内容位置URI指定为请求URI。如果RTSP代理希望通过条件请求验证资源变量是否为当前变量，则此选项非常有用。
A cache cannot assume that a message body with a Content-Location different from the URI used to retrieve it can be used to respond to later requests on that Content-Location URI. However, the Content-Location can be used to differentiate between multiple variants retrieved from a single requested resource.
缓存不能假定内容位置与用于检索它的URI不同的消息体可用于响应该内容位置URI上的后续请求。但是，内容位置可用于区分从单个请求的资源检索的多个变体。
If the Content-Location is a relative URI, the relative URI is interpreted relative to the Request-URI.
如果内容位置是相对URI，则相对URI将相对于请求URI进行解释。
Note that Content-Location can be used in some cases to derive the base-URI for relative URI(s) present in session description formats. This needs to be taken into account when Content-Location is used. The easiest way to avoid needing to consider that issue is to include the Content-Base whenever the Content-Location is included.
请注意，在某些情况下，可以使用内容位置为会话描述格式中存在的相对URI派生基本URI。在使用内容位置时，需要考虑这一点。避免需要考虑该问题的最简单方法是在包含内容位置时包含内容基。
Note also, when using Media Tags in conjunction with Content-Location, it is important that the different versions have different MTags, even if provided under different Content-Location URIs. This is because the different content variants still have been provided in response to the same request URI.
另外请注意，当将媒体标记与内容位置一起使用时，重要的是不同版本具有不同的MTAG，即使在不同的内容位置URI下提供。这是因为仍然提供了不同的内容变体来响应相同的请求URI。
Note also, as in most cases, the URIs used in the DESCRIBE and the SETUP requests are different: the URI provided in a DESCRIBE Content-Location response can't directly be used in a SETUP request. Instead, the steps of deriving the media resource URIs are necessary. This commonly involves combing the media description's relative URIs, e.g., from the SDP's a=control attribute, with the base-URI to create the absolute URIs needed in the SETUP request.
另外请注意，在大多数情况下，描述和设置请求中使用的URI是不同的：描述内容位置响应中提供的URI不能直接用于设置请求。相反，派生媒体资源URI的步骤是必要的。这通常涉及将媒体描述的相对URI（例如，来自SDP的a=control属性）与基本URI相结合，以创建安装请求中所需的绝对URI。
The Content-Type message body header indicates the media type of the message body sent to the recipient. Note that the content types suitable for RTSP are likely to be restricted in practice to presentation descriptions and parameter-value types.
Content Type message body标头指示发送给收件人的邮件正文的媒体类型。注意，适用于RTSP的内容类型在实践中可能仅限于表示描述和参数值类型。
The CSeq general-header field specifies the sequence number (integer) for an RTSP request/response pair. This field MUST be present in all requests and responses. RTSP agents maintain a sequence number series for each responder to which they have an open message transport channel. For each new RTSP request an agent originates on a particular RTSP message transport, the CSeq value MUST be incremented by one. The initial sequence number can be any number; however, it is RECOMMENDED to start at 0. Each sequence number series is unique between each requester and responder, i.e., the client has one series for its requests to a server and the server has another when sending requests to the client. Each requester and responder is identified by its socket address (IP address and port number), i.e., per direction of a TCP connection. Any retransmitted request MUST contain the same sequence number as the original, i.e., the sequence number is not incremented for retransmissions of the same request. The RTSP agent receiving requests MUST process the requests arriving on a particular transport in the order of the sequence numbers. Responses are sent in the order that they are generated. The RTSP response MUST have the same sequence number as was present in the corresponding request. An RTSP agent receiving a response MAY receive the responses out of order compared to the order of the requests it sent. Thus, the agent MUST use the sequence number in the response to pair it with the corresponding request.
CSeq general header字段指定RTSP请求/响应对的序列号（整数）。此字段必须出现在所有请求和响应中。RTSP代理为具有开放消息传输通道的每个响应程序维护序列号序列。对于代理在特定RTSP消息传输上发起的每个新RTSP请求，CSeq值必须增加1。初始序列号可以是任何数字；但是，建议从0开始。每个序列号序列在每个请求者和响应者之间都是唯一的，即，客户端对服务器的请求有一个序列，服务器在向客户端发送请求时有另一个序列。每个请求者和响应者都由其套接字地址（IP地址和端口号）标识，即TCP连接的每个方向。任何重新传输的请求必须包含与原始请求相同的序列号，即，对于相同请求的重新传输，序列号不会增加。接收请求的RTSP代理必须按照序列号的顺序处理在特定传输上到达的请求。响应按生成顺序发送。RTSP响应的序列号必须与相应请求中的序列号相同。接收响应的RTSP代理接收响应的顺序可能与其发送的请求的顺序不同。因此，代理必须在响应中使用序列号将其与相应的请求配对。
The main purpose of the sequence number is to map responses to requests.
序列号的主要用途是将响应映射到请求。
The requirement to use a sequence-number increment of one for each new request is to support any future specification of RTSP message transport over a protocol that does not provide in-order delivery or is unreliable.
对每个新请求使用一个序列号增量的要求是，通过不提供顺序交付或不可靠的协议支持RTSP消息传输的任何未来规范。
The above rules relating to the initial sequence number may appear unnecessarily loose. The reason for this is to cater to some common behavior of existing implementations: when using multiple reliable connections in sequence, it may still be easiest to use a single sequence-number series for a client connecting with a particular server. Thus, the initial sequence number may be arbitrary depending on the number of previous requests. For any unreliable transport, a stricter definition or other solution will be required to enable detection of any loss of the first request.
与初始序列号相关的上述规则可能显得不必要的松散。这样做的原因是为了迎合现有实现的一些常见行为：当按顺序使用多个可靠连接时，对于与特定服务器连接的客户机，使用单个序列号序列可能仍然是最容易的。因此，根据先前请求的数量，初始序列号可以是任意的。对于任何不可靠的传输，需要更严格的定义或其他解决方案来检测第一次请求的任何丢失。
When using multiple sequential transport connections, there is no protocol mechanism to ensure in-order processing as the sequence number is scoped on the individual transport connection and its five tuple. Thus, there are potential issues with opening a new transport connection to the same host for which there already exists a transport connection with outstanding requests and previously dispatched requests related to the same RTSP session.
当使用多个顺序传输连接时，没有协议机制来确保顺序处理，因为序列号的作用域是单个传输连接及其五元组。因此，打开到同一主机的新传输连接时存在潜在问题，对于该主机，已存在传输连接，其中包含与同一RTSP会话相关的未完成请求和以前调度的请求。
RTSP Proxies also need to follow the above rules. This implies that proxies that aggregate requests from multiple clients onto a single transport towards a server or a next-hop proxy need to renumber these requests to form a unified sequence on that transport, fulfilling the above rules. A proxy capable of fulfilling some agent's request without emitting its own request (e.g., a caching proxy that fulfills a request from its cache) also causes a need to renumber as the number of received requests with a particular target may not be the same as the number of emitted requests towards that target agent. A proxy that needs to renumber needs to perform the corresponding renumbering back to the original sequence number for any received response before forwarding it back to the originator of the request.
RTSP代理还需要遵循上述规则。这意味着，将来自多个客户端的请求聚合到通向服务器或下一跳代理的单个传输上的代理需要对这些请求重新编号，以在该传输上形成统一的序列，从而满足上述规则。能够在不发出自身请求的情况下满足某个代理请求的代理（例如，满足其缓存请求的缓存代理）也需要重新编号，因为具有特定目标的接收请求数可能与向该目标代理发出的请求数不同。需要重新编号的代理需要对任何接收到的响应执行相应的重新编号，然后再将其转发回请求的发起人。
A client connected to a proxy, and using that transport to send requests to multiple servers, creates a situation where it is quite likely to receive the responses out of order. This is because the proxy will establish separate transports from the proxy to the servers on which to forward the client's requests. When the responses arrive from the different servers, they will be forwarded to the client in the order they arrive at the proxy and can be processed, not the order of the client's original sequence numbers. This is intentional to avoid some session's requests being blocked by another server's slow processing of requests.
客户机连接到代理，并使用该传输将请求发送到多个服务器，这会造成一种情况，即很可能接收到无序的响应。这是因为代理将建立从代理到服务器的单独传输，在服务器上转发客户端的请求。当来自不同服务器的响应到达时，它们将按照到达代理并可以处理的顺序转发到客户端，而不是按照客户端原始序列号的顺序。这是为了避免某些会话的请求被另一台服务器处理请求的速度缓慢所阻止。
The Date general-header field represents the date and time at which the message was originated. The inclusion of the Date header in an RTSP message follows these rules:
Date general header字段表示消息发出的日期和时间。RTSP消息中包含的日期标头遵循以下规则：
o An RTSP message, sent by either the client or the server, containing a body MUST include a Date header, if the sending host has a clock;
o 如果发送主机有时钟，则由客户端或服务器发送的包含正文的RTSP消息必须包含日期标头；
o Clients and servers are RECOMMENDED to include a Date header in all other RTSP messages, if the sending host has a clock;
o 如果发送主机有时钟，建议客户端和服务器在所有其他RTSP消息中包含日期头；
o If the server does not have a clock that can provide a reasonable approximation of the current time, its responses MUST NOT include a Date header field. In this case, this rule MUST be followed: some origin-server implementations might not have a clock available. An origin server without a clock MUST NOT assign Expires or Last-Modified values to a response, unless these values were associated with the resource by a system or user with a reliable clock. It MAY assign an Expires value that is known, at or before server-configuration time, to be in the past (this allows "pre-expiration" of responses without storing separate Expires values for each resource).
o 如果服务器没有能够提供当前时间合理近似值的时钟，则其响应不得包含日期标头字段。在这种情况下，必须遵循以下规则：某些源服务器实现可能没有可用的时钟。没有时钟的源服务器不得将Expires或Last Modified值分配给响应，除非这些值由具有可靠时钟的系统或用户与资源关联。它可以分配一个在服务器配置时或之前已知的过期值，该值将是过去的（这允许响应“预过期”，而无需为每个资源存储单独的过期值）。
A received message that does not have a Date header field MUST be assigned one by the recipient if the message will be cached by that recipient. An RTSP implementation without a clock MUST NOT cache responses without revalidating them on every use. An RTSP cache, especially a shared cache, SHOULD use a mechanism, such as the Network Time Protocol (NTP) [RFC5905], to synchronize its clock with a reliable external standard.
如果收件人将缓存没有日期标头字段的已接收邮件，则收件人必须为该邮件分配一个字段。没有时钟的RTSP实现在每次使用时都必须重新验证响应，否则不能缓存响应。RTSP缓存，尤其是共享缓存，应该使用一种机制，如网络时间协议（NTP）[RFC5905]，以使其时钟与可靠的外部标准同步。
The RTSP-date, a full date as specified by Section 3.3 of [RFC5322], sent in a Date header SHOULD NOT represent a date and time subsequent to the generation of the message. It SHOULD represent the best available approximation of the date and time of message generation, unless the implementation has no means of generating a reasonably accurate date and time. In theory, the date ought to represent the moment just before the message body is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic value.
在日期标头中发送的RTSP日期（RFC5322第3.3节规定的完整日期）不应表示生成消息后的日期和时间。它应该代表消息生成日期和时间的最佳可用近似值，除非实现无法生成合理准确的日期和时间。理论上，日期应该表示消息体生成之前的时刻。实际上，可以在消息发起期间的任何时间生成日期，而不影响其语义值。
Note: The RTSP 2.0 date format is defined to be the full-date format in RFC 5322. This format is more flexible than the date format in RFC 1123 used by RTSP 1.0. Thus, implementations should use single spaces as separators, as recommended by RFC 5322, and support receiving the obsolete format.
注：RTSP 2.0日期格式定义为RFC 5322中的完整日期格式。此格式比RTSP 1.0使用的RFC 1123中的日期格式更灵活。因此，按照RFC5322的建议，实现应该使用单个空格作为分隔符，并支持接收过时的格式。
Further, note that the syntax allows for a comment to be added at the end of the date.
此外，请注意，语法允许在日期末尾添加注释。
The Expires message body header field gives a date and time after which the description or media-stream should be considered stale. The interpretation depends on the method:
Expires消息正文标头字段提供了一个日期和时间，在此日期和时间之后，说明或媒体流应被视为过时。解释取决于方法：
DESCRIBE response: The Expires header indicates a date and time after which the presentation description (body) SHOULD be considered stale.
描述响应：Expires标头指示一个日期和时间，在此日期和时间之后，应将演示文稿描述（正文）视为过时。
SETUP response: The Expires header indicates a date and time after which the media stream SHOULD be considered stale.
设置响应：Expires标头表示媒体流过期的日期和时间。
A stale cache entry should not be returned by a cache (either a proxy cache or a user agent cache) unless it is first validated with the origin server (or with an intermediate cache that has a fresh copy of the message body). See Section 16 for further discussion of the expiration model.
缓存（代理缓存或用户代理缓存）不应返回过时的缓存项，除非首先使用源服务器（或具有消息正文新副本的中间缓存）对其进行验证。有关过期模型的进一步讨论，请参见第16节。
The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time.
Expires字段的存在并不意味着原始资源将在该时间、之前或之后更改或停止存在。
The format is an absolute date and time as defined by RTSP-date. An example of its use is
格式为RTSP date定义的绝对日期和时间。其使用的一个例子是
Expires: Wed, 23 Jan 2013 15:36:52 +0000
Expires: Wed, 23 Jan 2013 15:36:52 +0000
RTSP 2.0 clients and caches MUST treat other invalid date formats, especially those including the value "0", as having occurred in the past (i.e., already expired).
RTSP 2.0客户端和缓存必须将其他无效日期格式，尤其是那些包含值“0”的格式，视为过去发生过（即已过期）。
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 response as "never expires", an origin server SHOULD use an Expires date approximately one year from the time the response is sent. RTSP 2.0 servers SHOULD NOT send Expires dates that are more than one year in the future.
要将响应标记为“已过期”，源服务器应使用与日期标头值相等的过期日期。要将响应标记为“永不过期”，源服务器应使用从发送响应起大约一年的过期日期。RTSP 2.0服务器不应发送超过一年的过期日期。
The From request-header field, if given, SHOULD contain an Internet email address for the human user who controls the requesting user agent. The address SHOULD be machine usable, as defined by "mailbox" in [RFC1123].
From request header字段（如果给定）应包含控制请求用户代理的用户的Internet电子邮件地址。地址应该是机器可用的，如[RFC1123]中的“邮箱”所定义。
This header field MAY be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It SHOULD NOT be used as an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents SHOULD include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving end.
此标头字段可用于日志记录目的，并可作为标识无效或不需要的请求源的手段。不应将其用作不安全的访问保护形式。该字段的解释是，请求是代表接受所执行方法责任的人员执行的。特别是，机器人代理应包括此标题，以便在接收端出现问题时可以联系负责运行机器人的人员。
The Internet email address in this field MAY be separate from the Internet host that issued the request. For example, when a request is passed through a proxy, the original issuer's address SHOULD be used.
此字段中的Internet电子邮件地址可能与发出请求的Internet主机分开。例如，当请求通过代理传递时，应使用原始颁发者的地址。
The client SHOULD NOT send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at any time prior to a request.
未经用户批准，客户端不应发送“发件人”标题字段，因为这可能会与用户的隐私利益或其网站的安全策略相冲突。强烈建议用户能够在请求之前随时禁用、启用和修改此字段的值。
The If-Match request-header field is especially useful for ensuring the integrity of the presentation description, independent of how the presentation description was received. The presentation description can be fetched via means external to RTSP (such as HTTP) or via the DESCRIBE message. In the case of retrieving the presentation description via RTSP, the server implementation is guaranteeing the integrity of the description between the time of the DESCRIBE message and the SETUP message. By including the MTag given in or with the session description in an If-Match header part of the SETUP request, the client ensures that resources set up are matching the description. A SETUP request with the If-Match header for which the MTag validation check fails MUST generate a response using 412 (Precondition Failed).
If Match request header字段对于确保演示文稿描述的完整性特别有用，与演示文稿描述的接收方式无关。可以通过RTSP外部的方式（如HTTP）或通过描述消息获取表示描述。在通过RTSP检索表示描述的情况下，服务器实现将保证描述消息和设置消息之间描述的完整性。通过在安装请求的If Match头部分中包含会话描述中或与会话描述一起提供的MTag，客户端确保所设置的资源与描述匹配。MTag验证检查失败的具有If Match标头的安装请求必须使用412生成响应（前提条件失败）。
This validation check is also very useful if a session has been redirected from one server to another.
如果会话已从一台服务器重定向到另一台服务器，此验证检查也非常有用。
The If-Modified-Since request-header field is used with the DESCRIBE and SETUP methods to make them conditional. If the requested variant has not been modified since the time specified in this field, a description will not be returned from the server (DESCRIBE) or a stream will not be set up (SETUP). Instead, a 304 (Not Modified) response MUST be returned without any message body.
If-Modified-Since-request标头字段与descripe和SETUP方法一起使用，使它们具有条件。如果自此字段中指定的时间以来未修改请求的变量，则不会从服务器返回描述（描述）或设置流（设置）。相反，必须返回304（未修改）响应，而不返回任何消息体。
An example of the field is:
该字段的一个示例是：
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
This request-header can be used with one or several message body tags to make DESCRIBE requests conditional. A client that has one or more message bodies previously obtained from the resource can verify that none of those entities is current by including a list of their associated message body tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. As a special case, the value "*" matches any current entity of the resource.
此请求头可与一个或多个消息体标记一起使用，以使描述请求具有条件。具有先前从资源获取的一个或多个消息体的客户端可以通过在If none Match标头字段中包含其关联的消息体标记的列表来验证这些实体是否为当前实体。此功能的目的是允许以最小的事务开销高效地更新缓存信息。作为一种特殊情况，值“*”匹配资源的任何当前实体。
If any of the message body tags match the message body tag of the message body that would have been returned in the response to a similar DESCRIBE request (without the If-None-Match header) on that resource, or if "*" is given and any current entity exists for that resource, then the server MUST NOT perform the requested method, unless required to do so because the resource's modification date fails to match that supplied in an If-Modified-Since header field in the request. Instead, if the request method was DESCRIBE, the server SHOULD respond with a 304 (Not Modified) response, including the cache-related header fields (particularly MTag) of one of the message bodies that matched. For all other request methods, the server MUST respond with a status of 412 (Precondition Failed).
如果任何消息体标记与该资源上的类似描述请求（无If None match标头）响应中返回的消息体的消息体标记匹配，或者如果给定了“*”且该资源存在任何当前实体，则服务器不得执行请求的方法，除非由于资源的修改日期与请求中If-Modified-Since标头字段中提供的日期不匹配而需要这样做。相反，如果请求方法是description，服务器应该用304（未修改）响应，包括匹配的其中一个消息体的缓存相关头字段（特别是MTag）。对于所有其他请求方法，服务器的响应状态必须为412（前提条件失败）。
See Section 16.1.3 for rules on how to determine if two message body tags match.
有关如何确定两个消息正文标记是否匹配的规则，请参见第16.1.3节。
If none of the message body tags match, then the server MAY perform the requested method as if the If-None-Match header field did not exist, but MUST also ignore any If-Modified-Since header field(s) in the request. That is, if no message body tags match, then the server MUST NOT return a 304 (Not Modified) response.
如果消息正文标记都不匹配，则服务器可以执行请求的方法，就好像If none match标头字段不存在一样，但也必须忽略请求中的If Modified-Since标头字段。也就是说，如果没有匹配的消息体标记，则服务器不得返回304（未修改）响应。
If the request would, without the If-None-Match header field, result in anything other than a 2xx or 304 status, then the If-None-Match header MUST be ignored. (See Section 16.1.4 for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
如果请求在没有If None Match header字段的情况下会导致除2xx或304状态以外的任何其他状态，则必须忽略If None Match header。（请参阅第16.1.4节，了解在同一请求中同时出现“如果自修改”和“如果不匹配”时服务器行为的讨论。）
The result of a request having both an If-None-Match header field and an If-Match header field is unspecified and MUST be considered an illegal request.
同时具有If None匹配标头字段和If Match标头字段的请求的结果未指定，必须视为非法请求。
The Last-Modified message body header field indicates the date and time at which the origin server believes the presentation description or media stream was last modified. For the DESCRIBE method, the header field indicates the last modification date and time of the description, for the SETUP of the media stream.
Last Modified message body header字段表示源服务器认为演示文稿描述或媒体流上次被修改的日期和时间。对于描述方法，标题字段指示用于设置媒体流的描述的最后修改日期和时间。
An origin server MUST NOT send a Last-Modified date that is later than the server's time of message origination. In such cases, where the resource's last modification would indicate some time in the future, the server MUST replace that date with the message origination date.
源服务器发送的最后修改日期不得晚于服务器的邮件发起时间。在这种情况下，如果资源的最后一次修改将指示将来的某个时间，服务器必须用消息发起日期替换该日期。
An origin server SHOULD obtain the Last-Modified value of the message body as close as possible to the time that it generates the Date value of its response. This allows a recipient to make an accurate assessment of the message body's modification time, especially if the message body changes near the time that the response is generated.
源服务器应在尽可能接近其生成响应日期值的时间获取消息正文的最后修改值。这允许收件人对消息正文的修改时间进行准确评估，尤其是在消息正文在生成响应的时间附近发生更改时。
RTSP servers SHOULD send Last-Modified whenever feasible.
只要可行，RTSP服务器应发送上次修改。
The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 3rr responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field-value consists of a single absolute URI.
Location response header字段用于将收件人重定向到请求URI以外的位置，以完成请求或标识新资源。对于3rr响应，位置应指示服务器的首选URI，以便自动重定向到资源。字段值由单个绝对URI组成。
Note: The Content-Location header field (Section 18.18) differs from Location in that the Content-Location identifies the original location of the message body enclosed in the request. Therefore, it is possible for a response to contain header fields for both Location and Content-Location. Also, see Section 16.2 for cache requirements of some methods.
注意：Content Location标头字段（第18.18节）与Location的不同之处在于，Content Location标识了请求中包含的消息正文的原始位置。因此，响应可能同时包含位置和内容位置的标题字段。此外，有关某些方法的缓存要求，请参见第16.2节。
This general-header is used in SETUP responses or PLAY_NOTIFY requests to indicate the media's properties that currently are applicable to the RTSP session. PLAY_NOTIFY MAY be used to modify these properties at any point. However, the client SHOULD have received the update prior to any action related to the new media properties taking effect. For aggregated sessions, the Media-Properties header will be returned in each SETUP response. The header received in the latest response is the one that applies on the
此常规标头用于设置响应或播放通知请求，以指示当前适用于RTSP会话的媒体属性。PLAY_NOTIFY可用于随时修改这些属性。但是，在与新媒体属性相关的任何操作生效之前，客户端应已收到更新。对于聚合会话，将在每个设置响应中返回媒体属性标头。在最新响应中接收到的标头是应用于
whole session from this point until any future update. The header MAY be included without value in GET_PARAMETER requests to the server with a Session header included to query the current Media-Properties for the session. The responder MUST include the current session's media properties.
从此时开始的整个会话，直到将来的任何更新。在对服务器的GET_参数请求中，如果包含会话头以查询会话的当前媒体属性，则可以不带值地包含该头。响应程序必须包括当前会话的媒体属性。
The media properties expressed by this header are the ones applicable to all media in the RTSP session. 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.
此标头表示的介质属性适用于RTSP会话中的所有介质。对于聚合会话，标头表示组合的媒体属性。结果，媒体的聚合可能导致媒体属性的改变，从而导致包含在后续设置响应中的媒体属性报头的内容的改变。
The header contains a list of property values that are applicable to the currently setup media or aggregate of media as indicated by the RTSP URI in the request. No ordering is enforced within the header. Property values should be placed into a single group that handles a particular orthogonal property. Values or groups that express multiple properties SHOULD NOT be used. The list of properties that can be expressed MAY be extended at any time. Unknown property values MUST be ignored.
标头包含一个属性值列表，这些属性值适用于当前设置的介质或由请求中的RTSP URI指示的介质集合。在标头中不强制执行任何排序。属性值应放在处理特定正交属性的单个组中。不应使用表示多个属性的值或组。可以表示的属性列表可以随时扩展。必须忽略未知的属性值。
This specification defines the following four groups and their property values:
本规范定义了以下四个组及其属性值：
Random Access:
随机存取：
Random-Access: Indicates that random access is possible. May optionally include a floating-point value in seconds indicating the longest duration between any two random access points in the media.
随机访问：表示可以进行随机访问。可以选择性地包括以秒为单位的浮点值，指示媒体中任意两个随机访问点之间的最长持续时间。
Beginning-Only: Seeking is limited to the beginning only.
仅开始：搜索仅限于开始。
No-Seeking: No seeking is possible.
不寻求：不可能寻求。
Content Modifications:
内容修改：
Immutable: The content will not be changed during the lifetime of the RTSP session.
不可变：在RTSP会话的生存期内，内容不会更改。
Dynamic: The content may be changed based on external methods or triggers.
动态：可以根据外部方法或触发器更改内容。
Time-Progressing: The media accessible progresses as wallclock time progresses.
时间进程：可访问介质的进程与挂钟时间的进程相同。
Retention:
保留：
Unlimited: Content will be retained for the duration of the lifetime of the RTSP session.
无限：内容将在RTSP会话的生存期内保留。
Time-Limited: Content will be retained at least until the specified wallclock time. The time must be provided in the absolute time format specified in Section 4.4.3.
时间限制：内容将至少保留到指定的挂钟时间。时间必须以第4.4.3节规定的绝对时间格式提供。
Time-Duration: Each individual media unit is retained for at least the specified Time-Duration. This definition allows for retaining data with a time-based sliding window. The time duration is expressed as floating-point number in seconds. The value 0.0 is a valid as this indicates that no data is retained in a time-progressing session.
持续时间：每个单独的媒体单元至少保留指定的持续时间。此定义允许使用基于时间的滑动窗口保留数据。持续时间表示为以秒为单位的浮点数。值0.0是有效的，因为这表示时间进程会话中不保留任何数据。
Supported Scale:
支持的比例：
Scales: A quoted comma-separated list of one or more decimal values or ranges of scale values supported by the content in arbitrary order. A range has a start and stop value separated by a colon. A range indicates that the content supports a fine-grained selection of scale values. Fine-graining allows for steps at least as small as one tenth of a scale value. Content is considered to support fine-grained selection when the server in response to a given scale value can produce content with an actual scale that is less than one tenth of scale unit, i.e., 0.1, from the requested value. Negative values are supported. The value 0 has no meaning and MUST NOT be used.
刻度：以逗号分隔的引号列表，其中包含一个或多个十进制值，或内容支持的任意顺序的刻度值范围。范围有一个由冒号分隔的开始值和停止值。范围表示内容支持对比例值进行细粒度选择。精细颗粒化允许步骤至少小到刻度值的十分之一。当服务器响应给定的比例值时，可以生成实际比例小于比例单位十分之一（即，0.1）的内容，则认为内容支持细粒度选择。支持负值。值0没有意义，不能使用。
Examples of this header for on-demand content and a live stream without recording are:
点播内容和未录制的直播流的标题示例如下：
On-demand:
Media-Properties: Random-Access=2.5, Unlimited, Immutable,
Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20"
On-demand:
Media-Properties: Random-Access=2.5, Unlimited, Immutable,
Scales="-20, -10, -4, 0.5:1.5, 4, 8, 10, 15, 20"
Live stream without recording/timeshifting:
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0
Live stream without recording/timeshifting:
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0
The Media-Range general-header is used to give the range of the media at the time of sending the RTSP message. This header MUST be included in the SETUP response, PLAY and PAUSE responses for media that are time-progressing, PLAY and PAUSE responses after any change for media that are Dynamic, and in PLAY_NOTIFY requests that are sent
Media Range general标头用于提供发送RTSP消息时的介质范围。此标题必须包含在设置响应、播放和暂停响应（适用于随时间推移的介质）、播放和暂停响应（适用于动态介质）以及播放通知请求（适用于发送的介质）中
due to Media-Property-Update. A Media-Range header without any range specifications MAY be included in GET_PARAMETER requests to the server to request the current range. In this case, the server MUST include the current range at the time of sending the response.
由于媒体属性更新。向服务器请求当前范围的GET_参数请求中可能包含没有任何范围规范的媒体范围标头。在这种情况下，服务器必须在发送响应时包含当前范围。
The header MUST include range specifications for all time formats supported for the media, as indicated in Accept-Ranges header (Section 18.5) when setting up the media. The server MAY include more than one range specification of any given time format to indicate media that has non-continuous range. The range specifications SHALL be ordered with the range with the lowest value or earliest start time first, followed by ranges with increasingly higher values or later start time.
标题必须包括介质支持的所有时间格式的范围规范，如设置介质时的“接受范围”标题（第18.5节）所示。服务器可以包括任意给定时间格式的多个范围规范，以指示具有非连续范围的媒体。订购范围规格时，应首先选择最低值或最早开始时间的范围，然后是值越来越高或开始时间越来越晚的范围。
For media that has the time-progressing property, the Media-Range header values will only be valid for the particular point in time when it was issued. As the wallclock progresses, so will the media range. However, it shall be assumed that media time progresses in direct relationship to wallclock time (with the exception of clock skew) so that a reasonably accurate estimation of the media range can be calculated.
对于具有time progressing属性的介质，介质范围标头值仅在发出时的特定时间点有效。随着wallclock的发展，媒体范围也将不断扩大。但是，应假设媒体时间与挂钟时间直接相关（时钟偏移除外），以便可以计算出媒体范围的合理准确估计。
The MTag response-header MAY be included in DESCRIBE, GET_PARAMETER, or SETUP responses. The message body tags (Section 4.6) returned in a DESCRIBE response and the one in SETUP refer to the presentation, i.e., both the returned session description and the media stream. This allows for verification that one has the right session description to a media resource at the time of the SETUP request. However, it has the disadvantage that a change in any of the parts results in invalidation of all the parts.
MTag响应标头可能包含在描述、获取参数或设置响应中。描述响应中返回的消息正文标记（第4.6节）和设置中的消息正文标记均指演示文稿，即返回的会话描述和媒体流。这允许在设置请求时验证您是否具有媒体资源的正确会话描述。然而，它的缺点是任何零件的变更都会导致所有零件失效。
If the MTag is provided both inside the message body, e.g., within the "a=mtag" attribute in SDP, and in the response message, then both tags MUST be identical. It is RECOMMENDED that the MTag be primarily given in the RTSP response message, to ensure that caches can use the MTag without requiring content inspection. However, for session descriptions that are distributed outside of RTSP, for example, using HTTP, etc., it will be necessary to include the message body tag in the session description as specified in Appendix D.1.9.
如果在邮件正文（例如SDP中的“a=MTag”属性）和响应邮件中都提供了MTag，则两个标记必须相同。建议MTag主要在RTSP响应消息中给出，以确保缓存可以使用MTag而无需进行内容检查。但是，对于在RTSP之外分发的会话描述，例如，使用HTTP等，有必要按照附录D.1.9中的规定，在会话描述中包含消息体标记。
SETUP and DESCRIBE requests can be made conditional upon the MTag using the headers If-Match (Section 18.24) and If-None-Match (Section 18.26).
如果匹配（第18.24节）和不匹配（第18.26节），则可以根据MTag使用标题进行设置和描述请求。
The Notify-Reason response-header is solely used in the PLAY_NOTIFY method. It indicates the reason why the server has sent the asynchronous PLAY_NOTIFY request (see Section 13.5).
Notify Reason response标头仅用于PLAY_Notify方法。它表示服务器发送异步播放通知请求的原因（参见第13.5节）。
The Pipelined-Requests general-header is used to indicate that a request is to be executed in the context created by a previous request(s). The primary usage of this header is to allow pipelining of SETUP requests so that any additional SETUP request after the first one does not need to wait for the session ID to be sent back to the requesting agent. The header contains a unique identifier that is scoped by the persistent connection used to send the requests.
Pipelined Requests general标头用于指示将在先前请求创建的上下文中执行请求。此标头的主要用途是允许安装请求的管道化，以便在第一个安装请求之后的任何其他安装请求都不需要等待会话ID发送回请求代理。标头包含一个唯一标识符，其作用域由用于发送请求的持久连接确定。
Upon receiving a request with the Pipelined-Requests, the responding agent MUST look up if there exists a binding between this Pipelined-Requests identifier for the current persistent connection and an RTSP session ID. If the binding exists, then the received request is processed the same way as if it contained the Session header with the found session ID. If there does not exist a mapping and no Session header is included in the request, the responding agent MUST create a binding upon the successful completion of a session creating request, i.e., SETUP. A binding MUST NOT be created, if the request failed to create an RTSP session. In case the request contains both a Session header and the Pipelined-Requests header, the Pipelined-Requests header MUST be ignored.
收到带有管道化请求的请求后，响应代理必须查找当前持久连接的管道化请求标识符与RTSP会话ID之间是否存在绑定。如果存在绑定，然后，对接收到的请求的处理方式与包含具有找到的会话ID的会话头的处理方式相同。如果不存在映射且请求中不包含会话头，则响应代理必须在成功完成会话创建请求（即设置）后创建绑定。如果请求未能创建RTSP会话，则不得创建绑定。如果请求同时包含会话头和管道化请求头，则必须忽略管道化请求头。
Note: Based on the above definition, at least the first request containing a new unique Pipelined-Requests header will be required to be a SETUP request (unless the protocol is extended with new methods of creating a session). After that first one, additional SETUP requests or requests of any type using the RTSP session context may include the Pipelined-Requests header.
注意：根据上述定义，至少第一个包含新的唯一管道化请求头的请求将被要求是设置请求（除非使用新的会话创建方法扩展协议）。在第一个请求之后，使用RTSP会话上下文的其他设置请求或任何类型的请求可能包括Pipelined requests标头。
When responding to any request that contained the Pipelined-Requests header, the server MUST also include the Session header when a binding to a session context exists. An RTSP agent that knows the session identifier SHOULD NOT use the Pipelined-Requests header in any request and only use the Session header. This as the Session identifier is persistent across transport contexts, like TCP connections, which the Pipelined-Requests identifier is not.
当响应包含Pipelined Requests标头的任何请求时，如果存在与会话上下文的绑定，服务器还必须包含会话标头。知道会话标识符的RTSP代理不应在任何请求中使用Pipelined Requests标头，而应仅使用会话标头。这是因为会话标识符在传输上下文中是持久的，比如TCP连接，而流水线请求标识符不是。
The RTSP agent sending the request with a Pipelined-Requests header has the responsibility for using a unique and previously unused identifier within the transport context. Currently, only a TCP connection is defined as such a transport context. A server MUST
发送带有Pipelined Requests标头的请求的RTSP代理负责在传输上下文中使用唯一且以前未使用的标识符。目前，只有TCP连接被定义为这样的传输上下文。服务器必须
delete the Pipelined-Requests identifier and its binding to a session upon the termination of that session. Despite the previous mandate, RTSP agents are RECOMMENDED not to reuse identifiers to allow for better error handling and logging.
在会话终止时删除流水线请求标识符及其与会话的绑定。尽管有以前的规定，建议RTSP代理不要重用标识符，以便更好地处理和记录错误。
RTSP Proxies may need to translate Pipelined-Requests identifier values from incoming requests to outgoing to allow for aggregation of requests onto a persistent connection.
RTSP代理可能需要将管道化请求标识符值从传入请求转换为传出请求，以便将请求聚合到持久连接上。
The Proxy-Authenticate response-header field MUST be included as part of a 407 (Proxy Authentication Required) response. The field-value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI. The definition of the header is in [RFC7235], and any applicable HTTP authentication schemes appear in other RFCs, such as Digest [RFC7616] and Basic [RFC7617].
代理身份验证响应头字段必须作为407（需要代理身份验证）响应的一部分包含。字段值由一个质询组成，该质询指示适用于此请求URI的代理的身份验证方案和参数。头的定义在[RFC7235]中，任何适用的HTTP身份验证方案都出现在其他RFC中，如摘要[RFC7616]和基本[RFC7617]。
The HTTP access authentication process is described in [RFC7235]. This header MUST only be used in response messages related to client-to-server requests.
[RFC7235]中描述了HTTP访问身份验证过程。此标头只能用于与客户端到服务器请求相关的响应消息。
The Proxy-Authentication-Info response-header is used by the proxy to communicate some information regarding the successful authentication to the proxy in the message response in some authentication schemes, such as the Digest scheme [RFC7616]. The definition of the header is in [RFC7615], and any applicable HTTP authentication schemes appear in other RFCs. This header MUST only be used in response messages related to client-to-server requests. This header has hop-by-hop scope.
代理使用代理身份验证信息响应头在一些身份验证方案（例如摘要方案[RFC7616]）中的消息响应中将有关成功身份验证的一些信息传递给代理。头的定义在[RFC7615]中，任何适用的HTTP身份验证方案都出现在其他RFC中。此标头只能用于与客户端到服务器请求相关的响应消息。此标头具有逐跳范围。
The Proxy-Authorization request-header field allows the client to identify itself (or its user) to a proxy that requires authentication. The Proxy-Authorization field-value consists of credentials containing the authentication information of the user agent for the proxy or realm of the resource being requested. The definition of the header is in [RFC7235], and any applicable HTTP authentication schemes appear in other RFCs, such as Digest [RFC7616] and Basic [RFC7617].
Proxy Authorization request header（代理授权请求标头）字段允许客户端向需要身份验证的代理标识其自身（或其用户）。Proxy Authorization（代理授权）字段值由凭据组成，其中包含所请求资源的代理或领域的用户代理的身份验证信息。头的定义在[RFC7235]中，任何适用的HTTP身份验证方案都出现在其他RFC中，如摘要[RFC7616]和基本[RFC7617]。
The HTTP access authentication process is described in [RFC7235]. Unlike Authorization, the Proxy-Authorization header field applies only to the next-hop proxy. This header MUST only be used in client-to-server requests.
[RFC7235]中描述了HTTP访问身份验证过程。与授权不同，代理授权标头字段仅适用于下一跳代理。此标头只能用于客户端到服务器的请求。
The Proxy-Require request-header field is used to indicate proxy-sensitive features that MUST be supported by the proxy. Any Proxy-Require header features that are not supported by the proxy MUST be negatively acknowledged by the proxy to the client using the Unsupported header. The proxy MUST use the 551 (Option Not Supported) status code in the response. Any feature tag included in the Proxy-Require does not apply to the endpoint (server or client). To ensure that a feature is supported by both proxies and servers, the tag needs to be included in also a Require header.
Proxy Require request header字段用于指示代理必须支持的代理敏感功能。代理不支持的任何代理要求标头功能必须由代理使用不支持的标头向客户端进行负面确认。代理必须在响应中使用551（选项不受支持）状态代码。代理请求中包含的任何功能标记均不适用于端点（服务器或客户端）。为了确保代理和服务器都支持某个功能，标签还需要包含在Require头中。
See Section 18.43 for more details on the mechanics of this message and a usage example. See discussion in the proxies section (Section 15.1) about when to consider that a feature requires proxy support.
有关此消息的机制和用法示例的更多详细信息，请参见第18.43节。请参阅代理部分（第15.1节）中讨论何时考虑功能需要代理支持的讨论。
Example of use:
使用示例：
Proxy-Require: play.basic
代理要求：play.basic
The Proxy-Supported general-header field enumerates all the extensions supported by the proxy using feature tags. The header carries the intersection of extensions supported by the forwarding proxies. The Proxy-Supported header MAY be included in any request by a proxy. It MUST be added by any proxy if the Supported header is present in a request. When present in a request, the receiver MUST copy the received Proxy-Supported header in the response.
Proxy Supported general header字段使用功能标记枚举代理支持的所有扩展。标头包含转发代理支持的扩展的交集。代理支持的头可以包括在代理的任何请求中。如果请求中存在受支持的标头，则必须由任何代理添加。当存在于请求中时，接收方必须在响应中复制接收到的代理支持标头。
The Proxy-Supported header field contains a list of feature tags applicable to proxies, as described in Section 4.5. The list is the intersection of all feature tags understood by the proxies. To achieve an intersection, the proxy adding the Proxy-Supported header includes all proxy feature tags it understands. Any proxy receiving a request with the header MUST check the list and remove any feature tag(s) it does not support. A Proxy-Supported header present in the response MUST NOT be modified by the proxies. These feature tags are the ones the proxy chains support in general and are not specific to the request resource.
代理支持的标题字段包含适用于代理的功能标签列表，如第4.5节所述。该列表是代理理解的所有要素标记的交点。要实现交集，添加代理支持的标头的代理将包括其理解的所有代理功能标记。任何接收到带有标头的请求的代理都必须检查列表并删除其不支持的任何功能标记。代理不能修改响应中存在的代理支持的标头。这些特性标记通常是代理链支持的，并且不是特定于请求资源的。
Example:
例子：
C->P1: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech
User-Agent: PhonyClient/1.2
C->P1: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech
User-Agent: PhonyClient/1.2
P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-bar, proxy-blech
Via: 2.0 pro.example.com
P1->P2: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-bar, proxy-blech
Via: 2.0 pro.example.com
P2->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-blech
Via: 2.0 pro.example.com, 2.0 prox2.example.com
P2->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech
Proxy-Supported: proxy-foo, proxy-blech
Via: 2.0 pro.example.com, 2.0 prox2.example.com
S->C: RTSP/2.0 200 OK
Supported: foo, bar, baz
Proxy-Supported: proxy-foo, proxy-blech
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Via: 2.0 pro.example.com, 2.0 prox2.example.com
S->C: RTSP/2.0 200 OK
Supported: foo, bar, baz
Proxy-Supported: proxy-foo, proxy-blech
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
Via: 2.0 pro.example.com, 2.0 prox2.example.com
The Public response-header field lists the set of methods supported by the response sender. This header applies to the general capabilities of the sender, and its only purpose is to indicate the sender's capabilities to the recipient. The methods listed may or may not be applicable to the Request-URI; the Allow header field (Section 18.6) MAY be used to indicate methods allowed for a particular URI.
Public response header字段列出响应发送方支持的方法集。此标题适用于发送方的一般功能，其唯一目的是向接收方指示发送方的功能。列出的方法可能适用于请求URI，也可能不适用于请求URI；Allow header字段（第18.6节）可用于指示特定URI允许的方法。
Example of use:
使用示例：
Public: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN
公共：选项、设置、播放、暂停、拆卸
In the event that there are proxies between the sender and the recipient of a response, each intervening proxy MUST modify the Public header field to remove any methods that are not supported via that proxy. The resulting Public header field will contain an intersection of the sender's methods and the methods allowed through by the intervening proxies.
如果响应的发送方和接收方之间存在代理，则每个介入代理必须修改公共头字段，以删除该代理不支持的任何方法。生成的公共头字段将包含发送方方法和中间代理允许通过的方法的交集。
In general, proxies should allow all methods to transparently pass through from the sending RTSP agent to the receiving RTSP agent, but there may be cases where this is not desirable for a given proxy. Modification of the Public response-header field by the
一般来说，代理应该允许所有方法从发送RTSP代理透明地传递到接收RTSP代理，但在某些情况下，这对于给定代理是不可取的。用户修改公共响应标头字段
intervening proxies ensures that the request sender gets an accurate response indicating the methods that can be used on the target agent via the proxy chain.
介入代理可确保请求发送方获得准确响应，指示可通过代理链在目标代理上使用的方法。
The Range general-header specifies a time range in PLAY (Section 13.4), PAUSE (Section 13.6), SETUP (Section 13.3), and PLAY_NOTIFY (Section 13.5) requests and responses. It MAY be included in GET_PARAMETER requests from the client to the server with only a Range format and no value to request the current media position, whether the session is in Play or Ready state in the included format. The server SHALL, if supporting the range format, respond with the current playing point or pause point as the start of the range. If an explicit stop point was used in the previous PLAY request, then that value shall be included as stop point. Note that if the server is currently under any type of media playback manipulation affecting the interpretation of the Range header, like scale value other than 1, that fact is also required to be included in any GET_PARAMETER response by including the Scale header to provide complete information.
Range general标头指定播放（第13.4节）、暂停（第13.6节）、设置（第13.3节）和播放通知（第13.5节）请求和响应的时间范围。它可能包含在从客户端到服务器的GET_参数请求中，仅使用范围格式，而不使用任何值来请求当前媒体位置，无论会话是否处于包含格式的播放或就绪状态。如果服务器支持范围格式，则应以当前播放点或暂停点作为范围的开始点进行响应。如果在上一次播放请求中使用了明确的停止点，则该值应包含为停止点。请注意，如果服务器当前正在进行影响范围标头解释的任何类型的媒体播放操作（如除1以外的缩放值），则还需要通过包括缩放标头来在任何GET_参数响应中包括该事实，以提供完整信息。
The range can be specified in a number of units. This specification defines smpte (Section 4.4.1), npt (Section 4.4.2), and clock (Section 4.4.3) range units. While octet ranges (Byte Ranges) (see Section 2.1 of [RFC7233]) and other extended units MAY be used, their behavior is unspecified since they are not normally meaningful in RTSP. Servers supporting the Range header MUST understand the NPT range format and SHOULD understand the SMPTE range format. If the Range header is sent in a time format that is not understood, the recipient SHOULD return 456 (Header Field Not Valid for Resource) and include an Accept-Ranges header indicating the supported time formats for the given resource.
范围可以用许多单位指定。本规范定义了smpte（第4.4.1节）、npt（第4.4.2节）和时钟（第4.4.3节）量程单位。虽然可以使用八位字节范围（字节范围）（见[RFC7233]第2.1节）和其他扩展单元，但它们的行为未指定，因为它们在RTSP中通常没有意义。支持范围标头的服务器必须理解NPT范围格式，并且应该理解SMPTE范围格式。如果范围标头以不可理解的时间格式发送，则收件人应返回456（标头字段对资源无效），并包含一个Accept Ranges标头，指示给定资源支持的时间格式。
Example:
例子：
Range: clock=19960213T143205Z-
范围：时钟=19960213T143205Z-
The Range header contains a range of one single range format. A range is a half-open interval with a start and an end point, including the start point but excluding the end point. A range may either be fully specified with explicit values for start point and end point or have either the start or end point be implicit. An implicit start point indicates the session's pause point, and if no pause point is set, the start of the content. An implicit end point indicates the end of the content. The usage of both implicit start
范围标头包含一个单一范围格式的范围。范围是具有起点和终点的半开区间，包括起点但不包括终点。范围可以完全指定为起点和终点的显式值，也可以隐式指定起点或终点。隐式起点表示会话的暂停点，如果未设置暂停点，则表示内容的开始。隐式结束点表示内容的结束。隐式启动和隐式启动的用法
and end points is not allowed in the same Range header; however, the omission of the Range header has that meaning, i.e., from pause point (or start) until end of content.
和端点不允许在同一范围标头中；然而，省略范围标题具有该含义，即从暂停点（或开始）到内容结束。
As noted, Range headers define half-open intervals. A range of A-B starts exactly at time A, but ends just before B. Only the start time of a media unit such as a video or audio frame is relevant. For example, assume that video frames are generated every 40 ms. A range of 10.0-10.1 would include a video frame starting at 10.0 or later time and would include a video frame starting at 10.08, even though it lasted beyond the interval. A range of 10.0-10.08, on the other hand, would exclude the frame at 10.08.
如上所述，范围标头定义了半开间隔。A-B范围恰好在时间A开始，但在时间B之前结束。只有媒体单元（如视频或音频帧）的开始时间才相关。例如，假设每40 ms生成一次视频帧。10.0-10.1的范围将包括在10.0或更高时间开始的视频帧，并且将包括在10.08开始的视频帧，即使其持续时间超过间隔。另一方面，10.0-10.08的范围将排除10.08的帧。
Please note the difference between NPT timescales' "now" and an implicit start value. Implicit values reference the current pause-point, while "now" is the current time. In a time-progressing session with recording (retention for some or full time), the pause point may be 2 min into the session while now could be 1 hour into the session.
请注意NPT时间刻度的“现在”和隐式开始值之间的差异。隐式值引用当前暂停点，“now”是当前时间。在进行记录的时间进程会话（保留部分或全部时间）中，暂停点可能是会话开始2分钟，而现在可能是会话开始1小时。
By default, range intervals increase, where the second point is larger than the first point.
默认情况下，范围间隔增加，其中第二个点大于第一个点。
Example:
例子：
Range: npt=10-15
范围：npt=10-15
However, range intervals can also decrease if the Scale header (see Section 18.46) indicates a negative scale value. For example, this would be the case when a playback in reverse is desired.
但是，如果刻度表头（见第18.46节）指示负刻度值，则量程间隔也会减小。例如，当需要反向播放时，就会出现这种情况。
Example:
例子：
Scale: -1
Range: npt=15-10
Scale: -1
Range: npt=15-10
Decreasing ranges are still half-open intervals as described above. Thus, for range A-B, A is closed and B is open. In the above example, 15 is closed and 10 is open. An exception to this rule is the case when B=0 is in a decreasing range. In this case, the range is closed on both ends, as otherwise there would be no way to reach 0 on a reverse playback for formats that have such a notion, like NPT and SMPTE.
如上所述，递减范围仍然是半开区间。因此，对于范围A-B，A关闭，B打开。在上述示例中，15关闭，10打开。此规则的一个例外情况是B=0在递减范围内。在本例中，范围在两端都是闭合的，否则对于具有这种概念的格式（如NPT和SMPTE），在反向播放时将无法达到0。
Example:
例子：
Scale: -1
Range: npt=15-0
Scale: -1
Range: npt=15-0
In this range, both 15 and 0 are closed.
在此范围内，15和0均为闭合。
A decreasing range interval without a corresponding negative value in the Scale header is not valid.
刻度表头中没有相应负值的递减范围间隔无效。
The Referrer request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained. The URI refers to that of the presentation description, typically retrieved via HTTP. The Referrer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referrer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.
referer请求头字段允许客户机为服务器指定从中获取请求URI的资源的地址（URI）。URI指的是表示描述的URI，通常通过HTTP检索。referer请求头允许服务器生成指向感兴趣资源、日志记录、优化缓存等的反向链接列表。它还允许跟踪过时或键入错误的链接以进行维护。如果请求URI是从没有自己URI的源（如用户键盘的输入）获取的，则不得发送Referrer字段。
If the field-value is a relative URI, it SHOULD be interpreted relative to the Request-URI. The URI MUST NOT include a fragment identifier.
如果字段值是相对URI，则应相对于请求URI进行解释。URI不得包含片段标识符。
Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referrer field is sent. For example, a streaming client could have a toggle switch for openly/anonymously, which would respectively enable/disable the sending of Referrer and From information.
由于链接的来源可能是私人信息，或者可能会显示其他私人信息来源，因此强烈建议用户能够选择是否发送Referrer字段。例如，流式客户端可以有一个公开/匿名切换开关，分别启用/禁用推荐人和来自信息的发送。
Clients SHOULD NOT include a Referrer header field in an (non-secure) RTSP request if the referring page was transferred with a secure protocol.
如果引用页面是通过安全协议传输的，则客户端不应在（非安全）RTSP请求中包含引用者标头字段。
This request-header is used to indicate the end result for requests that take time to complete, such as PLAY (Section 13.4). It is sent in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report how the PLAY request concluded, either in success or in failure. The header carries a reference to the request it reports on using the CSeq number and the Session ID used in the request reported on. This is not ensured to be unambiguous due to the fact that the CSeq number is scoped by the transport connection. Agents originating requests
此请求标头用于指示需要时间才能完成的请求的最终结果，如播放（第13.4节）。在PLAY_NOTIFY（第13.5节）中发送，带有流结束原因，以报告播放请求如何结束（成功或失败）。报头使用CSeq号和报告的请求中使用的会话ID携带对其报告的请求的引用。由于CSeq编号的范围由传输连接确定，因此无法确保这是明确的。发起请求的代理
can reduce the issue by using a monotonically increasing counter across all sequential transports used. The header provides both a numerical status code (according to Section 8.1.1) and a human-readable reason phrase.
可以通过在所有使用的顺序传输中使用单调递增的计数器来减少问题。标题提供数字状态代码（根据第8.1.1节）和人类可读的原因短语。
Example:
Request-Status: cseq=63 status=500 reason="Media data unavailable"
Example:
Request-Status: cseq=63 status=500 reason="Media data unavailable"
Proxies that renumber the CSeq header need to perform corresponding remapping of the cseq parameter in this header when forwarding the request to the next-hop agent.
将请求转发给下一跳代理时，重新编号CSeq头的代理需要在此头中执行CSeq参数的相应重新映射。
The Require request-header field is used by agents to ensure that the other endpoint supports features that are required in respect to this request. It can also be used to query if the other endpoint supports certain features; however, the use of the Supported general-header (Section 18.51) is much more effective in this purpose. In case any of the feature tags listed by the Require header are not supported by the server or client receiving the request, it MUST respond to the request using the error code 551 (Option Not Supported) and include the Unsupported header listing those feature tags that are NOT supported. This header does not apply to proxies; for the same functionality with respect to proxies, see the Proxy-Require header (Section 18.37) 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 a server, do need to understand also the server's features to correctly serve the client.
代理使用Require-request-header字段来确保其他端点支持此请求所需的功能。它还可以用于查询其他端点是否支持某些功能；然而，在这方面，使用受支撑的通用收割台（第18.51节）更有效。如果接收请求的服务器或客户端不支持Require标头列出的任何功能标记，则必须使用错误代码551（选项不支持）响应请求，并包括列出不支持的功能标记的不支持标头。此标题不适用于代理；有关代理的相同功能，请参见代理要求标题（第18.37节），但媒体修改代理除外。介质修改代理，由于其处理介质的方式与服务器非常相似，因此也需要了解服务器的功能，以便正确地为客户端服务。
This is to make sure that the client-server interaction will proceed without delay when all features are understood by both sides and only slow down if features are not understood (as in the example below). For a well-matched client-server pair, the interaction proceeds quickly, saving a round trip often required by negotiation mechanisms. In addition, it also removes state ambiguity when the client requires features that the server does not understand.
这是为了确保当双方都理解了所有特性时，客户机-服务器交互将毫不延迟地进行，并且只有在不理解特性时才会减慢（如下面的示例所示）。对于匹配良好的客户机-服务器对，交互进行得很快，节省了协商机制通常需要的往返时间。此外，当客户端需要服务器不理解的功能时，它还消除了状态模糊性。
Example (Not complete):
示例（不完整）：
C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302
Require: funky-feature
Funky-Parameter: funkystuff
C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302
Require: funky-feature
Funky-Parameter: funkystuff
S->C: RTSP/2.0 551 Option not supported
CSeq: 302
Unsupported: funky-feature
S->C: RTSP/2.0 551 Option not supported
CSeq: 302
Unsupported: funky-feature
In this example, "funky-feature" is the feature tag that indicates to the client that the fictional Funky-Parameter field is required. The relationship between "funky-feature" and Funky-Parameter is not communicated via the RTSP exchange, since that relationship is an immutable property of "funky-feature" and thus should not be transmitted with every exchange.
在本例中，“funky feature”是向客户机指示虚构的funky参数字段是必需的特性标记。“funky feature”和funky参数之间的关系不通过RTSP交换进行通信，因为该关系是“funky feature”的不可变属性，因此不应在每次交换中传输。
Proxies and other intermediary devices MUST ignore this header. If a particular extension requires that intermediate devices support it, the extension should be tagged in the Proxy-Require field instead (see Section 18.37). See discussion in the proxies section (Section 15.1) about when to consider that a feature requires proxy support.
代理和其他中间设备必须忽略此标头。如果特定扩展需要中间设备支持，则应在代理要求字段中标记该扩展（参见第18.37节）。请参阅代理部分（第15.1节）中讨论何时考虑功能需要代理支持的讨论。
The Retry-After response-header field can be used with a 503 (Service Unavailable) or 553 (Proxy Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. This field MAY also be used with any 3rr (Redirection) response to indicate the minimum time the user agent is asked to wait before issuing the redirected request. A response using 413 (Request Message Body Too Large) when the restriction is temporary MAY also include the Retry-After header. The value of this field can be either an RTSP-date or an integer number of seconds (in decimal) after the time of the response.
响应后重试报头字段可与503（服务不可用）或553（代理不可用）响应一起使用，以指示服务预计对请求客户端不可用的时间。此字段还可与任何3rr（重定向）响应一起使用，以指示在发出重定向请求之前要求用户代理等待的最短时间。当限制是临时的时，使用413（请求消息正文太大）的响应也可能包括Retry After报头。此字段的值可以是RTSP日期，也可以是响应时间后的整数秒数（十进制）。
Example:
例子：
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
In the latter example, the delay is 2 minutes.
在后一个示例中，延迟为2分钟。
The RTP-Info general-header field is used to set RTP-specific parameters in the PLAY and GET_PARAMETER responses or PLAY_NOTIFY and GET_PARAMETER requests. For streams using RTP as transport protocol, the RTP-Info header SHOULD be part of a 200 response to PLAY.
RTP Info general header字段用于在播放中设置RTP特定参数并获取参数响应或播放通知并获取参数请求。对于使用RTP作为传输协议的流，RTP Info报头应该是要播放的200响应的一部分。
The exclusion of the RTP-Info in a PLAY response for RTP-transported media will result in a client needing to synchronize the media streams using RTCP. This may have negative impact as the RTCP can be lost and does not need to be particularly timely in its arrival. Also, functionality that informs the client from which packet a seek has occurred is affected.
在RTP传输媒体的播放响应中排除RTP信息将导致客户端需要使用RTCP同步媒体流。这可能会产生负面影响，因为RTCP可能会丢失，并且不需要在到达时特别及时。此外，通知客户端已从哪个数据包进行搜索的功能也会受到影响。
The RTP-Info MAY be included in SETUP responses to provide synchronization information when changing transport parameters, see Section 13.3. The RTP-Info header and the Range header MAY be included in a GET_PARAMETER request from client to server without any values to request the current playback point and corresponding RTP synchronization information. When the RTP-Info header is included in a Request, the Range header MUST also be included. The server response SHALL include both the Range header and the RTP-Info header. If the session is in Play state, then the value of the Range header SHALL be filled in with the current playback point and with the corresponding RTP-Info values. If the server is in another state, no values are included in the RTP-Info header. The header is included in PLAY_NOTIFY requests with the Notify-Reason of the end of stream to provide RTP information about the end of the stream.
RTP信息可包含在设置响应中，以在更改传输参数时提供同步信息，请参见第13.3节。RTP Info报头和Range报头可以包括在从客户端到服务器的GET_参数请求中，而不需要任何值来请求当前播放点和相应的RTP同步信息。当请求中包含RTP Info标头时，还必须包含范围标头。服务器响应应包括范围标头和RTP信息标头。如果会话处于播放状态，则应使用当前播放点和相应的RTP Info值填写范围标头的值。如果服务器处于其他状态，则RTP Info标头中不包含任何值。标头包含在PLAY_NOTIFY请求中，带有流结束的通知原因，以提供流结束的RTP信息。
The header can carry the following parameters:
收割台可以携带以下参数：
url: Indicates the stream URI for which the following RTP parameters correspond; this URI MUST be the same as used in the SETUP request for this media stream. Any relative URI MUST use the Request-URI as base URI. This parameter MUST be present.
url：表示以下RTP参数对应的流URI；此URI必须与此媒体流的设置请求中使用的URI相同。任何相对URI都必须使用请求URI作为基本URI。此参数必须存在。
ssrc: The SSRC to which the RTP timestamp and sequence number provided applies. This parameter MUST be present.
ssrc：提供的RTP时间戳和序列号适用的ssrc。此参数必须存在。
seq: Indicates the sequence number of the first packet of the stream that is direct result of the request. This allows clients to gracefully deal with packets when seeking. The client uses this value to differentiate packets that originated before the seek from packets that originated after the seek. Note that a client may not receive the packet with the expressed sequence number and instead may receive packets with a higher sequence number due to packet loss or reordering. This parameter is RECOMMENDED to be present.
seq：指示流的第一个数据包的序列号，该数据包是请求的直接结果。这允许客户端在查找数据包时优雅地处理数据包。客户机使用此值区分在搜索之前发出的数据包和在搜索之后发出的数据包。注意，客户端可能不会接收具有所表示的序列号的分组，而是由于分组丢失或重新排序而接收具有更高序列号的分组。建议存在此参数。
rtptime: MUST indicate the RTP timestamp value corresponding to the start time value in the Range response-header or, if not explicitly given, the implied start point. The client uses this value to calculate the mapping of RTP time to NPT or other media timescale. This parameter SHOULD be present to ensure inter-media synchronization is achieved. There exists no requirement that any received RTP packet will have the same RTP timestamp value as the one in the parameter used to establish synchronization.
rtptime：必须指示与范围响应标头中的开始时间值相对应的RTP时间戳值，或者，如果没有明确给出，则指示隐含的开始点。客户端使用此值计算RTP时间到NPT或其他媒体时间刻度的映射。应提供此参数以确保实现媒体间同步。不要求任何接收到的RTP数据包具有与用于建立同步的参数中的RTP时间戳值相同的RTP时间戳值。
A mapping from RTP timestamps to NTP format timestamps (wallclock) is available via RTCP. However, this information is not sufficient to generate a mapping from RTP timestamps to media clock time (NPT, etc.). Furthermore, in order to ensure that this information is available at the necessary time (immediately at startup or after a seek), and that it is delivered reliably, this mapping is placed in the RTSP control channel.
从RTP时间戳到NTP格式时间戳（wallclock）的映射可通过RTCP获得。但是，该信息不足以生成从RTP时间戳到媒体时钟时间（NPT等）的映射。此外，为了确保该信息在必要的时间可用（启动时或寻道后立即可用），并且可靠地传递，将该映射放置在RTSP控制通道中。
In order to compensate for drift for long, uninterrupted presentations, RTSP clients should additionally map NPT to NTP, using initial RTCP sender reports to do the mapping, and later reports to check drift against the mapping.
为了补偿长时间不间断演示的漂移，RTSP客户端应另外将NPT映射到NTP，使用初始RTCP发送方报告进行映射，然后使用后续报告根据映射检查漂移。
Example:
例子：
Range:npt=3.25-15
RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102;
rtptime=12345678,url="rtsp://example.com/foo/video"
ssrc=9A9DE123:seq=30211;rtptime=29567112
Range:npt=3.25-15
RTP-Info:url="rtsp://example.com/foo/audio" ssrc=0A13C760:seq=45102;
rtptime=12345678,url="rtsp://example.com/foo/video"
ssrc=9A9DE123:seq=30211;rtptime=29567112
Lets assume that Audio uses a 16 kHz RTP timestamp clock and Video a 90 kHz RTP timestamp clock. Then, the media synchronization is depicted in the following way.
假设音频使用16 kHz RTP时间戳时钟，视频使用90 kHz RTP时间戳时钟。然后，以以下方式描述媒体同步。
NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6
Audio PA A
Video V PV
NPT 3.0---3.1---3.2-X-3.3---3.4---3.5---3.6
Audio PA A
Video V PV
X: NPT time value = 3.25, from Range header.
A: RTP timestamp value for Audio from RTP-Info header (12345678).
V: RTP timestamp value for Video from RTP-Info header (29567112).
PA: RTP audio packet carrying an RTP timestamp of 12344878, which
corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2
PV: RTP video packet carrying an RTP timestamp of 29573412, which
corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32
X: NPT time value = 3.25, from Range header.
A: RTP timestamp value for Audio from RTP-Info header (12345678).
V: RTP timestamp value for Video from RTP-Info header (29567112).
PA: RTP audio packet carrying an RTP timestamp of 12344878, which
corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2
PV: RTP video packet carrying an RTP timestamp of 29573412, which
corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32
The Scale general-header indicates the requested or used view rate for the media resource being played back. A scale value of 1 indicates normal play at the normal forward viewing rate. If not 1, the value corresponds to the rate with respect to normal viewing rate. For example, a value of 2 indicates twice the normal viewing rate ("fast forward") and a value of 0.5 indicates half the normal viewing rate. In other words, a value of 2 has content time increase at twice the playback time. For every second of elapsed (wallclock) time, 2 seconds of content time will be delivered. A negative value indicates reverse direction. For certain media transports, this may require certain considerations to work consistently; see Appendix C.1 for description on how RTP handles this.
“缩放常规”标题指示正在播放的媒体资源的请求或使用的观看率。比例值为1表示在正常向前观看速率下的正常播放。如果不是1，则该值对应于相对于正常观看率的速率。例如，值2表示正常观看率的两倍（“快进”），值0.5表示正常观看率的一半。换句话说，值2使内容时间以播放时间的两倍增加。每经过一秒（wallclock）时间，就会交付2秒的内容时间。负值表示方向相反。对于某些媒体传输，这可能需要考虑某些因素才能始终如一地工作；有关RTP如何处理此问题的说明，请参见附录C.1。
The transmitted-data rate SHOULD NOT be changed by selection of a different scale value. The resulting bitrate should be reasonably close to the nominal bitrate of the content for scale = 1. The server has to actively manipulate the data when needed to meet the bitrate constraints. Implementation of scale changes depends on the server and media type. For video, a server may, for example, deliver only key frames or selected frames. For audio, it may time-scale the audio while preserving pitch or, less desirably, deliver fragments of audio, or completely mute the audio.
不应通过选择不同的标度值来改变传输的数据速率。对于scale=1，结果比特率应合理地接近内容的标称比特率。当需要满足比特率约束时，服务器必须主动操作数据。规模更改的实施取决于服务器和媒体类型。例如，对于视频，服务器可以仅传送关键帧或选定帧。对于音频，它可以在保持音高的同时对音频进行时间缩放，或者在不太理想的情况下传递音频片段，或者完全静音音频。
The server and content may restrict the range of scale values that it supports. The supported values are indicated by the Media-Properties header (Section 18.29). The client SHOULD only indicate request values to be supported. However, as the values may change as the content progresses, a requested value may no longer be valid when the request arrives. Thus, a non-supported value in a request does not generate an error, it only forces the server to choose the closest value. The response MUST always contain the actual scale value chosen by the server.
服务器和内容可能会限制其支持的缩放值范围。支持的值由介质属性标题指示（第18.29节）。客户端应仅指示要支持的请求值。但是，由于值可能随着内容的进展而改变，因此请求到达时，请求的值可能不再有效。因此，请求中不支持的值不会生成错误，它只会强制服务器选择最接近的值。响应必须始终包含服务器选择的实际比例值。
If the server does not implement the possibility to scale, it will not return a Scale header. A server supporting scale operations for PLAY MUST indicate this with the use of the "play.scale" feature tag.
如果服务器没有实现缩放的可能性，它将不会返回缩放头。支持播放缩放操作的服务器必须使用“PLAY.scale”功能标签来指示这一点。
When indicating a negative scale for a reverse playback, the Range header MUST indicate a decreasing range as described in Section 18.40.
当指示反向播放的负刻度时，范围标题必须指示第18.40节所述的递减范围。
Example of playing in reverse at 3.5 times normal rate:
以3.5倍正常速率反向播放的示例：
Scale: -3.5
Range: npt=15-10
Scale: -3.5
Range: npt=15-10
When a client sends a PLAY request with a Range header to perform a random access to the media, the client does not know if the server will pick the first media samples or the first random access point prior to the request range. Depending on the use case, the client may have a strong preference. To express this preference and provide the client with information on how the server actually acted on that preference, the Seek-Style general-header is defined.
当客户端发送带有范围标头的播放请求以执行对媒体的随机访问时，客户端不知道服务器是否会在请求范围之前拾取第一个媒体样本或第一个随机访问点。根据用例的不同，客户可能有强烈的偏好。要表达此首选项并向客户端提供有关服务器如何实际执行该首选项的信息，需要定义Seek样式的general标头。
Seek-Style is a general-header that MAY be included in any PLAY request to indicate the client's preference for any media stream that has the random access properties. The server MUST always include the header in any PLAY response for media with random access properties to indicate what policy was applied. A server that receives an unknown Seek-Style policy MUST ignore it and select the server default policy. A client receiving an unknown policy MUST ignore it and use the Range header and any media synchronization information as basis to determine what the server did.
Seek Style是可包括在任何播放请求中的通用标头，以指示客户端对具有随机访问属性的任何媒体流的偏好。对于具有随机访问属性的媒体，服务器必须始终在任何播放响应中包含标头，以指示应用了什么策略。接收未知搜索样式策略的服务器必须忽略它并选择服务器默认策略。接收未知策略的客户端必须忽略该策略，并使用范围标头和任何媒体同步信息作为确定服务器所做操作的基础。
This specification defines the following seek policies that may be requested (see also Section 4.7.1):
本规范规定了可能要求的以下搜索策略（另见第4.7.1节）：
RAP: Random Access Point (RAP) is the behavior of requesting the server to locate the closest previous random access point that exists in the media aggregate and deliver from that. By requesting a RAP, media quality will be the best possible as all media will be delivered from a point where full media state can be established in the media decoder.
RAP:Random Access Point（RAP）是请求服务器定位媒体聚合中最近的前一个随机访问点并从中传递的行为。通过请求RAP，媒体质量将尽可能最好，因为所有媒体都将从媒体解码器中可以建立完整媒体状态的点交付。
CoRAP: Conditional Random Access Point (CoRAP) is a variant of the above RAP behavior. This policy is primarily intended for cases where there is larger distance between the random access points in the media. CoRAP uses the RAP policy if the condition that there is a Random Access Point closer to the requested start point than to the current pause point is fulfilled. Otherwise, no seeking is performed and playback will continue from the current pause point. This policy assumes that the media state existing prior to the pause is usable if delivery is continued. If the client or server knows that this is not the fact, the RAP policy should be used. In other words, in most cases when the client requests a start point prior to the current pause point, a valid decoding dependency chain from the media delivered prior to the pause and to the requested media unit will not exist. If the server searched to a random access point, the server MUST return the CoRAP policy in the Seek-Style header and adjust the Range header to reflect the position of the selected RAP. In case the random access point is farther away and the server chooses to continue
CoRAP：条件随机接入点（CoRAP）是上述RAP行为的变体。此策略主要用于媒体中随机接入点之间存在较大距离的情况。如果满足以下条件，则CoRAP将使用RAP策略：随机访问点距离请求的起点比当前暂停点更近。否则，不执行搜索，将从当前暂停点继续播放。此策略假定，如果继续传送，则暂停之前存在的媒体状态可用。如果客户机或服务器知道事实并非如此，则应使用RAP策略。换句话说，在大多数情况下，当客户端在当前暂停点之前请求开始点时，从暂停之前交付的媒体到请求的媒体单元的有效解码依赖链将不存在。如果服务器搜索到随机访问点，则服务器必须在Seek Style标头中返回CoRAP策略，并调整Range标头以反映选定RAP的位置。如果随机访问点距离较远，服务器选择继续
from the current pause point, it MUST include the "Next" policy in the Seek-Style header and adjust the Range header start point to the current pause point.
从当前暂停点开始，它必须在Seek Style标头中包含“Next”（下一步）策略，并将范围标头起点调整为当前暂停点。
First-Prior: The first-prior policy will start delivery with the media unit that has a playout time first prior to the requested time. For discrete media, that would only include media units that would still be rendered at the request time. For continuous media, that is media that will be rendered during the requested start time of the range.
First Previor：First Previor策略将首先在请求时间之前具有播放时间的媒体单元开始交付。对于离散介质，这将仅包括仍将在请求时呈现的介质单元。对于连续介质，即将在范围的请求开始时间内渲染的介质。
Next: The next media units after the provided start time of the range: for continuous framed media, that would mean the first next frame after the provided time and for discrete media, the first unit that is to be rendered after the provided time. The main usage for this case is when the client knows it has all media up to a certain point and would like to continue delivery so that a complete uninterrupted media playback can be achieved. An example of such a scenario would be switching from a broadcast/multicast delivery to a unicast-based delivery. This policy MUST only be used on the client's explicit request.
下一个：范围内提供的开始时间之后的下一个媒体单元：对于连续帧媒体，这意味着在提供的时间之后的第一个下一帧，对于离散媒体，则意味着在提供的时间之后要渲染的第一个单元。这种情况的主要用途是当客户端知道它在某一点上拥有所有媒体，并希望继续交付，以便实现完全不间断的媒体播放。这种情况的一个例子是从广播/多播传送切换到基于单播的传送。此策略只能用于客户端的显式请求。
Please note that these expressed preferences exist for optimizing the startup time or the media quality. The "Next" policy breaks the normal definition of the Range header to enable a client to request media with minimal overlap, although some may still occur for aggregated sessions. RAP and First-Prior both fulfill the requirement of providing media from the requested range and forward. However, unless RAP is used, the media quality for many media codecs using predictive methods can be severely degraded unless additional data is available as, for example, already buffered, or through other side channels.
请注意，这些明确的首选项用于优化启动时间或介质质量。“下一步”策略打破了范围标头的正常定义，使客户机能够以最小的重叠请求媒体，尽管对于聚合会话仍然可能会出现一些重叠。RAP和First Previor都满足了从请求范围向前提供介质的要求。然而，除非使用RAP，否则使用预测方法的许多媒体编解码器的媒体质量可能会严重降低，除非额外的数据可用，例如，已经缓冲或通过其他侧信道。
The Server general-header field contains information about the software used by the origin server to create or handle the request. This field can contain multiple product tokens and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server general header字段包含有关源服务器用于创建或处理请求的软件的信息。此字段可以包含多个产品标记和注释，用于标识服务器和任何重要的子产品。产品标记按其对识别应用程序的重要性顺序列出。
Example:
例子：
Server: PhonyServer/1.0
服务器：PhonyServer/1.0
If the response is being forwarded through a proxy, the proxy application MUST NOT modify the Server response-header. Instead, it SHOULD include a Via field (Section 18.57). If the response is generated by the proxy, the proxy application MUST return the Server response-header as previously returned by the server.
如果通过代理转发响应，则代理应用程序不得修改服务器响应头。相反，它应该包括一个过孔字段（第18.57节）。如果响应由代理生成，则代理应用程序必须返回服务器先前返回的服务器响应头。
The Session general-header field identifies an RTSP session. An RTSP session is created by the server as a result of a successful SETUP request, and in the response, the session identifier is given to the client. The RTSP session exists until destroyed by a TEARDOWN or a REDIRECT or is timed out by the server.
会话常规标头字段标识RTSP会话。由于安装请求成功，服务器将创建一个RTSP会话，并在响应中向客户端提供会话标识符。RTSP会话一直存在，直到被拆除或重定向破坏，或者服务器超时。
The session identifier is chosen by the server (see Section 4.3) and MUST be returned in the SETUP response. Once a client receives a session identifier, it MUST be included in any request related to that session. This means that the Session header MUST be included in a request, using the following methods: PLAY, PAUSE, PLAY_NOTIFY and TEARDOWN. It MAY be included in SETUP, OPTIONS, SET_PARAMETER, GET_PARAMETER, and REDIRECT. It MUST NOT be included in DESCRIBE. The Session header MUST NOT be included in the following methods, if these requests are pipelined and if the session identifier is not yet known: PLAY, PAUSE, TEARDOWN, SETUP, OPTIONS SET_PARAMETER, and GET_PARAMETER.
会话标识符由服务器选择（参见第4.3节），必须在设置响应中返回。一旦客户机收到会话标识符，它必须包含在与该会话相关的任何请求中。这意味着必须使用以下方法将会话头包括在请求中：播放、暂停、播放通知和拆卸。它可能包含在设置、选项、设置参数、获取参数和重定向中。不得将其包含在描述中。如果这些请求是管道化的，并且会话标识符未知，则会话头不能包含在以下方法中：播放、暂停、拆卸、设置、选项设置参数和获取参数。
In an RTSP response, the session header MUST be included in methods, SETUP, PLAY, PAUSE, and PLAY_NOTIFY, and it MAY be included in methods TEARDOWN and REDIRECT. If included in the request of the following methods it MUST also be included in the response: OPTIONS, GET_PARAMETER, and SET_PARAMETER. It MUST NOT be included in DESCRIBE responses.
在RTSP响应中，会话头必须包含在方法、设置、播放、暂停和播放通知中，也可以包含在方法拆卸和重定向中。如果包含在以下方法的请求中，则还必须包含在响应中：选项、获取参数和设置参数。不得将其包含在描述响应中。
Note that a session identifier identifies an RTSP session across transport sessions or connections. RTSP requests for a given session can use different URIs (Presentation and media URIs). Note, that there are restrictions depending on the session as to which URIs are acceptable for a given method. However, multiple "user" sessions for the same URI from the same client will require use of different session identifiers.
请注意，会话标识符标识跨传输会话或连接的RTSP会话。给定会话的RTSP请求可以使用不同的URI（表示URI和媒体URI）。注意，对于给定的方法，哪些URI是可接受的，这取决于会话。但是，来自同一客户端的同一URI的多个“用户”会话将需要使用不同的会话标识符。
The session identifier is needed to distinguish several delivery requests for the same URI coming from the same client.
需要会话标识符来区分来自同一客户端的同一URI的多个传递请求。
The response 454 (Session Not Found) MUST be returned if the session identifier is invalid.
如果会话标识符无效，则必须返回响应454（未找到会话）。
The header MAY include a parameter for session timeout period. If not explicitly provided, this value is set to 60 seconds. As this affects how often session keep-alives are needed, values smaller than 30 seconds are not recommended. However, larger-than-default values can be useful in applications of RTSP that have inactive but established sessions for longer time periods.
报头可以包括会话超时时间的参数。如果未明确提供，此值将设置为60秒。由于这会影响需要会话保持有效的频率，因此不建议使用小于30秒的值。但是，大于默认值的值在RTSP应用程序中非常有用，这些应用程序具有较长时间段的非活动但已建立的会话。
The 60-second value was chosen as the session timeout value as it results in keep-alive messages that are not too frequent and low sensitivity to variations in request/response timing. If one reduces the timeout value to below 30 seconds, the corresponding request/response timeout becomes a significant part of the session timeout. The 60-second value also allows for reasonably rapid recovery of committed server resources in case of client failure.
选择60秒值作为会话超时值，因为它会导致保持活动状态的消息不太频繁，并且对请求/响应时间变化的敏感性较低。如果将超时值减少到30秒以下，则相应的请求/响应超时将成为会话超时的重要部分。60秒的值还允许在客户端出现故障时合理快速地恢复已提交的服务器资源。
The Speed general-header field requests the server to deliver specific amounts of nominal media time per unit of delivery time, contingent on the server's ability and desire to serve the media stream at the given speed. The client requests the delivery speed to be within a given range with a lower and upper bound. The server SHALL deliver at the highest possible speed within the range, but not faster than the upper bound, for which the underlying network path can support the resulting transport data rates. As long as any speed value within the given range can be provided, the server SHALL NOT modify the media quality. Only if the server is unable to deliver media at the speed value provided by the lower bound shall it reduce the media quality.
Speed general header字段请求服务器在每单位传递时间内传递特定数量的标称媒体时间，这取决于服务器以给定速度提供媒体流的能力和愿望。客户机要求交付速度在给定范围内，并具有下限和上限。服务器应在该范围内以尽可能高的速度交付数据，但速度不得超过上限，对于该上限，底层网络路径可支持产生的传输数据速率。只要能提供给定范围内的任何速度值，服务器不得修改媒体质量。只有当服务器无法以下限提供的速度值交付媒体时，才会降低媒体质量。
Implementation of the Speed functionality by the server is OPTIONAL. The server can indicate its support through a feature tag, play.speed. The lack of a Speed header in the response is an indication of lack of support of this functionality.
由服务器实现速度功能是可选的。服务器可以通过功能标签play.speed指示其支持。响应中缺少速度标题表示缺少对该功能的支持。
The speed parameter values are expressed as a positive decimal value, e.g., a value of 2.0 indicates that data is to be delivered twice as fast as normal. A speed value of zero is invalid. The range is specified in the form "lower bound - upper bound". The lower-bound value may be smaller or equal to the upper bound. All speeds may not be possible to support. Therefore, the server MAY modify the requested values to the closest supported. The actual supported speed MUST be included in the response. However, note that the use cases may vary and that Speed value ranges such as 0.7-0.8, 0.3-2.0, 1.0-2.5, and 2.5-2.5 all have their usages.
速度参数值表示为正十进制值，例如，值2.0表示数据传输速度为正常速度的两倍。速度值为零无效。范围以“下限-上限”的形式指定。下限值可以小于或等于上限。可能无法支持所有速度。因此，服务器可以将请求的值修改为最接近支持的值。响应中必须包括实际支持的速度。但是，请注意，用例可能会有所不同，速度值范围（如0.7-0.8、0.3-2.0、1.0-2.5和2.5-2.5）都有其用途。
Example:
例子：
Speed: 1.0-2.5
速度：1.0-2.5
Use of this header changes the bandwidth used for data delivery. It is meant for use in specific circumstances where delivery of the presentation at a higher or lower rate is desired. The main use cases are buffer operations or local scale operations. Implementers should keep in mind that bandwidth for the session may be negotiated beforehand (by means other than RTSP) and, therefore, renegotiation may be necessary. To perform Speed operations, the server needs to ensure that the network path can support the resulting bitrate. Thus, the media transport needs to support feedback so that the server can react and adapt to the available bitrate.
使用此标头会更改用于数据传输的带宽。它适用于需要以更高或更低的速率交付演示文稿的特定情况。主要用例是缓冲区操作或局部规模操作。实现者应该记住，会话的带宽可以事先协商（通过RTSP以外的方式），因此可能需要重新协商。要执行速度操作，服务器需要确保网络路径能够支持生成的比特率。因此，媒体传输需要支持反馈，以便服务器能够响应并适应可用比特率。
The Supported general-header enumerates all the extensions supported by the client or server using feature tags. The header carries the extensions supported by the message-sending client or server. The Supported header MAY be included in any request. When present in a request, the receiver MUST respond with its corresponding Supported header. Note that the Supported header is also included in 4xx and 5xx responses.
Supported general标头使用功能标记枚举客户端或服务器支持的所有扩展。标头包含消息发送客户端或服务器支持的扩展名。支持的标头可以包含在任何请求中。当存在于请求中时，接收方必须使用其相应的受支持标头进行响应。请注意，支持的标题也包含在4xx和5xx响应中。
The Supported header contains a list of feature tags, described in Section 4.5, that are understood by the client or server. These feature tags are the ones the server or client supports in general and are not specific to the request resource.
受支持的标题包含一个功能标签列表，如第4.5节所述，客户机或服务器可以理解这些标签。这些功能标签通常是服务器或客户端支持的，并不特定于请求资源。
Example:
例子：
C->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech
User-Agent: PhonyClient/1.2
C->S: OPTIONS rtsp://example.com/ RTSP/2.0
Supported: foo, bar, blech
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
Supported: bar, blech, baz
S->C: RTSP/2.0 200 OK
Supported: bar, blech, baz
The Terminate-Reason request-header allows the server, when sending a REDIRECT or TEARDOWN request, to provide a reason for the session termination and any additional information. This specification identifies three reasons for Redirections and may be extended in the future:
Terminate Reason请求头允许服务器在发送重定向或拆卸请求时提供会话终止的原因和任何其他信息。本规范确定了重定向的三个原因，并可能在将来扩展：
Server-Admin: The server needs to be shut down for some administrative reason.
服务器管理：由于某些管理原因，服务器需要关闭。
Session-Timeout: A client's session has been kept alive for extended periods of time and the server has determined that it needs to reclaim the resources associated with this session.
会话超时：客户端会话已保持活动状态很长一段时间，服务器已确定需要回收与此会话关联的资源。
Internal-Error An internal error that is impossible to recover from has occurred, forcing the server to terminate the session.
内部错误发生无法恢复的内部错误，迫使服务器终止会话。
The Server may provide additional parameters containing information around the redirect. This specification defines the following ones.
服务器可以提供包含重定向相关信息的附加参数。本规范定义了以下内容。
time: Provides a wallclock time when the server will stop providing any service.
时间：提供服务器停止提供任何服务时的挂钟时间。
user-msg: A UTF-8 text string with a message from the server to the user. This message SHOULD be displayed to the user.
user msg：一个UTF-8文本字符串，包含从服务器发送给用户的消息。应向用户显示此消息。
The Timestamp general-header describes when the agent sent the request. The value of the timestamp is of significance only to the agent and may use any timescale. The responding agent MUST echo the exact same value and MAY, if it has accurate information about this, add a floating-point number indicating the number of seconds that has elapsed since it has received the request. The timestamp can be used by the agent to compute the round-trip time to the responding agent so that it can adjust the timeout value for retransmissions when running over an unreliable protocol. It also resolves retransmission ambiguities for unreliable transport of RTSP.
Timestamp general标头描述代理何时发送请求。时间戳的值仅对代理有意义，可以使用任何时间刻度。响应代理必须回显完全相同的值，并且如果它有关于该值的准确信息，可以添加一个浮点数，指示自收到请求以来经过的秒数。代理可以使用时间戳计算到响应代理的往返时间，以便在运行不可靠的协议时调整重传的超时值。它还解决了RTSP不可靠传输的重传模糊问题。
Note that the present specification provides only for reliable transport of RTSP messages. The Timestamp general-header is specified in case the protocol is extended in the future to use unreliable transport.
请注意，本规范仅提供RTSP消息的可靠传输。时间戳通用报头是在协议将来扩展以使用不可靠传输时指定的。
The Transport general-header indicates which transport protocol is to be used and configures its parameters such as destination address, compression, multicast time-to-live and destination port for a single stream. It sets those values not already determined by a presentation description.
Transport general标头指示要使用哪个传输协议，并为单个流配置其参数，如目标地址、压缩、多播生存时间和目标端口。它设置那些尚未由演示文稿描述确定的值。
A Transport request-header MAY contain a list of transport options acceptable to the client, in the form of multiple transport specification entries. Transport specifications are comma separated and listed in decreasing order of preference. Each transport specification consists of a transport protocol identifier, followed by any number of parameters separated by semicolons. A Transport request-header MAY contain multiple transport specifications using the same transport protocol identifier. The server MUST return a Transport response-header in the response to indicate the values actually chosen, if any. If no transport specification is supported, no transport header is returned and the response MUST use the status code 461 (Unsupported Transport) (Section 17.4.25). In case more than one transport specification was present in the request, the server MUST return the single transport specification (transport-spec) that was actually chosen, if any. The number of transport-spec entries is expected to be limited as the client will receive guidance on what configurations are possible from the presentation description.
传输请求头可以包含客户端可接受的传输选项列表，其形式为多个传输规范条目。传输规范以逗号分隔，并按优先顺序递减列出。每个传输规范都包含一个传输协议标识符，后跟任意数量的参数，参数之间用分号分隔。传输请求报头可以包含使用相同传输协议标识符的多个传输规范。服务器必须在响应中返回传输响应头，以指示实际选择的值（如果有的话）。如果不支持传输规范，则不返回传输标头，响应必须使用状态代码461（不支持的传输）（第17.4.25节）。如果请求中存在多个传输规范，服务器必须返回实际选择的单个传输规范（传输规范），如果有的话。传输规范条目的数量预计将受到限制，因为客户将从演示文稿描述中获得关于可能的配置的指导。
The Transport header MAY also be used in subsequent SETUP requests to change transport parameters. A server MAY refuse to change parameters of an existing stream.
传输标头也可用于后续设置请求中，以更改传输参数。服务器可能拒绝更改现有流的参数。
The transport protocol identifier defines, for each transport specification, which transport protocol to use and any related rules. Each transport protocol identifier defines the parameters that are required to occur; additional optional parameters MAY occur. This flexibility is provided as parameters may be different and provide different options to the RTSP agent. A transport specification may only contain one of any given parameter within it. A parameter consists of a name and optionally a value string. Parameters MAY be given in any order. Additionally, a transport specification may only contain either the unicast or the multicast transport type parameter. The transport protocol identifier, and all parameters, need to be understood in a transport specification; if not, the transport specification MUST be ignored. An RTSP proxy of any type that uses or modifies the transport specification, e.g., access proxy or security proxy, MUST remove specifications with unknown parameters
传输协议标识符为每个传输规范定义要使用的传输协议和任何相关规则。每个传输协议标识符定义了需要出现的参数；可能会出现其他可选参数。提供这种灵活性是因为参数可能不同，并且为RTSP代理提供不同的选项。传输规范中只能包含一个给定参数。参数由名称和可选的值字符串组成。参数可以按任何顺序给出。此外，传输规范只能包含单播或多播传输类型参数。需要在传输规范中理解传输协议标识符和所有参数；否则，必须忽略运输规范。使用或修改传输规范（如访问代理或安全代理）的任何类型的RTSP代理必须删除具有未知参数的规范
before forwarding the RTSP message. If that results in no remaining transport specification, the proxy SHALL send a 461 (Unsupported Transport) (Section 17.4.25) response without any Transport header.
在转发RTSP消息之前。如果这导致没有剩余的传输规范，则代理应发送461（不支持的传输）（第17.4.25节）响应，而不发送任何传输头。
The Transport header is restricted to describing a single media stream. (RTSP can also control multiple streams as a single entity.) Making it part of RTSP rather than relying on a multitude of session description formats greatly simplifies designs of firewalls.
传输报头仅限于描述单个媒体流。（RTSP还可以作为一个实体控制多个流。）使其成为RTSP的一部分而不是依赖于多种会话描述格式大大简化了防火墙的设计。
The general syntax for the transport protocol identifier is a list of slash-separated tokens:
传输协议标识符的一般语法是斜杠分隔的令牌列表：
Value1/Value2/Value3...
值1/值2/值3。。。
Which, for RTP transports, takes the form:
对于RTP传输，其形式如下：
RTP/profile/lower-transport.
RTP/外形/下部运输。
The default value for the "lower-transport" parameters is specific to the profile. For RTP/AVP, the default is UDP.
“较低传输”参数的默认值特定于配置文件。对于RTP/AVP，默认为UDP。
There are two different methods for how to specify where the media should be delivered for unicast transport:
有两种不同的方法可以指定媒体应在何处进行单播传输：
dest_addr: The presence of this parameter and its values indicates the destination address or addresses (host address and port pairs for IP flows) necessary for the media transport.
dest_addr：此参数及其值表示媒体传输所需的一个或多个目标地址（IP流的主机地址和端口对）。
No dest_addr: The lack of the dest_addr parameter indicates that the server MUST send media to the same address from which the RTSP messages originates.
无dest_addr：缺少dest_addr参数表示服务器必须将媒体发送到RTSP消息来源的同一地址。
The choice of method for indicating where the media is to be delivered depends on the use case. In some cases, the only allowed method will be to use no explicit address indication and have the server deliver media to the source of the RTSP messages.
指示介质交付位置的方法的选择取决于用例。在某些情况下，唯一允许的方法是不使用显式地址指示，并让服务器将媒体传送到RTSP消息源。
For multicast, there are 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 need to be addressed because an RTSP server can be used as a DoS attacker on an existing multicast group.
dest_addr with client picked address：实际多播组将媒体传送到的地址和相关参数，如TTL（范围）。由于RTSP服务器可以用作现有多播组上的DoS攻击者，因此需要解决此方法的安全问题（第21节）。
dest_addr using Session Description Information: The information included in the transport header can all be coming from the session description, e.g., the SDP "c=" and "m=" lines. 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 MUST include the information if it is available in the session description.
dest_addr using Session Description Information：传输头中包含的信息都可以来自会话描述，例如，SDP“c=”和“m=”行。这减轻了以前方法的一些安全问题，因为是会话提供者选择多播组和范围。如果会话描述中有可用的信息，则客户端必须包含该信息。
No dest_addr: The behavior when no explicit multicast group is present in a request is not defined.
No dest_addr：未定义请求中不存在显式多播组时的行为。
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 destination indication.
RTSP代理需要注意。如果不希望介质通过代理路由，代理将需要引入目标指示。
Below are the configuration parameters associated with transport:
以下是与传输相关的配置参数：
General parameters:
一般参数：
unicast / multicast: This parameter is a mutually exclusive indication of whether unicast or multicast delivery will be attempted. One of the two values MUST be specified. Clients that are capable of handling both unicast and multicast transmission need to indicate such capability by including two full transport-specs with separate parameters for each.
单播/多播：此参数是一个互斥的指示，指示是否尝试单播或多播传递。必须指定两个值中的一个。能够处理单播和多播传输的客户端需要通过包含两个完整的传输规范（每个规范有单独的参数）来指示这种能力。
layers: The number of multicast layers to be used for this media stream. The layers are sent to consecutive addresses starting at the dest_addr address. If the parameter is not included, it defaults to a single layer.
layers：用于此媒体流的多播层数。层被发送到从dest_addr地址开始的连续地址。如果未包含该参数，则默认为单个图层。
dest_addr: A general destination address parameter that can contain one or more address specifications. Each combination of protocol/profile/lower transport needs to have the format and interpretation of its address specification defined. For RTP/AVP/UDP and RTP/AVP/TCP, the address specification is a tuple containing a host address and port. Note, only a single destination parameter per transport spec is intended. The usage of multiple destinations to distribute a single media to multiple entities is unspecified.
dest_addr：可以包含一个或多个地址规范的通用目标地址参数。协议/配置文件/较低传输的每个组合都需要定义其地址规范的格式和解释。对于RTP/AVP/UDP和RTP/AVP/TCP，地址规范是包含主机地址和端口的元组。注意，每个传输规范只需要一个目标参数。未指定使用多个目标将单个媒体分发给多个实体。
The client originating the RTSP request MAY specify the destination address of the stream recipient with the host address as part of the tuple. When the destination address is specified, the recipient may be a different party than the originator of the request. To avoid becoming the unwitting perpetrator of a remote-controlled DoS attack, a server MUST perform security checks (see Section 21.2.1) and SHOULD log
发起RTSP请求的客户端可以指定流接收方的目标地址，主机地址作为元组的一部分。指定目标地址时，收件人可能与请求的发起人不同。为避免成为远程控制的DoS攻击的无意实施者，服务器必须执行安全检查（见第21.2.1节），并应记录
such attempts before allowing the client to direct a media stream to a recipient address not chosen by the server. Implementations cannot rely on TCP as a reliable means of client identification. If the server does not allow the host address part of the tuple to be set, it MUST return 463 (Destination Prohibited).
在允许客户机将媒体流定向到服务器未选择的收件人地址之前，这种尝试。实现不能依赖TCP作为可靠的客户端标识手段。如果服务器不允许设置元组的主机地址部分，则必须返回463（目标禁止）。
The host address part of the tuple MAY be empty, for example ":58044", in cases when it is desired to specify only the destination port. Responses to requests 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 that is already present in the request when responding, unless the protocol requires it.
当需要仅指定目标端口时，元组的主机地址部分可以为空，例如“：58044”。对包含带有dest_addr参数的传输标头的请求的响应应包括服务器实际使用的完整目标地址。服务器在响应时不得删除请求中已存在的地址信息，除非协议需要。
src_addr: A general source address parameter that can contain one or more address specifications. Each combination of protocol/profile/lower transport needs to have the format and interpretation of its address specification defined. For RTP/AVP/UDP and RTP/AVP/TCP, the address specification is a tuple containing a host address and port.
src_addr：可以包含一个或多个地址规范的通用源地址参数。协议/配置文件/较低传输的每个组合都需要定义其地址规范的格式和解释。对于RTP/AVP/UDP和RTP/AVP/TCP，地址规范是包含主机地址和端口的元组。
This parameter MUST be specified by the server if it transmits media packets from an address other than the one RTSP messages are sent to. This will allow the client to verify the source address and give it a destination address for its RTCP feedback packets, if RTP is used. The address or addresses indicated in the src_addr parameter SHOULD be used both for the sending and receiving of the media stream's data packets. The main reasons are threefold: First, indicating the port and source address(s) lets the receiver know where from the packets is expected to originate. Second, traversal of NATs is greatly simplified when traffic is flowing symmetrically over a NAT binding. Third, certain NAT traversal mechanisms need to know to which address and port to send so-called "binding packets" from the receiver to the sender, thus creating an address binding in the NAT that the sender-to-receiver packet flow can use.
如果服务器从发送RTSP消息的地址以外的地址发送媒体数据包，则必须指定此参数。如果使用RTP，这将允许客户端验证源地址并为其RTCP反馈数据包提供目标地址。src_addr参数中指示的一个或多个地址应用于发送和接收媒体流的数据包。主要原因有三：首先，指示端口和源地址可以让接收方知道数据包的预期来源。其次，当流量在NAT绑定上对称流动时，NAT的遍历大大简化。第三，某些NAT遍历机制需要知道将所谓的“绑定数据包”从接收方发送到发送方的地址和端口，从而在NAT中创建发送方到接收方数据包流可以使用的地址绑定。
This information may also be available through SDP. However, since this is more a feature of transport than media initialization, the authoritative source for this information should be in the SETUP response.
此信息也可通过SDP获得。但是，由于这更多的是传输功能，而不是媒体初始化功能，因此此信息的权威来源应在设置响应中。
mode: The mode parameter indicates the methods to be supported for this session. The currently defined valid value is "PLAY". If not provided, the default is "PLAY". The "RECORD" value was defined in RFC 2326; in this specification, it is unspecified but reserved. RECORD and other values may be specified in the future.
模式：模式参数指示此会话支持的方法。当前定义的有效值为“播放”。如果未提供，则默认为“播放”。RFC 2326中定义了“记录”值；在本规范中，未指定但保留。将来可能会指定记录值和其他值。
interleaved: The interleaved parameter implies mixing the media stream with the control stream in whatever protocol is being used by the control stream, using the mechanism defined in Section 14. The argument provides the channel number to be used in the $ block (see Section 14) and MUST be present. This parameter MAY be specified as an interval, e.g., interleaved=4-5 in cases where the transport choice for the media stream requires it, e.g., for RTP with RTCP. The channel number given in the request is only a guidance from the client to the server on what channel number(s) to use. The server MAY set any valid channel number in the response. The declared channels are bidirectional, so both end parties MAY send data on the given channel. One example of such usage is the second channel used for RTCP, where both server and client send RTCP packets on the same channel.
交错：交错参数意味着使用第14节中定义的机制，以控制流正在使用的任何协议将媒体流与控制流混合。参数提供要在$block中使用的通道号（参见第14节），并且必须存在。该参数可以被指定为间隔，例如，在媒体流的传输选择需要它的情况下，例如，对于带有RTCP的RTP，交错=4-5。请求中给出的通道号只是从客户端到服务器关于使用哪个通道号的指导。服务器可以在响应中设置任何有效的通道号。声明的通道是双向的，因此双方都可以在给定通道上发送数据。这种用法的一个示例是用于RTCP的第二个通道，其中服务器和客户端都在同一通道上发送RTCP数据包。
This allows RTP/RTCP to be handled similarly to the way that it is done with UDP, i.e., one channel for RTP and the other for RTCP.
这使得RTP/RTCP的处理方式与UDP类似，即一个通道用于RTP，另一个通道用于RTCP。
MIKEY: This parameter is used in conjunction with transport specifications that can utilize MIKEY [RFC3830] for security context establishment. So far, only the SRTP-based RTP profiles SAVP and SAVPF can utilize MIKEY, and this is defined in Appendix C.1.4.1. This parameter can be included both in request and response messages. The binary MIKEY message SHALL be Base64-encoded [RFC4648] before being included in the value part of the parameter, where the encoding adheres to the definition in Section 4 of RFC 4648 and where the padding bits are set to zero.
MIKEY：此参数与传输规范一起使用，传输规范可以利用MIKEY[RFC3830]建立安全上下文。到目前为止，只有基于SRTP的RTP配置文件SAVP和SAVPF可以使用MIKEY，其定义见附录C.1.4.1。此参数可以包含在请求和响应消息中。二进制MIKEY消息在包含在参数的值部分之前应进行Base64编码[RFC4648]，其中编码符合RFC 4648第4节中的定义，并且填充位设置为零。
Multicast-specific:
特定于多播：
ttl: multicast time-to-live for IPv4. When included in requests, the value indicates the TTL value that the client requests the server to use. In a response, the value actually being used by the server is returned. A server will need to consider what values that are reasonable and also the authority of the user to set this value. Corresponding functions are not needed for IPv6 as the scoping is part of the IPv6 multicast address [RFC4291].
ttl:IPv4的多播生存时间。当包含在请求中时，该值指示客户端请求服务器使用的TTL值。在响应中，返回服务器实际使用的值。服务器需要考虑哪些是合理的值，以及用户设置该值的权限。IPv6不需要相应的功能，因为作用域是IPv6多播地址[RFC4291]的一部分。
RTP-specific:
RTP特定：
These parameters MAY only be used if the media-transport protocol is RTP.
仅当媒体传输协议为RTP时，才能使用这些参数。
ssrc: The ssrc parameter, if included in a SETUP response, indicates the RTP SSRC [RFC3550] value(s) that will be used by the media server for RTP packets within the stream. The values are expressed as a slash-separated sequence of SSRC values, each SSRC expressed as an eight-digit hexadecimal value.
ssrc：如果设置响应中包含ssrc参数，则表示媒体服务器将用于流中RTP数据包的RTP ssrc[RFC3550]值。这些值表示为以斜杠分隔的SSRC值序列，每个SSRC表示为八位十六进制值。
The ssrc parameter MUST NOT be specified in requests. The functionality of specifying the ssrc parameter in a SETUP request is deprecated as it is incompatible with the specification of RTP [RFC3550]. If the parameter is included in the Transport header of a SETUP request, the server SHOULD ignore it, and choose appropriate SSRCs for the stream. The server SHOULD set the ssrc parameter in the Transport header of the response.
不能在请求中指定ssrc参数。在设置请求中指定ssrc参数的功能不受欢迎，因为它与RTP[RFC3550]的规范不兼容。如果参数包含在安装请求的传输头中，服务器应忽略该参数，并为流选择适当的SSRC。服务器应在响应的传输头中设置ssrc参数。
RTCP-mux: Used to negotiate the usage of RTP and RTCP multiplexing [RFC5761] on a single underlying transport stream/flow. The presence of this parameter in a SETUP request indicates the client's support and requires the server to use RTP and RTCP multiplexing. The client SHALL only include one transport stream in the Transport header specification. To provide the server with a choice between using RTP/RTCP multiplexing or not, two different transport header specifications must be included.
RTCP mux：用于协商在单个底层传输流/流上使用RTP和RTCP多路复用[RFC5761]。设置请求中存在此参数表示客户端的支持，并要求服务器使用RTP和RTCP多路复用。客户应在传输头规范中仅包含一个传输流。为了让服务器在是否使用RTP/RTCP多路复用之间进行选择，必须包含两种不同的传输头规范。
The parameter setup and connection defined below MAY only be used if the media-transport protocol of the lower-level transport is connection oriented (such as TCP). However, these parameters MUST NOT be used when interleaving data over the RTSP connection.
仅当较低级别传输的媒体传输协议面向连接（如TCP）时，才能使用下面定义的参数设置和连接。但是，在RTSP连接上交错数据时，不得使用这些参数。
setup: Clients use the setup parameter on the Transport line in a SETUP request to indicate the roles it wishes to play in a TCP connection. This parameter is adapted from [RFC4145]. The use of this parameter in RTP/AVP/TCP non-interleaved transport is discussed in Appendix C.2.2; the discussion below is limited to syntactic issues. Clients may specify the following values for the setup parameter:
设置：客户端在设置请求中使用传输线上的设置参数来指示它希望在TCP连接中扮演的角色。此参数根据[RFC4145]进行调整。该参数在RTP/AVP/TCP非交织传输中的使用在附录C.2.2中讨论；下面的讨论仅限于句法问题。客户端可以为设置参数指定以下值：
active: The client will initiate an outgoing connection.
活动：客户端将启动传出连接。
passive: The client will accept an incoming connection.
被动：客户端将接受传入连接。
actpass: The client is willing to accept an incoming connection or to initiate an outgoing connection.
actpass：客户端愿意接受传入连接或启动传出连接。
If a client does not specify a setup value, the "active" value is assumed.
如果客户端未指定设置值，则假定为“活动”值。
In response to a client SETUP request where the setup parameter is set to "active", a server's 2xx reply MUST assign the setup parameter to "passive" on the Transport header line.
为了响应设置参数设置为“活动”的客户端设置请求，服务器的2xx回复必须在传输头行上将设置参数指定为“被动”。
In response to a client SETUP request where the setup parameter is set to "passive", a server's 2xx reply MUST assign the setup parameter to "active" on the Transport header line.
为了响应设置参数设置为“被动”的客户端设置请求，服务器的2xx回复必须在传输头行上将设置参数指定为“主动”。
In response to a client SETUP request where the setup parameter is set to "actpass", a server's 2xx reply MUST assign the setup parameter to "active" or "passive" on the Transport header line.
为响应设置参数设置为“actpass”的客户端设置请求，服务器的2xx回复必须在传输头行上将设置参数指定为“主动”或“被动”。
Note that the "holdconn" value for setup is not defined for RTSP use, and MUST NOT appear on a Transport line.
请注意，设置的“holdconn”值未定义为RTSP使用，且不得出现在传输线上。
connection: Clients use the connection parameter in a transport specification part of the Transport header in a SETUP request to indicate the client's preference for either reusing an existing connection between client and server (in which case the client sets the "connection" parameter to "existing") or requesting the creation of a new connection between client and server (in which cast the client sets the "connection" parameter to "new"). Typically, clients use the "new" value for the first SETUP request for a URL, and "existing" for subsequent SETUP requests for a URL.
连接：客户端在设置请求中使用传输头的传输规范部分中的连接参数来指示客户端是否愿意重用客户端和服务器之间的现有连接（在这种情况下，客户端将“连接”参数设置为“现有”）或者请求在客户机和服务器之间创建新连接（在该连接中，客户机将“connection”参数设置为“new”）。通常，客户端对URL的第一个设置请求使用“新”值，对URL的后续设置请求使用“现有”值。
If a client SETUP request assigns the "new" value to "connection", the server response MUST also assign the "new" value to "connection" on the Transport line.
如果客户端设置请求将“新”值分配给“连接”，则服务器响应还必须将“新”值分配给传输线上的“连接”。
If a client SETUP request assigns the "existing" value to "connection", the server response MUST assign a value of "existing" or "new" to "connection" on the Transport line, at its discretion.
如果客户端设置请求将“现有”值分配给“连接”，则服务器响应必须自行决定将“现有”或“新”值分配给传输线上的“连接”。
The default value of "connection" is "existing", for all SETUP requests (initial and subsequent).
对于所有设置请求（初始和后续），默认值“connection”为“existing”。
The combination of transport protocol, profile and lower transport needs to be defined. A number of combinations are defined in the Appendix C.
需要定义传输协议、配置文件和较低传输的组合。附录C中定义了许多组合。
Below is a usage example, showing a client advertising the capability to handle multicast or unicast, preferring multicast. Since this is a unicast-only stream, the server responds with the proper transport parameters for unicast.
下面是一个使用示例，显示了一个客户机，它宣传处理多播或单播的能力，更喜欢多播。由于这是一个仅单播的流，服务器将使用单播的适当传输参数进行响应。
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302
Transport: RTP/AVP;multicast;mode="PLAY",
RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";mode="PLAY"
Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302
Transport: RTP/AVP;multicast;mode="PLAY",
RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";mode="PLAY"
Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 302
Date: Fri, 20 Dec 2013 10:20:32 +0000
Session: rQi1hBrGlFdiYld241FxUO
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";src_addr="192.0.2.224:6256"/
"192.0.2.224:6257";mode="PLAY"
Accept-Ranges: npt
Media-Properties: Random-Access=0.6, Dynamic,
Time-Limited=20081128T165900
S->C: RTSP/2.0 200 OK
CSeq: 302
Date: Fri, 20 Dec 2013 10:20:32 +0000
Session: rQi1hBrGlFdiYld241FxUO
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";src_addr="192.0.2.224:6256"/
"192.0.2.224:6257";mode="PLAY"
Accept-Ranges: npt
Media-Properties: Random-Access=0.6, Dynamic,
Time-Limited=20081128T165900
The Unsupported response-header lists the features not supported by the responding RTSP agent. In the case where the feature was specified via the Proxy-Require field (Section 18.37), if there is a proxy on the path between the client and the server, the proxy MUST send a response message with a status code of 551 (Option Not Supported). The request MUST NOT be forwarded.
不支持的响应标头列出了响应RTSP代理不支持的功能。如果通过Proxy Require（代理要求）字段（第18.37节）指定了该功能，则如果客户端和服务器之间的路径上存在代理，则代理必须发送状态代码为551的响应消息（选项不受支持）。不得转发该请求。
See Section 18.43 for a usage example.
有关使用示例，请参见第18.43节。
The User-Agent general-header field contains information about the user agent originating the request or producing a response. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. The field can contain multiple product tokens and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application.
用户代理常规标头字段包含有关发起请求或生成响应的用户代理的信息。这是出于统计目的，跟踪协议冲突，以及自动识别用户代理，以便调整响应以避免特定的用户代理限制。用户代理应在请求中包含此字段。该字段可以包含多个产品标记和注释，标识代理和构成用户代理重要部分的任何子产品。按照惯例，产品标记按其识别应用程序的重要性顺序列出。
Example:
例子：
User-Agent: PhonyClient/1.2
用户代理：PhonyClient/1.2
The Via general-header field MUST be used by proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests and between the origin server and the client on responses. The field is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request/response chain.
代理必须使用Via general header字段来指示请求时用户代理和服务器之间以及响应时源服务器和客户端之间的中间协议和收件人。该字段用于跟踪消息转发，避免请求循环，并标识请求/响应链上所有发送方的协议功能。
Each of multiple values in the Via field represents each proxy that has forwarded the message. Each recipient MUST append its information such that the end result is ordered according to the sequence of forwarding applications. So messages originating with the client or server do not include the Via header. The first proxy or other intermediate adds the header and its information into the field. Any additional intermediate adds additional field-values. Resulting in the server seeing the chains of intermediates in a client-to-server request and the client seeing the full chain in the response message.
Via字段中的多个值中的每一个表示已转发消息的每个代理。每个收件人必须附加其信息，以便根据转发应用程序的顺序对最终结果进行排序。因此，来自客户端或服务器的消息不包括Via头。第一个代理或其他中间程序将标头及其信息添加到字段中。任何附加的中间值都会添加附加的字段值。导致服务器看到客户端到服务器请求中的中间链，客户端看到响应消息中的完整链。
Proxies (e.g., Access Proxy or Translator Proxy) SHOULD NOT, by default, forward the names and ports of hosts within the private/ protected region. This information SHOULD only be propagated if explicitly enabled. If not enabled, the via-received of any host behind the firewall/NAT SHOULD be replaced by an appropriate pseudonym for that host.
默认情况下，代理（例如，访问代理或转换器代理）不应转发专用/受保护区域内主机的名称和端口。仅当显式启用时，才应传播此信息。如果未启用，则防火墙/NAT后面的任何主机接收的via应替换为该主机的适当假名。
For organizations that have strong privacy requirements for hiding internal structures, a proxy MAY combine an ordered subsequence of Via header field entries with identical sent-protocol values into a single such entry. Applications MUST NOT combine entries that have different received-protocol values.
对于对隐藏内部结构有强烈隐私要求的组织，代理可以将具有相同发送协议值的Via头字段项的有序子序列组合到单个此类项中。应用程序不得组合具有不同接收协议值的条目。
The WWW-Authenticate header is specified in [RFC7235]; its usage depends on the used authentication schemes, such as Digest [RFC7616] and Basic [RFC7617]. The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field-value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. This header MUST only be used in response messages related to client to server requests.
WWW认证头在[RFC7235]中指定；它的使用取决于所使用的身份验证方案，例如摘要[RFC7616]和基本[RFC7617]。WWW Authenticate响应头字段必须包含在401（未经授权）响应消息中。字段值由至少一个质询组成，该质询指示认证方案和适用于请求URI的参数。此标头只能用于与客户端到服务器请求相关的响应消息。
The HTTP access authentication process is described in [RFC7235] with some clarification in Section 19.1. User agents are advised to take special care in parsing the WWW-Authenticate field-value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters.
[RFC7235]中描述了HTTP访问身份验证过程，第19.1节对此作了一些说明。建议用户代理在解析WWW Authenticate字段值时特别小心，因为它可能包含多个质询，或者如果提供了多个WWW Authenticate标头字段，质询本身的内容可以包含以逗号分隔的身份验证参数列表。
The RTSP security framework consists of two high-level components: the pure authentication mechanisms based on HTTP authentication and the message transport protection based on TLS, which is independent of RTSP. Because of the similarity in syntax and usage between RTSP servers and HTTP servers, the security for HTTP is reused to a large extent.
RTSP安全框架由两个高级组件组成：基于HTTP身份验证的纯身份验证机制和独立于RTSP的基于TLS的消息传输保护。由于RTSP服务器和HTTP服务器在语法和用法上的相似性，HTTP的安全性在很大程度上被重用。
RTSP and HTTP share common authentication schemes; thus, they follow the same framework as specified in [RFC7235]. RTSP uses the corresponding RTSP error codes (401 and 407) and headers (WWW-Authenticate, Authorization, Proxy-Authenticate, Proxy-Authorization) by importing the definitions from [RFC7235]. Servers SHOULD implement both the Basic [RFC7617] and the Digest [RFC7616] authentication schemes. Clients MUST implement both the Basic and the Digest authentication schemes so that a server that requires the client to authenticate can trust that the capability is present. If implementing the Digest authentication scheme, then the additional considerations specified below in Section 19.1.1 MUST be followed.
RTSP和HTTP共享公共认证方案；因此，它们遵循[RFC7235]中规定的相同框架。RTSP通过从[RFC7235]导入定义，使用相应的RTSP错误代码（401和407）和标头（WWW-Authenticate、Authorization、Proxy-Authenticate、Proxy-Authorization）。服务器应实现基本[RFC7617]和摘要[RFC7616]身份验证方案。客户端必须同时实现基本身份验证方案和摘要身份验证方案，以便要求客户端进行身份验证的服务器可以信任该功能的存在。如果实施摘要认证方案，则必须遵循以下第19.1.1节中规定的其他注意事项。
It should be stressed that using the HTTP authentication alone does not provide full RTSP message security. Therefore, TLS SHOULD be used; see Section 19.2. Any RTSP message containing an Authorization header using the Basic authentication scheme MUST be using a TLS connection with confidentiality protection enabled, i.e., no NULL encryption.
It should be stressed that using the HTTP authentication alone does not provide full RTSP message security. Therefore, TLS SHOULD be used; see Section 19.2. Any RTSP message containing an Authorization header using the Basic authentication scheme MUST be using a TLS connection with confidentiality protection enabled, i.e., no NULL encryption.translate error, please retry
In cases where there is a chain of proxies between the client and the server, each proxy may individually request the client or previous proxy to authenticate itself. This is done using the Proxy-Authenticate (Section 18.34), the Proxy-Authorization (Section 18.36), and the Proxy-Authentication-Info (Section 18.35) headers. These headers are hop-by-hop headers and are only scoped to the current connection and hop. Thus, if a proxy chain exists, a proxy connecting to another proxy will have to act as a client to authorize itself towards the next proxy. The WWW-Authenticate (Section 18.58), Authorization (Section 18.8), and Authentication-Info (Section 18.7) headers are end-to-end and MUST NOT be modified by proxies.
在客户机和服务器之间存在代理链的情况下，每个代理可以单独请求客户机或之前的代理进行自身身份验证。这是通过使用代理身份验证（第18.34节）、代理授权（第18.36节）和代理身份验证信息（第18.35节）头来完成的。这些标头是逐跃标头，仅限于当前连接和跃点。因此，如果存在代理链，则连接到另一个代理的代理必须充当客户机，以便向下一个代理授权自己。WWW-Authenticate（第18.58节）、Authentication（第18.8节）和Authentication-Info（第18.7节）头是端到端的，不能由代理修改。
This authentication mechanism works only for client-to-server requests as currently defined. This leaves server-to-client request outside of the context of TLS-based communication more vulnerable to message-injection attacks on the client. Based on the server-to-client methods that exist, the potential risks are various: hijacking (REDIRECT), denial of service (TEARDOWN and PLAY_NOTIFY), or attacks with uncertain results (SET_PARAMETER).
此身份验证机制仅适用于当前定义的客户端到服务器的请求。这使得基于TLS的通信上下文之外的服务器到客户端请求更容易受到客户端上的消息注入攻击。根据现有的服务器到客户端方法，潜在的风险是多种多样的：劫持（重定向）、拒绝服务（拆卸和播放通知）或结果不确定的攻击（设置参数）。
This section describes the modifications and clarifications required to apply the HTTP Digest authentication scheme to RTSP. The RTSP scheme usage is almost completely identical to that for HTTP [RFC7616]. These modifications are based on the procedures defined for SIP 2.0 [RFC3261] (in Section 22.4) but updated to use RFC 7235, RFC 7616 and RFC 7615 instead of RFC 2617.
本节描述了将HTTP摘要身份验证方案应用于RTSP所需的修改和澄清。RTSP方案的使用几乎与HTTP完全相同[RFC7616]。这些修改基于SIP 2.0[RFC3261]（第22.4节）中定义的程序，但已更新为使用RFC 7235、RFC 7616和RFC 7615而不是RFC 2617。
Digest authentication uses two additional headers, Authentication-Info and Proxy-Authentication-Info, that are defined as in [RFC7615]. The rules for Digest authentication follow those defined in [RFC7616], with "HTTP/1.1" replaced by "RTSP/2.0" in addition to the following differences:
摘要身份验证使用两个附加头，身份验证信息和代理身份验证信息，如[RFC7615]中所定义。摘要身份验证的规则遵循[RFC7616]中定义的规则，除以下区别外，“HTTP/1.1”替换为“RTSP/2.0”：
1. Use the ABNF specified in the referenced documents, with the difference that the URI parameter uses the request URI format for RTSP, i.e. the ABNF element: Request-URI (see Section 20.2.1). The domain parameter uses the RTSP-URI-Ref element for absolute and relative URIs.
1. 使用参考文档中指定的ABNF，不同之处在于URI参数使用RTSP的请求URI格式，即ABNF元素：请求URI（参见第20.2.1节）。domain参数将RTSP URI Ref元素用于绝对和相对URI。
2. If MTags are used, then the example procedure for choosing a nonce based on ETag can work, based on replacing the ETag with the MTag.
2. 如果使用了MTag，那么基于ETag选择nonce的示例过程可以工作，这是基于将ETag替换为MTag。
3. As a clarification to the calculation of the A2 value for message integrity assurance in the Digest authentication scheme, implementers should assume, when the entity-body is empty (that is, when the RTSP messages have no message body) that the hash of the message body resolves to the hash of an empty string, or: H(entity-body), example MD5("") = "d41d8cd98f00b204e9800998ecf8427e".
3. 作为对摘要身份验证方案中消息完整性保证A2值计算的澄清，实现者应假设，当实体正文为空时（即，当RTSP消息没有消息正文时），消息正文的哈希解析为空字符串的哈希，或：H（实体正文），示例MD5（“”=“d41d8cd98f00b204e9800998ecf8427e”。
RTSP agents MUST implement RTSP over TLS as defined in this section and the next Section 19.3. RTSP MUST follow the same guidelines with regard to TLS [RFC5246] usage as specified for HTTP; see [RFC2818]. RTSP over TLS is separated from unsecured RTSP both on the URI level and the port level. 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 is given in a URI with the "rtsps" scheme, port 322 MUST be used for TLS over TCP/IP.
RTSP代理必须按照本节和下一节19.3中的定义通过TLS实现RTSP。RTSP必须遵循HTTP规定的TLS[RFC5246]使用指南；见[RFC2818]。TLS上的RTSP在URI级别和端口级别上与不安全的RTSP分离。必须使用“rtsp”方案标识符通过TLS向rtsp发送信号，而不是在URI中使用“rtsp”方案标识符。如果在具有“rtsps”方案的URI中未提供任何端口，则端口322必须用于TCP/IP上的TLS。
When a client tries to set up an insecure channel to the server (using the "rtsp" URI), and the policy for the resource requires a secure channel, the server MUST redirect the client to the secure service by sending a 301 redirect response code together with the correct Location URI (using the "rtsps" scheme). A user or client MAY upgrade a non secured URI to a secured by changing the scheme from "rtsp" to "rtsps". A server implementing support for "rtsps" MUST allow this.
当客户端试图设置到服务器的不安全通道（使用“rtsp”URI），并且资源的策略需要安全通道时，服务器必须通过发送301重定向响应代码和正确的位置URI（使用“rtsps”方案），将客户端重定向到安全服务。用户或客户端可以通过将方案从“rtsp”更改为“rtsp”，将非安全URI升级为安全URI。实现对“RTSP”支持的服务器必须允许此操作。
It should be noted that TLS allows for mutual authentication (when using both server and client certificates). Still, one of the more common ways TLS is used is to provide only server-side authentication (often to avoid client certificates). TLS is then used in addition to HTTP authentication, providing transport security and server authentication, while HTTP Authentication is used to authenticate the client.
应该注意，TLS允许相互身份验证（同时使用服务器和客户端证书时）。不过，使用TLS的一种更常见的方法是只提供服务器端身份验证（通常是为了避免客户端证书）。然后，除了HTTP身份验证之外，还使用TLS，提供传输安全性和服务器身份验证，而HTTP身份验证用于对客户端进行身份验证。
RTSP includes the possibility to keep a TCP session up between the client and server, throughout the RTSP session lifetime. It may be convenient to keep the TCP session, not only to save the extra setup time for TCP, but also the extra setup time for TLS (even if TLS uses the resume function, there will be almost two extra round trips). Still, when TLS is used, such behavior introduces extra active state in the server, not only for TCP and RTSP, but also for TLS. This may increase the vulnerability to DoS attacks.
RTSP包括在RTSP会话生存期内保持客户端和服务器之间TCP会话的可能性。保持TCP会话可能很方便，不仅可以节省TCP的额外设置时间，还可以节省TLS的额外设置时间（即使TLS使用恢复功能，也会有几乎两个额外的往返）。但是，当使用TLS时，这种行为会在服务器中引入额外的活动状态，不仅对于TCP和RTSP，而且对于TLS。这可能会增加DoS攻击的脆弱性。
There exists a potential security vulnerability when reusing TCP and TLS state for different resources (URIs). If two different hostnames point at the same IP address, it can be desirable to reuse the TCP/ TLS connection to that server. In that case, the RTSP agent having the TCP/TLS connection MUST verify that the server certificate associated with the connection has a SubjectAltName matching the hostname present in the URI for the resource an RTSP request is to be issued.
在为不同的资源（URI）重用TCP和TLS状态时，存在潜在的安全漏洞。如果两个不同的主机名指向同一IP地址，则最好重用与该服务器的TCP/TLS连接。在这种情况下，具有TCP/TLS连接的RTSP代理必须验证与该连接关联的服务器证书是否具有与要发出RTSP请求的资源的URI中存在的主机名匹配的SubjectAltName。
In addition to these recommendations, Section 19.3 gives further recommendations of TLS usage with proxies.
除这些建议外，第19.3节给出了TLS与代理使用的进一步建议。
The nature of a proxy is often to act as a "man in the middle", while security is often about preventing the existence of one. This section provides clients with the possibility to use proxies even when applying secure transports (TLS) between the RTSP agents. The TLS proxy mechanism allows for server and proxy identification using certificates. However, the client cannot be identified based on certificates. The client needs to select between using the procedure specified below or using a TLS connection directly (bypassing any proxies) to the server. The choice may be dependent on policies.
代理人的性质通常是充当“中间人”，而安全性通常是防止中间人的存在。本节为客户端提供了使用代理的可能性，即使在RTSP代理之间应用安全传输（TLS）时也是如此。TLS代理机制允许使用证书识别服务器和代理。但是，无法根据证书识别客户端。客户端需要选择使用下面指定的过程还是直接（绕过任何代理）使用到服务器的TLS连接。选择可能取决于政策。
In general, there are two categories of proxies: the transparent proxies (of which the client is not aware) and the non-transparent proxies (of which the client is aware). This memo specifies only non-transparent RTSP proxies, i.e., proxies visible to the RTSP client and RTSP server. An infrastructure based on proxies requires that the trust model be such that both client and server can trust the proxies to handle the RTSP messages correctly. To be able to trust a proxy, the client and server also need to be aware of the proxy. Hence, transparent proxies cannot generally be seen as trusted and will not work well with security (unless they work only at the transport layer). In the rest of this section, any reference to "proxy" will be to a non-transparent proxy, which inspects or manipulates the RTSP messages.
通常，有两类代理：透明代理（客户端不知道）和非透明代理（客户端知道）。此备忘录仅指定不透明的RTSP代理，即RTSP客户端和RTSP服务器可见的代理。基于代理的基础设施要求信任模型能够使客户端和服务器都信任代理来正确处理RTSP消息。为了能够信任代理，客户机和服务器还需要知道代理。因此，透明代理通常不能被视为受信任的代理，并且不能很好地与安全性配合使用（除非它们仅在传输层工作）。在本节的其余部分中，对“代理”的任何引用都将指向一个不透明的代理，它检查或操纵RTSP消息。
HTTP Authentication is built on the assumption of proxies and can provide user-proxy authentication and proxy-proxy/server authentication in addition to the client-server authentication.
HTTP身份验证建立在代理的假设之上，除了客户机-服务器身份验证之外，还可以提供用户代理身份验证和代理/服务器身份验证。
When TLS is applied and a proxy is used, the client will connect to the proxy's address when connecting to any RTSP server. This implies that for TLS, the client will authenticate the proxy server and not the end server. Note that when the client checks the server
应用TLS并使用代理时，客户端将在连接到任何RTSP服务器时连接到代理的地址。这意味着对于TLS，客户端将对代理服务器而不是终端服务器进行身份验证。请注意，当客户端检查服务器时
certificate in TLS, it MUST check the proxy's identity (URI or possibly other known identity) against the proxy's identity as presented in the proxy's Certificate message.
证书在TLS中，它必须根据代理的证书消息中显示的代理的身份检查代理的身份（URI或可能的其他已知身份）。
The problem is that for a proxy accepted by the client, the proxy needs to be provided information on which grounds it should accept the next-hop certificate. Both the proxy and the user may have rules for this, and the user should have the possibility to select the desired behavior. To handle this case, the Accept-Credentials header (see Section 18.2) is used, where the client can request the proxy or proxies to relay back the chain of certificates used to authenticate any intermediate proxies as well as the server. The assumption that the proxies are viewed as trusted gives the user a possibility to enforce policies on each trusted proxy of whether it should accept the next agent in the chain. However, it should be noted that not all deployments will return the chain of certificates used to authenticate any intermediate proxies as well as the server. An operator of such a deployment may want to hide its topology from the client. It should be noted well that the client does not have any insight into the proxy's operation. Even if the proxy is trusted, it can still return an incomplete chain of certificates.
问题是，对于客户端接受的代理，需要向代理提供信息，说明它应该基于哪些理由接受下一跳证书。代理和用户都可能对此有规则，用户应该有可能选择所需的行为。为了处理这种情况，使用Accept Credentials标头（参见第18.2节），其中客户端可以请求一个或多个代理中继用于验证任何中间代理以及服务器的证书链。假设代理被视为可信的，则用户可以在每个可信代理上强制执行策略，以确定是否应接受链中的下一个代理。但是，应该注意的是，并非所有部署都将返回用于对任何中间代理以及服务器进行身份验证的证书链。此类部署的操作员可能希望对客户端隐藏其拓扑。应该注意的是，客户端对代理的操作没有任何洞察。即使代理是可信的，它仍然可以返回不完整的证书链。
A proxy MUST use TLS for the next hop if the RTSP request includes an "rtsps" URI. TLS MAY be applied on intermediate links (e.g., between client and proxy or between proxy and proxy) even if the resource and the end server are not required to use it. The chain of proxies used by a client to reach a server and its TLS sessions MUST have commensurate security. Therefore, a proxy MUST, when initiating the next-hop TLS connection, use the incoming TLS connections cipher-suite list, only modified by removing any cipher suites that the proxy does not support. In case a proxy fails to establish a TLS connection due to cipher-suite mismatch between proxy and next-hop proxy or server, this is indicated using error code 472 (Failure to Establish Secure Connection).
如果RTSP请求包含“rtsps”URI，则代理必须为下一跳使用TLS。TLS可应用于中间链路（例如，客户端和代理之间或代理和代理之间），即使资源和终端服务器不需要使用它。客户端用于访问服务器及其TLS会话的代理链必须具有相应的安全性。因此，在启动下一跳TLS连接时，代理必须使用传入TLS连接密码套件列表，仅通过删除代理不支持的任何密码套件进行修改。如果由于代理和下一跳代理或服务器之间的密码套件不匹配，代理无法建立TLS连接，则使用错误代码472（无法建立安全连接）表示。
The Accept-Credentials header can be used by the client to distribute simple authorization policies to intermediate proxies. The client includes the Accept-Credentials header to dictate how the proxy treats the server / next proxy certificate. There are currently three methods defined:
客户端可以使用Accept Credentials标头将简单授权策略分发给中间代理。客户端包含Accept Credentials标头，以指示代理如何处理服务器/下一个代理证书。目前定义了三种方法：
Any: With "any", the proxy (or proxies) MUST accept whatever certificate is presented. Of course, this is not a recommended option to use, but it may be useful in certain circumstances (such as testing).
Any：使用“Any”时，代理人必须接受提交的任何证书。当然，这不是推荐使用的选项，但在某些情况下（如测试）可能有用。
Proxy: For the "proxy" method, the proxy (or proxies) MUST use its own policies to validate the certificate and decide whether or not to accept it. This is convenient in cases where the user has a strong trust relation with the proxy. Reasons why a strong trust relation may exist are personal/company proxy or the proxy has an out-of-band policy configuration mechanism.
代理：对于“代理”方法，代理（或多个代理）必须使用自己的策略来验证证书，并决定是否接受证书。这在用户与代理有很强的信任关系的情况下很方便。可能存在强信任关系的原因是个人/公司代理或代理具有带外策略配置机制。
User: For the "user" method, the proxy (or proxies) MUST send credential information about the next hop to the client for authorization. The client can then decide whether or not the proxy should accept the certificate. See Section 19.3.2 for further details.
用户：对于“用户”方法，代理（或多个代理）必须将有关下一跳的凭据信息发送给客户端进行授权。然后，客户机可以决定代理是否应该接受证书。详见第19.3.2节。
If the Accept-Credentials header is not included in the RTSP request from the client, then the "Proxy" method MUST be used as default. If a method other than the "Proxy" is to be used, then the Accept-Credentials header MUST be included in all of the RTSP requests from the client. This is because it cannot be assumed that the proxy always keeps the TLS state or the user's previous preference between different RTSP messages (in particular, if the time interval between the messages is long).
如果客户端的RTSP请求中不包含Accept Credentials标头，则必须使用“Proxy”方法作为默认方法。如果要使用“代理”以外的方法，则必须在来自客户端的所有RTSP请求中包含Accept Credentials标头。这是因为不能假设代理在不同RTSP消息之间始终保持TLS状态或用户以前的首选项（特别是，如果消息之间的时间间隔较长）。
With the "Any" and "Proxy" methods, the proxy will apply the policy as defined for each method. If the policy does not accept the credentials of the next hop, the proxy MUST respond with a message using status code 471 (Connection Credentials Not Accepted).
对于“任意”和“代理”方法，代理将应用为每个方法定义的策略。如果策略不接受下一个跃点的凭据，则代理必须使用状态代码471（连接凭据未接受）响应消息。
An RTSP request in the direction server to client MUST NOT include the Accept-Credentials header. As for the non-secured communication, the possibility for these requests depends on the presence of a client established connection. However, if the server-to-client request is in relation to a session established over a TLS secured channel, it MUST be sent in a TLS secured connection. That secured connection MUST also be the one used by the last client-to-server request. If no such transport connection exists at the time when the server desires to send the request, the server MUST discard the message.
服务器到客户端方向中的RTSP请求不得包含Accept Credentials标头。至于非安全通信，这些请求的可能性取决于是否存在客户端建立的连接。但是，如果服务器到客户端的请求与通过TLS安全通道建立的会话有关，则必须在TLS安全连接中发送该请求。该安全连接还必须是上次客户端到服务器请求使用的连接。如果在服务器希望发送请求时不存在此类传输连接，则服务器必须放弃该消息。
Further policies MAY be defined and registered, but this should be done with caution.
可能会定义和注册进一步的策略，但应谨慎执行。
For the "User" method, each proxy MUST perform the following procedure for each RTSP request:
对于“用户”方法，每个代理必须对每个RTSP请求执行以下过程：
o Set up the TLS session to the next hop if not already present (i.e., run the TLS handshake, but do not send the RTSP request).
o 如果尚未存在，则将TLS会话设置为下一跳（即，运行TLS握手，但不发送RTSP请求）。
o Extract the peer certificate chain for the TLS session.
o 提取TLS会话的对等证书链。
o Check if a matching identity and hash of the peer certificate are present in the Accept-Credentials header. If present, send the message to the next hop and conclude these procedures. If not, go to the next step.
o 检查Accept Credentials标头中是否存在对等证书的匹配标识和哈希。如果存在，将消息发送到下一个跃点并完成这些过程。如果没有，请转至下一步。
o The proxy responds to the RTSP request with a 470 or 407 response code. The 407 response code MAY be used when the proxy requires both user and connection authorization from user or client. In this message the proxy MUST include a Connection-Credentials header, see Section 18.13, with the next hop's identity and certificate.
o 代理使用470或407响应代码响应RTSP请求。当代理需要用户或客户端的用户和连接授权时，可以使用407响应代码。在该消息中，代理必须包括连接凭据头（见第18.13节）以及下一个跃点的标识和证书。
The client MUST upon receiving a 470 (Connection Authorization Required) or 407 (Proxy Authentication Required) response with Connection-Credentials header take the decision on whether or not to accept the certificate (if it cannot do so, the user SHOULD be consulted). Using IP addresses in the next-hop URI and certificates rather than domain names makes it very difficult for a user to determine whether or not it should approve the next hop. Proxies are RECOMMENDED to use domain names to identify themselves in URIs and in the certificates. If the certificate is accepted, the client has to again send the RTSP request. In that request, the client has to include the Accept-Credentials header including the hash over the DER-encoded certificate for all trusted proxies in the chain.
客户机必须在收到带有Connection Credentials标头的470（需要连接授权）或407（需要代理身份验证）响应后决定是否接受证书（如果无法接受证书，应咨询用户）。在下一个跃点URI和证书中使用IP地址而不是域名，这使得用户很难确定是否应该批准下一个跃点。建议代理使用域名在URI和证书中标识自己。如果证书被接受，客户端必须再次发送RTSP请求。在该请求中，客户端必须包含Accept Credentials标头，其中包括链中所有受信任代理的DER编码证书上的哈希。
Example:
例子：
C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 2
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589"
Accept-Ranges: npt, smpte, clock
Accept-Credentials: User
C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 2
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589"
Accept-Ranges: npt, smpte, clock
Accept-Credentials: User
P->C: RTSP/2.0 470 Connection Authorization Required CSeq: 2 Connection-Credentials: "rtsps://test.example.org"; MIIDNTCCAp...
P->C:RTSP/2.0 470所需的连接授权CSeq:2连接凭据：rtsps://test.example.org"; MIIDNTCCAp。。。
C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 3
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589"
Accept-Credentials: User "rtsps://test.example.org";sha-256;
dPYD7txpoGTbAqZZQJ+vaeOkyH4=
Accept-Ranges: npt, smpte, clock
C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 3
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589"
Accept-Credentials: User "rtsps://test.example.org";sha-256;
dPYD7txpoGTbAqZZQJ+vaeOkyH4=
Accept-Ranges: npt, smpte, clock
P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 3
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589"
Via: RTSP/2.0 proxy.example.org
Accept-Credentials: User "rtsps://test.example.org";sha-256;
dPYD7txpoGTbAqZZQJ+vaeOkyH4=
Accept-Ranges: npt, smpte, clock
P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 3
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589"
Via: RTSP/2.0 proxy.example.org
Accept-Credentials: User "rtsps://test.example.org";sha-256;
dPYD7txpoGTbAqZZQJ+vaeOkyH4=
Accept-Ranges: npt, smpte, clock
One implication of this process is that the connection for secured RTSP messages may take significantly more round-trip times for the first message. A complete extra message exchange between the proxy connecting to the next hop and the client results because of the process for approval for each hop. However, if each message contains the chain of proxies that the requester accepts, the remaining message exchange should not be delayed. The procedure of including the credentials in each request rather than building state in each proxy avoids the need for revocation procedures.
此过程的一个含义是，安全RTSP消息的连接可能会占用第一条消息的更多往返时间。由于每个跃点的审批过程，连接到下一个跃点的代理和客户端之间会产生一个完整的额外消息交换。但是，如果每条消息包含请求者接受的代理链，则不应延迟剩余的消息交换。在每个请求中包含凭据而不是在每个代理中构建状态的过程避免了撤销过程的需要。
The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) as defined in RFC 5234 [RFC5234]. It uses the basic definitions present in RFC 5234.
RTSP语法以RFC 5234[RFC5234]中定义的扩充巴科斯诺尔形式（ABNF）描述。它使用RFC 5234中的基本定义。
Please note that ABNF strings, e.g., "Accept", are case insensitive as specified in Section 2.3 of RFC 5234.
请注意，根据RFC 5234第2.3节的规定，ABNF字符串（例如“Accept”）不区分大小写。
The RTSP syntax makes use of the ISO 10646 character set in UTF-8 encoding [RFC3629].
RTSP语法使用UTF-8编码[RFC3629]中的ISO10646字符集。
RTSP header values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear whitespace, including folding, has the same semantics as SP. A recipient MAY replace any linear whitespace with a single SP before interpreting the field-value or forwarding the message downstream. The SWS construct is used when linear whitespace is optional, generally between tokens and separators.
如果续行以空格或水平制表符开头，则RTSP标题值可以折叠到多行上。所有线性空格（包括折叠）的语义都与SP相同。收件人可以在解释字段值或将消息转发到下游之前，将任何线性空格替换为单个SP。当线性空白是可选的时，通常在标记和分隔符之间使用SWS构造。
To separate the header name from the rest of value, a colon is used, which, by the above rule, allows whitespace before, but no line break, and whitespace after, including a line break. The HCOLON defines this construct.
要将头名称与值的其余部分分开，需要使用冒号，根据上述规则，冒号允许在头名称之前使用空格，但不允许换行，允许在头名称之后使用空格，包括换行。HCOLON定义了这个构造。
OCTET = %x00-FF ; any 8-bit sequence of data
CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127)
UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z"
LOALPHA = %x61-7A ; any US-ASCII lowercase letter "a".."z"
ALPHA = UPALPHA / LOALPHA
DIGIT = %x30-39 ; any US-ASCII digit "0".."9"
CTL = %x00-1F / %x7F ; any US-ASCII control character
; (octets 0 - 31) and DEL (127)
CR = %x0D ; US-ASCII CR, carriage return (13)
LF = %x0A ; US-ASCII LF, linefeed (10)
SP = %x20 ; US-ASCII SP, space (32)
HT = %x09 ; US-ASCII HT, horizontal-tab (9)
BACKSLASH = %x5C ; US-ASCII backslash (92)
CRLF = CR LF
LWS = [CRLF] 1*( SP / HT ) ; Line-breaking whitespace
SWS = [LWS] ; Separating whitespace
HCOLON = *( SP / HT ) ":" SWS
TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs
tspecials = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / BACKSLASH / DQUOTE
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP / HT
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7A / %x7C / %x7E)
; 1*<any CHAR except CTLs or tspecials>
quoted-string = ( DQUOTE *qdtext DQUOTE )
OCTET = %x00-FF ; any 8-bit sequence of data
CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127)
UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z"
LOALPHA = %x61-7A ; any US-ASCII lowercase letter "a".."z"
ALPHA = UPALPHA / LOALPHA
DIGIT = %x30-39 ; any US-ASCII digit "0".."9"
CTL = %x00-1F / %x7F ; any US-ASCII control character
; (octets 0 - 31) and DEL (127)
CR = %x0D ; US-ASCII CR, carriage return (13)
LF = %x0A ; US-ASCII LF, linefeed (10)
SP = %x20 ; US-ASCII SP, space (32)
HT = %x09 ; US-ASCII HT, horizontal-tab (9)
BACKSLASH = %x5C ; US-ASCII backslash (92)
CRLF = CR LF
LWS = [CRLF] 1*( SP / HT ) ; Line-breaking whitespace
SWS = [LWS] ; Separating whitespace
HCOLON = *( SP / HT ) ":" SWS
TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs
tspecials = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / BACKSLASH / DQUOTE
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP / HT
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7A / %x7C / %x7E)
; 1*<any CHAR except CTLs or tspecials>
quoted-string = ( DQUOTE *qdtext DQUOTE )
qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair
/ UTF8-NONASCII
; No DQUOTE and no "\"
quoted-pair = "\\" / ( "\" DQUOTE )
ctext = %x20-27 / %x2A-7E
/ %x80-FF ; any OCTET except CTLs, "(" and ")"
generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string
qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair
/ UTF8-NONASCII
; No DQUOTE and no "\"
quoted-pair = "\\" / ( "\" DQUOTE )
ctext = %x20-27 / %x2A-7E
/ %x80-FF ; any OCTET except CTLs, "(" and ")"
generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string
safe = "$" / "-" / "_" / "." / "+"
extra = "!" / "*" / "'" / "(" / ")" / ","
rtsp-extra = "!" / "*" / "'" / "(" / ")"
safe = "$" / "-" / "_" / "." / "+"
extra = "!" / "*" / "'" / "(" / ")" / ","
rtsp-extra = "!" / "*" / "'" / "(" / ")"
HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
/ "a" / "b" / "c" / "d" / "e" / "f"
LHEX = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
; lowercase "a-f" Hex
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "="
HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
/ "a" / "b" / "c" / "d" / "e" / "f"
LHEX = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
; lowercase "a-f" Hex
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "="
unreserved = ALPHA / DIGIT / safe / extra
rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra
unreserved = ALPHA / DIGIT / safe / extra
rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra
base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = (2base64-char "==") / (3base64-char "=")
base64-char = ALPHA / DIGIT / "+" / "/"
SLASH = SWS "/" SWS ; slash
EQUAL = SWS "=" SWS ; equal
LPAREN = SWS "(" SWS ; left parenthesis
RPAREN = SWS ")" SWS ; right parenthesis
COMMA = SWS "," SWS ; comma
SEMI = SWS ";" SWS ; semicolon
COLON = SWS ":" SWS ; colon
MINUS = SWS "-" SWS ; minus/dash
LDQUOT = SWS DQUOTE ; open double quotation mark
RDQUOT = DQUOTE SWS ; close double quotation mark
RAQUOT = ">" SWS ; right angle quote
LAQUOT = SWS "<" ; left angle quote
base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = (2base64-char "==") / (3base64-char "=")
base64-char = ALPHA / DIGIT / "+" / "/"
SLASH = SWS "/" SWS ; slash
EQUAL = SWS "=" SWS ; equal
LPAREN = SWS "(" SWS ; left parenthesis
RPAREN = SWS ")" SWS ; right parenthesis
COMMA = SWS "," SWS ; comma
SEMI = SWS ";" SWS ; semicolon
COLON = SWS ":" SWS ; colon
MINUS = SWS "-" SWS ; minus/dash
LDQUOT = SWS DQUOTE ; open double quotation mark
RDQUOT = DQUOTE SWS ; close double quotation mark
RAQUOT = ">" SWS ; right angle quote
LAQUOT = SWS "<" ; left angle quote
TEXT-UTF8char = %x21-7E / UTF8-NONASCII
UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4
UTF8-1 = <As defined in RFC 3629>
UTF8-2 = <As defined in RFC 3629>
UTF8-3 = <As defined in RFC 3629>
UTF8-4 = <As defined in RFC 3629>
UTF8-tail = <As defined in RFC 3629>
TEXT-UTF8char = %x21-7E / UTF8-NONASCII
UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4
UTF8-1 = <As defined in RFC 3629>
UTF8-2 = <As defined in RFC 3629>
UTF8-3 = <As defined in RFC 3629>
UTF8-4 = <As defined in RFC 3629>
UTF8-tail = <As defined in RFC 3629>
POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT]
FLOAT = ["-"] POS-FLOAT
POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT]
FLOAT = ["-"] POS-FLOAT
RTSP-IRI = schemes ":" IRI-rest
IRI-rest = ihier-part [ "?" iquery ]
ihier-part = "//" iauthority ipath-abempty
RTSP-IRI-ref = RTSP-IRI / irelative-ref
irelative-ref = irelative-part [ "?" iquery ]
irelative-part = "//" iauthority ipath-abempty
/ ipath-absolute
/ ipath-noscheme
/ ipath-empty
RTSP-IRI = schemes ":" IRI-rest
IRI-rest = ihier-part [ "?" iquery ]
ihier-part = "//" iauthority ipath-abempty
RTSP-IRI-ref = RTSP-IRI / irelative-ref
irelative-ref = irelative-part [ "?" iquery ]
irelative-part = "//" iauthority ipath-abempty
/ ipath-absolute
/ ipath-noscheme
/ ipath-empty
iauthority = < As defined in RFC 3987>
ipath = ipath-abempty ; begins with "/" or is empty
/ ipath-absolute ; begins with "/" but not "//"
/ ipath-noscheme ; begins with a non-colon segment
/ ipath-rootless ; begins with a segment
/ ipath-empty ; zero characters
iauthority = < As defined in RFC 3987>
ipath = ipath-abempty ; begins with "/" or is empty
/ ipath-absolute ; begins with "/" but not "//"
/ ipath-noscheme ; begins with a non-colon segment
/ ipath-rootless ; begins with a segment
/ ipath-empty ; zero characters
ipath-abempty = *( "/" isegment )
ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ]
ipath-noscheme = isegment-nz-nc *( "/" isegment )
ipath-rootless = isegment-nz *( "/" isegment )
ipath-empty = 0<ipchar>
ipath-abempty = *( "/" isegment )
ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ]
ipath-noscheme = isegment-nz-nc *( "/" isegment )
ipath-rootless = isegment-nz *( "/" isegment )
ipath-empty = 0<ipchar>
isegment = *ipchar [";" *ipchar]
isegment-nz = 1*ipchar [";" *ipchar]
/ ";" *ipchar
isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc])
/ ";" *ipchar-nc
; non-zero-length segment without any colon ":"
; No parameter (; delimited) inside path.
isegment = *ipchar [";" *ipchar]
isegment-nz = 1*ipchar [";" *ipchar]
/ ";" *ipchar
isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc])
/ ";" *ipchar-nc
; non-zero-length segment without any colon ":"
; No parameter (; delimited) inside path.
ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@"
ipchar-nc = iunreserved / pct-encoded / sub-delims / "@"
; sub-delims is different from RFC 3987
; not including ";"
ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@"
ipchar-nc = iunreserved / pct-encoded / sub-delims / "@"
; sub-delims is different from RFC 3987
; not including ";"
iquery = < As defined in RFC 3987>
iunreserved = < As defined in RFC 3987>
pct-encoded = < As defined in RFC 3987>
iquery = < As defined in RFC 3987>
iunreserved = < As defined in RFC 3987>
pct-encoded = < As defined in RFC 3987>
RTSP-URI = schemes ":" URI-rest
RTSP-REQ-URI = schemes ":" URI-req-rest
RTSP-URI-Ref = RTSP-URI / RTSP-Relative
RTSP-REQ-Ref = RTSP-REQ-URI / RTSP-REQ-Rel
schemes = "rtsp" / "rtsps" / scheme
scheme = < As defined in RFC 3986>
URI-rest = hier-part [ "?" query ]
URI-req-rest = hier-part [ "?" query ]
; Note fragment part not allowed in requests
hier-part = "//" authority path-abempty
RTSP-URI = schemes ":" URI-rest
RTSP-REQ-URI = schemes ":" URI-req-rest
RTSP-URI-Ref = RTSP-URI / RTSP-Relative
RTSP-REQ-Ref = RTSP-REQ-URI / RTSP-REQ-Rel
schemes = "rtsp" / "rtsps" / scheme
scheme = < As defined in RFC 3986>
URI-rest = hier-part [ "?" query ]
URI-req-rest = hier-part [ "?" query ]
; Note fragment part not allowed in requests
hier-part = "//" authority path-abempty
RTSP-Relative = relative-part [ "?" query ]
RTSP-REQ-Rel = relative-part [ "?" query ]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
RTSP-Relative = relative-part [ "?" query ]
RTSP-REQ-Rel = relative-part [ "?" query ]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
authority = < As defined in RFC 3986>
query = < As defined in RFC 3986>
authority = < As defined in RFC 3986>
query = < As defined in RFC 3986>
path = path-abempty ; begins with "/" or is empty
/ path-absolute ; begins with "/" but not "//"
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters
path = path-abempty ; begins with "/" or is empty
/ path-absolute ; begins with "/" but not "//"
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0<pchar>
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0<pchar>
segment = *pchar [";" *pchar]
segment-nz = ( 1*pchar [";" *pchar]) / (";" *pchar)
segment-nz-nc = ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc)
; non-zero-length segment without any colon ":"
; No parameter (; delimited) inside path.
segment = *pchar [";" *pchar]
segment-nz = ( 1*pchar [";" *pchar]) / (";" *pchar)
segment-nz-nc = ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc)
; non-zero-length segment without any colon ":"
; No parameter (; delimited) inside path.
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
pchar-nc = unreserved / pct-encoded / sub-delims / "@"
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
pchar-nc = unreserved / pct-encoded / sub-delims / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / "="
; sub-delims is different from RFC 3986/3987
; not including ";"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / "="
; sub-delims is different from RFC 3986/3987
; not including ";"
smpte-range = smpte-type [EQUAL smpte-range-spec]
; See section 4.4
smpte-range-spec = ( smpte-time "-" [ smpte-time ] )
/ ( "-" smpte-time )
smpte-type = "smpte" / "smpte-30-drop"
/ "smpte-25" / smpte-type-extension
; other timecodes may be added
smpte-type-extension = "smpte" token
smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT
[ ":" 1*2DIGIT [ "." 1*2DIGIT ] ]
smpte-range = smpte-type [EQUAL smpte-range-spec]
; See section 4.4
smpte-range-spec = ( smpte-time "-" [ smpte-time ] )
/ ( "-" smpte-time )
smpte-type = "smpte" / "smpte-30-drop"
/ "smpte-25" / smpte-type-extension
; other timecodes may be added
smpte-type-extension = "smpte" token
smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT
[ ":" 1*2DIGIT [ "." 1*2DIGIT ] ]
npt-range = "npt" [EQUAL npt-range-spec]
npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time )
npt-time = "now" / npt-sec / npt-hhmmss / npt-hhmmss-comp
npt-sec = 1*19DIGIT [ "." 1*9DIGIT ]
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ]
npt-hh = 2*19DIGIT ; any positive number
npt-mm = 2*2DIGIT ; 0-59
npt-ss = 2*2DIGIT ; 0-59
npt-hhmmss-comp = npt-hh-comp ":" npt-mm-comp ":" npt-ss-comp
[ "." 1*9DIGIT ] ; Compatibility format
npt-hh-comp = 1*19DIGIT ; any positive number
npt-mm-comp = 1*2DIGIT ; 0-59
npt-ss-comp = 1*2DIGIT ; 0-59
npt-range = "npt" [EQUAL npt-range-spec]
npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time )
npt-time = "now" / npt-sec / npt-hhmmss / npt-hhmmss-comp
npt-sec = 1*19DIGIT [ "." 1*9DIGIT ]
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ]
npt-hh = 2*19DIGIT ; any positive number
npt-mm = 2*2DIGIT ; 0-59
npt-ss = 2*2DIGIT ; 0-59
npt-hhmmss-comp = npt-hh-comp ":" npt-mm-comp ":" npt-ss-comp
[ "." 1*9DIGIT ] ; Compatibility format
npt-hh-comp = 1*19DIGIT ; any positive number
npt-mm-comp = 1*2DIGIT ; 0-59
npt-ss-comp = 1*2DIGIT ; 0-59
utc-range = "clock" [EQUAL utc-range-spec]
utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time )
utc-time = utc-date "T" utc-clock "Z"
utc-date = 8DIGIT
utc-clock = 6DIGIT [ "." 1*9DIGIT ]
utc-range = "clock" [EQUAL utc-range-spec]
utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time )
utc-time = utc-date "T" utc-clock "Z"
utc-date = 8DIGIT
utc-clock = 6DIGIT [ "." 1*9DIGIT ]
feature-tag = token
feature-tag = token
session-id = 1*256( ALPHA / DIGIT / safe )
session-id = 1*256( ALPHA / DIGIT / safe )
extension-header = header-name HCOLON header-value
header-name = token
header-value = *(TEXT-UTF8char / LWS)
extension-header = header-name HCOLON header-value
header-name = token
header-value = *(TEXT-UTF8char / LWS)
RTSP-message = Request / Response ; RTSP/2.0 messages
RTSP-message = Request / Response ; RTSP/2.0 messages
Request = Request-Line *((general-header / request-header / message-body-header) CRLF) CRLF [ message-body-data ]
请求=请求行*（（一般标题/请求标题/消息正文标题）CRLF）CRLF[消息正文数据]
Response = Status-Line *((general-header / response-header / message-body-header) CRLF) CRLF [ message-body-data ]
响应=状态行*（（一般标题/响应标题/消息正文标题）CRLF）CRLF[消息正文数据]
Request-Line = Method SP Request-URI SP RTSP-Version CRLF
请求行=方法SP请求URI SP RTSP版本CRLF
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
状态行=RTSP版本SP状态代码SP原因短语CRLF
Method = "DESCRIBE"
/ "GET_PARAMETER"
/ "OPTIONS"
/ "PAUSE"
/ "PLAY"
/ "PLAY_NOTIFY"
/ "REDIRECT"
/ "SETUP"
/ "SET_PARAMETER"
/ "TEARDOWN"
/ extension-method
Method = "DESCRIBE"
/ "GET_PARAMETER"
/ "OPTIONS"
/ "PAUSE"
/ "PLAY"
/ "PLAY_NOTIFY"
/ "REDIRECT"
/ "SETUP"
/ "SET_PARAMETER"
/ "TEARDOWN"
/ extension-method
extension-method = token
extension-method = token
Request-URI = "*" / RTSP-REQ-URI
RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT
Request-URI = "*" / RTSP-REQ-URI
RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT
message-body-data = 1*OCTET
message-body-data = 1*OCTET
Status-Code = "100" ; Continue
/ "200" ; OK
/ "301" ; Moved Permanently
/ "302" ; Found
/ "303" ; See Other
/ "304" ; Not Modified
/ "305" ; Use Proxy
Status-Code = "100" ; Continue
/ "200" ; OK
/ "301" ; Moved Permanently
/ "302" ; Found
/ "303" ; See Other
/ "304" ; Not Modified
/ "305" ; Use Proxy
/ "400" ; Bad Request
/ "401" ; Unauthorized
/ "402" ; Payment Required
/ "403" ; Forbidden
/ "404" ; Not Found
/ "405" ; Method Not Allowed
/ "406" ; Not Acceptable
/ "407" ; Proxy Authentication Required
/ "408" ; Request Timeout
/ "410" ; Gone
/ "412" ; Precondition Failed
/ "413" ; Request Message Body Too Large
/ "414" ; Request-URI Too Long
/ "415" ; Unsupported Media Type
/ "451" ; Parameter Not Understood
/ "452" ; reserved
/ "453" ; Not Enough Bandwidth
/ "454" ; Session Not Found
/ "455" ; Method Not Valid In This State
/ "456" ; Header Field Not Valid for Resource
/ "457" ; Invalid Range
/ "458" ; Parameter Is Read-Only
/ "459" ; Aggregate Operation Not Allowed
/ "460" ; Only Aggregate Operation Allowed
/ "461" ; Unsupported Transport
/ "462" ; Destination Unreachable
/ "463" ; Destination Prohibited
/ "464" ; Data Transport Not Ready Yet
/ "465" ; Notification Reason Unknown
/ "466" ; Key Management Error
/ "470" ; Connection Authorization Required
/ "471" ; Connection Credentials Not Accepted
/ "472" ; Failure to Establish Secure Connection
/ "500" ; Internal Server Error
/ "501" ; Not Implemented
/ "502" ; Bad Gateway
/ "503" ; Service Unavailable
/ "504" ; Gateway Timeout
/ "505" ; RTSP Version Not Supported
/ "551" ; Option Not Supported
/ "553" ; Proxy Unavailable
/ extension-code
/ "400" ; Bad Request
/ "401" ; Unauthorized
/ "402" ; Payment Required
/ "403" ; Forbidden
/ "404" ; Not Found
/ "405" ; Method Not Allowed
/ "406" ; Not Acceptable
/ "407" ; Proxy Authentication Required
/ "408" ; Request Timeout
/ "410" ; Gone
/ "412" ; Precondition Failed
/ "413" ; Request Message Body Too Large
/ "414" ; Request-URI Too Long
/ "415" ; Unsupported Media Type
/ "451" ; Parameter Not Understood
/ "452" ; reserved
/ "453" ; Not Enough Bandwidth
/ "454" ; Session Not Found
/ "455" ; Method Not Valid In This State
/ "456" ; Header Field Not Valid for Resource
/ "457" ; Invalid Range
/ "458" ; Parameter Is Read-Only
/ "459" ; Aggregate Operation Not Allowed
/ "460" ; Only Aggregate Operation Allowed
/ "461" ; Unsupported Transport
/ "462" ; Destination Unreachable
/ "463" ; Destination Prohibited
/ "464" ; Data Transport Not Ready Yet
/ "465" ; Notification Reason Unknown
/ "466" ; Key Management Error
/ "470" ; Connection Authorization Required
/ "471" ; Connection Credentials Not Accepted
/ "472" ; Failure to Establish Secure Connection
/ "500" ; Internal Server Error
/ "501" ; Not Implemented
/ "502" ; Bad Gateway
/ "503" ; Service Unavailable
/ "504" ; Gateway Timeout
/ "505" ; RTSP Version Not Supported
/ "551" ; Option Not Supported
/ "553" ; Proxy Unavailable
/ extension-code
extension-code = 3DIGIT
extension-code = 3DIGIT
Reason-Phrase = 1*(TEXT-UTF8char / HT / SP)
Reason-Phrase = 1*(TEXT-UTF8char / HT / SP)
rtsp-header = general-header
/ request-header
/ response-header
/ message-body-header
rtsp-header = general-header
/ request-header
/ response-header
/ message-body-header
general-header = Accept-Ranges
/ Cache-Control
/ Connection
/ CSeq
/ Date
/ Media-Properties
/ Media-Range
/ Pipelined-Requests
/ Proxy-Supported
/ Range
/ RTP-Info
/ Scale
/ Seek-Style
/ Server
/ Session
/ Speed
/ Supported
/ Timestamp
/ Transport
/ User-Agent
/ Via
/ extension-header
general-header = Accept-Ranges
/ Cache-Control
/ Connection
/ CSeq
/ Date
/ Media-Properties
/ Media-Range
/ Pipelined-Requests
/ Proxy-Supported
/ Range
/ RTP-Info
/ Scale
/ Seek-Style
/ Server
/ Session
/ Speed
/ Supported
/ Timestamp
/ Transport
/ User-Agent
/ Via
/ extension-header
request-header = Accept
/ Accept-Credentials
/ Accept-Encoding
/ Accept-Language
/ Authorization
/ Bandwidth
/ Blocksize
/ From
/ If-Match
/ If-Modified-Since
/ If-None-Match
/ Notify-Reason
/ Proxy-Authorization
/ Proxy-Require
/ Referrer
/ Request-Status
/ Require
/ Terminate-Reason
/ extension-header
request-header = Accept
/ Accept-Credentials
/ Accept-Encoding
/ Accept-Language
/ Authorization
/ Bandwidth
/ Blocksize
/ From
/ If-Match
/ If-Modified-Since
/ If-None-Match
/ Notify-Reason
/ Proxy-Authorization
/ Proxy-Require
/ Referrer
/ Request-Status
/ Require
/ Terminate-Reason
/ extension-header
response-header = Authentication-Info
/ Connection-Credentials
/ Location
/ MTag
/ Proxy-Authenticate
/ Proxy-Authentication-Info
/ Public
/ Retry-After
/ Unsupported
/ WWW-Authenticate
/ extension-header
response-header = Authentication-Info
/ Connection-Credentials
/ Location
/ MTag
/ Proxy-Authenticate
/ Proxy-Authentication-Info
/ Public
/ Retry-After
/ Unsupported
/ WWW-Authenticate
/ extension-header
message-body-header = Allow
/ Content-Base
/ Content-Encoding
/ Content-Language
/ Content-Length
/ Content-Location
/ Content-Type
/ Expires
/ Last-Modified
/ extension-header
message-body-header = Allow
/ Content-Base
/ Content-Encoding
/ Content-Language
/ Content-Length
/ Content-Location
/ Content-Type
/ Expires
/ Last-Modified
/ extension-header
Accept = "Accept" HCOLON
[ accept-range *(COMMA accept-range) ]
accept-range = media-type-range [SEMI accept-params]
media-type-range = ( "*/*"
/ ( m-type SLASH "*" )
/ ( m-type SLASH m-subtype )
) *( SEMI m-parameter )
accept-params = "q" EQUAL qvalue *(SEMI generic-param )
qvalue = ( "0" [ "." *3DIGIT ] )
/ ( "1" [ "." *3("0") ] )
Accept-Credentials = "Accept-Credentials" HCOLON cred-decision
cred-decision = ("User" [LWS cred-info])
/ "Proxy"
/ "Any"
/ (token [LWS 1*header-value])
; For future extensions
cred-info = cred-info-data *(COMMA cred-info-data)
Accept = "Accept" HCOLON
[ accept-range *(COMMA accept-range) ]
accept-range = media-type-range [SEMI accept-params]
media-type-range = ( "*/*"
/ ( m-type SLASH "*" )
/ ( m-type SLASH m-subtype )
) *( SEMI m-parameter )
accept-params = "q" EQUAL qvalue *(SEMI generic-param )
qvalue = ( "0" [ "." *3DIGIT ] )
/ ( "1" [ "." *3("0") ] )
Accept-Credentials = "Accept-Credentials" HCOLON cred-decision
cred-decision = ("User" [LWS cred-info])
/ "Proxy"
/ "Any"
/ (token [LWS 1*header-value])
; For future extensions
cred-info = cred-info-data *(COMMA cred-info-data)
cred-info-data = DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg SEMI base64 hash-alg = "sha-256" / extension-alg extension-alg = token Accept-Encoding = "Accept-Encoding" HCOLON
cred info data=DQUOTE RTSP-REQ-URI DQUOTE SEMI-hash alg SEMI-base64 hash alg=“sha-256”/extension alg extension alg=token Accept Encoding=“Accept Encoding”HCOLON
[ encoding *(COMMA encoding) ]
encoding = codings [SEMI accept-params]
codings = content-coding / "*"
content-coding = "identity" / token
Accept-Language = "Accept-Language" HCOLON
language *(COMMA language)
language = language-range [SEMI accept-params]
language-range = language-tag / "*"
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges
acceptable-ranges = (range-unit *(COMMA range-unit))
range-unit = "npt" / "smpte" / "smpte-30-drop" / "smpte-25"
/ "clock" / extension-format
extension-format = token
Allow = "Allow" HCOLON Method *(COMMA Method)
Authentication-Info = "Authentication-Info" HCOLON auth-param-list
auth-param-list = <As the Authentication-Info element in RFC 7615>
Authorization = "Authorization" HCOLON credentials
credentials = <As defined by RFC 7235>
[ encoding *(COMMA encoding) ]
encoding = codings [SEMI accept-params]
codings = content-coding / "*"
content-coding = "identity" / token
Accept-Language = "Accept-Language" HCOLON
language *(COMMA language)
language = language-range [SEMI accept-params]
language-range = language-tag / "*"
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges
acceptable-ranges = (range-unit *(COMMA range-unit))
range-unit = "npt" / "smpte" / "smpte-30-drop" / "smpte-25"
/ "clock" / extension-format
extension-format = token
Allow = "Allow" HCOLON Method *(COMMA Method)
Authentication-Info = "Authentication-Info" HCOLON auth-param-list
auth-param-list = <As the Authentication-Info element in RFC 7615>
Authorization = "Authorization" HCOLON credentials
credentials = <As defined by RFC 7235>
Bandwidth = "Bandwidth" HCOLON 1*19DIGIT
带宽=“带宽”HCOLON 1*19位
Blocksize = "Blocksize" HCOLON 1*9DIGIT
Blocksize=“Blocksize”HCOLON 1*9位
Cache-Control = "Cache-Control" HCOLON cache-directive *(COMMA cache-directive) cache-directive = cache-rqst-directive / cache-rspns-directive
Cache Control=“Cache Control”HCOLON缓存指令*（逗号缓存指令）缓存指令=缓存rqst指令/缓存rspns指令
cache-rqst-directive = "no-cache"
/ "max-stale" [EQUAL delta-seconds]
/ "min-fresh" EQUAL delta-seconds
/ "only-if-cached"
/ cache-extension
cache-rqst-directive = "no-cache"
/ "max-stale" [EQUAL delta-seconds]
/ "min-fresh" EQUAL delta-seconds
/ "only-if-cached"
/ cache-extension
cache-rspns-directive = "public"
/ "private"
/ "no-cache"
/ "no-transform"
/ "must-revalidate"
/ "proxy-revalidate"
/ "max-age" EQUAL delta-seconds
/ cache-extension
cache-rspns-directive = "public"
/ "private"
/ "no-cache"
/ "no-transform"
/ "must-revalidate"
/ "proxy-revalidate"
/ "max-age" EQUAL delta-seconds
/ cache-extension
cache-extension = token [EQUAL (token / quoted-string)]
delta-seconds = 1*19DIGIT
cache-extension = token [EQUAL (token / quoted-string)]
delta-seconds = 1*19DIGIT
Connection = "Connection" HCOLON connection-token *(COMMA connection-token) connection-token = "close" / token
Connection=“Connection”HCOLON连接令牌*（逗号连接令牌）Connection token=“close”/token
Connection-Credentials = "Connection-Credentials" HCOLON cred-chain cred-chain = DQUOTE RTSP-REQ-URI DQUOTE SEMI base64
Connection Credentials=“Connection Credentials”HCOLON cred chain cred chain=DQUOTE RTSP-REQ-URI DQUOTE SEMI base64
Content-Base = "Content-Base" HCOLON RTSP-URI
Content-Encoding = "Content-Encoding" HCOLON
content-coding *(COMMA content-coding)
Content-Language = "Content-Language" HCOLON
language-tag *(COMMA language-tag)
Content-Length = "Content-Length" HCOLON 1*19DIGIT
Content-Location = "Content-Location" HCOLON RTSP-REQ-Ref
Content-Type = "Content-Type" HCOLON media-type
media-type = m-type SLASH m-subtype *(SEMI m-parameter)
m-type = discrete-type / composite-type
discrete-type = "text" / "image" / "audio" / "video"
/ "application" / extension-token
composite-type = "message" / "multipart" / extension-token
extension-token = ietf-token / x-token
ietf-token = token
x-token = "x-" token
m-subtype = extension-token / iana-token
iana-token = token
m-parameter = m-attribute EQUAL m-value
m-attribute = token
m-value = token / quoted-string
Content-Base = "Content-Base" HCOLON RTSP-URI
Content-Encoding = "Content-Encoding" HCOLON
content-coding *(COMMA content-coding)
Content-Language = "Content-Language" HCOLON
language-tag *(COMMA language-tag)
Content-Length = "Content-Length" HCOLON 1*19DIGIT
Content-Location = "Content-Location" HCOLON RTSP-REQ-Ref
Content-Type = "Content-Type" HCOLON media-type
media-type = m-type SLASH m-subtype *(SEMI m-parameter)
m-type = discrete-type / composite-type
discrete-type = "text" / "image" / "audio" / "video"
/ "application" / extension-token
composite-type = "message" / "multipart" / extension-token
extension-token = ietf-token / x-token
ietf-token = token
x-token = "x-" token
m-subtype = extension-token / iana-token
iana-token = token
m-parameter = m-attribute EQUAL m-value
m-attribute = token
m-value = token / quoted-string
CSeq = "CSeq" HCOLON cseq-nr
cseq-nr = 1*9DIGIT
Date = "Date" HCOLON RTSP-date
RTSP-date = date-time ;
date-time = <As defined in RFC 5322>
Expires = "Expires" HCOLON RTSP-date
From = "From" HCOLON from-spec
from-spec = ( name-addr / addr-spec ) *( SEMI from-param )
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = RTSP-REQ-URI / absolute-URI
absolute-URI = < As defined in RFC 3986>
display-name = *(token LWS) / quoted-string
from-param = tag-param / generic-param
tag-param = "tag" EQUAL token
If-Match = "If-Match" HCOLON ("*" / message-tag-list)
message-tag-list = message-tag *(COMMA message-tag)
message-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
CSeq = "CSeq" HCOLON cseq-nr
cseq-nr = 1*9DIGIT
Date = "Date" HCOLON RTSP-date
RTSP-date = date-time ;
date-time = <As defined in RFC 5322>
Expires = "Expires" HCOLON RTSP-date
From = "From" HCOLON from-spec
from-spec = ( name-addr / addr-spec ) *( SEMI from-param )
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = RTSP-REQ-URI / absolute-URI
absolute-URI = < As defined in RFC 3986>
display-name = *(token LWS) / quoted-string
from-param = tag-param / generic-param
tag-param = "tag" EQUAL token
If-Match = "If-Match" HCOLON ("*" / message-tag-list)
message-tag-list = message-tag *(COMMA message-tag)
message-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string
If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date
If-None-Match = "If-None-Match" HCOLON ("*" / message-tag-list)
Last-Modified = "Last-Modified" HCOLON RTSP-date
Location = "Location" HCOLON RTSP-REQ-URI
Media-Properties = "Media-Properties" HCOLON [media-prop-list]
media-prop-list = media-prop-value *(COMMA media-prop-value)
media-prop-value = ("Random-Access" [EQUAL POS-FLOAT])
/ "Beginning-Only"
/ "No-Seeking"
/ "Immutable"
/ "Dynamic"
/ "Time-Progressing"
/ "Unlimited"
/ ("Time-Limited" EQUAL utc-time)
/ ("Time-Duration" EQUAL POS-FLOAT)
/ ("Scales" EQUAL scale-value-list)
/ media-prop-ext
media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)]
scale-value-list = DQUOTE scale-entry *(COMMA scale-entry) DQUOTE
scale-entry = scale-value / (scale-value COLON scale-value)
scale-value = FLOAT
Media-Range = "Media-Range" HCOLON [ranges-list]
ranges-list = ranges-spec *(COMMA ranges-spec)
MTag = "MTag" HCOLON message-tag
Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val
Notify-Reas-val = "end-of-stream"
/ "media-properties-update"
/ "scale-change"
/ Notify-Reason-extension
Notify-Reason-extension = token
Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id
startup-id = 1*8DIGIT
If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date
If-None-Match = "If-None-Match" HCOLON ("*" / message-tag-list)
Last-Modified = "Last-Modified" HCOLON RTSP-date
Location = "Location" HCOLON RTSP-REQ-URI
Media-Properties = "Media-Properties" HCOLON [media-prop-list]
media-prop-list = media-prop-value *(COMMA media-prop-value)
media-prop-value = ("Random-Access" [EQUAL POS-FLOAT])
/ "Beginning-Only"
/ "No-Seeking"
/ "Immutable"
/ "Dynamic"
/ "Time-Progressing"
/ "Unlimited"
/ ("Time-Limited" EQUAL utc-time)
/ ("Time-Duration" EQUAL POS-FLOAT)
/ ("Scales" EQUAL scale-value-list)
/ media-prop-ext
media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)]
scale-value-list = DQUOTE scale-entry *(COMMA scale-entry) DQUOTE
scale-entry = scale-value / (scale-value COLON scale-value)
scale-value = FLOAT
Media-Range = "Media-Range" HCOLON [ranges-list]
ranges-list = ranges-spec *(COMMA ranges-spec)
MTag = "MTag" HCOLON message-tag
Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val
Notify-Reas-val = "end-of-stream"
/ "media-properties-update"
/ "scale-change"
/ Notify-Reason-extension
Notify-Reason-extension = token
Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id
startup-id = 1*8DIGIT
Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list
challenge-list = <As defined by the WWW-Authenticate in RFC 7235>
Proxy-Authentication-Info = "Proxy-Authentication-Info" HCOLON
auth-param-list
Proxy-Authorization = "Proxy-Authorization" HCOLON credentials
Proxy-Require = "Proxy-Require" HCOLON feature-tag-list
feature-tag-list = feature-tag *(COMMA feature-tag)
Proxy-Supported = "Proxy-Supported" HCOLON [feature-tag-list]
Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list
challenge-list = <As defined by the WWW-Authenticate in RFC 7235>
Proxy-Authentication-Info = "Proxy-Authentication-Info" HCOLON
auth-param-list
Proxy-Authorization = "Proxy-Authorization" HCOLON credentials
Proxy-Require = "Proxy-Require" HCOLON feature-tag-list
feature-tag-list = feature-tag *(COMMA feature-tag)
Proxy-Supported = "Proxy-Supported" HCOLON [feature-tag-list]
Public = "Public" HCOLON Method *(COMMA Method)
Public=“Public”HCOLON方法*（逗号方法）
Range = "Range" HCOLON ranges-spec
Range=“Range”HCOLON范围规范
ranges-spec = npt-range / utc-range / smpte-range
/ range-ext
ranges-spec = npt-range / utc-range / smpte-range
/ range-ext
range-ext = extension-format [EQUAL range-value]
range-value = 1*(rtsp-unreserved / quoted-string / ":" )
range-ext = extension-format [EQUAL range-value]
range-value = 1*(rtsp-unreserved / quoted-string / ":" )
Referrer = "Referrer" HCOLON (absolute-URI / RTSP-URI-Ref) Request-Status = "Request-Status" HCOLON req-status-info req-status-info = cseq-info LWS status-info LWS reason-info cseq-info = "cseq" EQUAL cseq-nr status-info = "status" EQUAL Status-Code reason-info = "reason" EQUAL DQUOTE Reason-Phrase DQUOTE Require = "Require" HCOLON feature-tag-list
referer=“referer”HCOLON（绝对URI/RTSP URI Ref）请求状态=“请求状态”HCOLON请求状态信息请求状态信息=cseq信息LWS状态信息LWS原因信息cseq信息cseq信息cseq nr状态信息=“状态”等状态代码原因信息=“原因”等DQUOTE原因短语DQUOTE REQUOTE=“要求”HCOLON功能标记列表
RTP-Info = "RTP-Info" HCOLON [rtsp-info-spec
*(COMMA rtsp-info-spec)]
rtsp-info-spec = stream-url 1*ssrc-parameter
stream-url = "url" EQUAL DQUOTE RTSP-REQ-Ref DQUOTE
ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON
ri-parameter *(SEMI ri-parameter)
ri-parameter = ("seq" EQUAL 1*5DIGIT)
/ ("rtptime" EQUAL 1*10DIGIT)
/ generic-param
RTP-Info = "RTP-Info" HCOLON [rtsp-info-spec
*(COMMA rtsp-info-spec)]
rtsp-info-spec = stream-url 1*ssrc-parameter
stream-url = "url" EQUAL DQUOTE RTSP-REQ-Ref DQUOTE
ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON
ri-parameter *(SEMI ri-parameter)
ri-parameter = ("seq" EQUAL 1*5DIGIT)
/ ("rtptime" EQUAL 1*10DIGIT)
/ generic-param
Retry-After = "Retry-After" HCOLON (RTSP-date / delta-seconds)
Scale = "Scale" HCOLON scale-value
Seek-Style = "Seek-Style" HCOLON Seek-S-values
Seek-S-values = "RAP"
/ "CoRAP"
/ "First-Prior"
/ "Next"
/ Seek-S-value-ext
Seek-S-value-ext = token
Retry-After = "Retry-After" HCOLON (RTSP-date / delta-seconds)
Scale = "Scale" HCOLON scale-value
Seek-Style = "Seek-Style" HCOLON Seek-S-values
Seek-S-values = "RAP"
/ "CoRAP"
/ "First-Prior"
/ "Next"
/ Seek-S-value-ext
Seek-S-value-ext = token
Server = "Server" HCOLON ( product / comment )
*(LWS (product / comment))
product = token [SLASH product-version]
product-version = token
comment = LPAREN *( ctext / quoted-pair) RPAREN
Server = "Server" HCOLON ( product / comment )
*(LWS (product / comment))
product = token [SLASH product-version]
product-version = token
comment = LPAREN *( ctext / quoted-pair) RPAREN
Session = "Session" HCOLON session-id [ SEMI "timeout" EQUAL delta-seconds ]
Session=“Session”HCOLON会话id[半“超时”等于增量秒]
Speed = "Speed" HCOLON lower-bound MINUS upper-bound lower-bound = POS-FLOAT upper-bound = POS-FLOAT
Speed=“Speed”HCOLON下限减去上限下限=POS-FLOAT上限=POS-FLOAT
Supported = "Supported" HCOLON [feature-tag-list]
Supported=“Supported”HCOLON[功能标签列表]
Terminate-Reason = "Terminate-Reason" HCOLON TR-Info
TR-Info = TR-Reason *(SEMI TR-Parameter)
TR-Reason = "Session-Timeout"
/ "Server-Admin"
/ "Internal-Error"
/ token
TR-Parameter = TR-time / TR-user-msg / generic-param
TR-time = "time" EQUAL utc-time
TR-user-msg = "user-msg" EQUAL quoted-string
Terminate-Reason = "Terminate-Reason" HCOLON TR-Info
TR-Info = TR-Reason *(SEMI TR-Parameter)
TR-Reason = "Session-Timeout"
/ "Server-Admin"
/ "Internal-Error"
/ token
TR-Parameter = TR-time / TR-user-msg / generic-param
TR-time = "time" EQUAL utc-time
TR-user-msg = "user-msg" EQUAL quoted-string
Timestamp = "Timestamp" HCOLON timestamp-value [LWS delay]
timestamp-value = *19DIGIT [ "." *9DIGIT ]
delay = *9DIGIT [ "." *9DIGIT ]
Timestamp = "Timestamp" HCOLON timestamp-value [LWS delay]
timestamp-value = *19DIGIT [ "." *9DIGIT ]
delay = *9DIGIT [ "." *9DIGIT ]
Transport = "Transport" HCOLON transport-spec
*(COMMA transport-spec)
transport-spec = transport-id *trns-parameter
transport-id = trans-id-rtp / other-trans
trans-id-rtp = "RTP/" profile ["/" lower-transport]
; no LWS is allowed inside transport-id
other-trans = token *("/" token)
Transport = "Transport" HCOLON transport-spec
*(COMMA transport-spec)
transport-spec = transport-id *trns-parameter
transport-id = trans-id-rtp / other-trans
trans-id-rtp = "RTP/" profile ["/" lower-transport]
; no LWS is allowed inside transport-id
other-trans = token *("/" token)
profile = "AVP" / "SAVP" / "AVPF" / "SAVPF" / token
lower-transport = "TCP" / "UDP" / token
trns-parameter = (SEMI ( "unicast" / "multicast" ))
/ (SEMI "interleaved" EQUAL channel ["-" channel])
/ (SEMI "ttl" EQUAL ttl)
/ (SEMI "layers" EQUAL 1*DIGIT)
/ (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc))
/ (SEMI "mode" EQUAL mode-spec)
/ (SEMI "dest_addr" EQUAL addr-list)
/ (SEMI "src_addr" EQUAL addr-list)
/ (SEMI "setup" EQUAL contrans-setup)
/ (SEMI "connection" EQUAL contrans-con)
/ (SEMI "RTCP-mux")
/ (SEMI "MIKEY" EQUAL MIKEY-Value)
/ (SEMI trn-param-ext)
contrans-setup = "active" / "passive" / "actpass"
contrans-con = "new" / "existing"
trn-param-ext = par-name [EQUAL trn-par-value]
par-name = token
trn-par-value = *(rtsp-unreserved / quoted-string)
ttl = 1*3DIGIT ; 0 to 255
ssrc = 8HEX
channel = 1*3DIGIT ; 0 to 255
MIKEY-Value = base64
mode-spec = ( DQUOTE mode *(COMMA mode) DQUOTE )
mode = "PLAY" / token
addr-list = quoted-addr *(SLASH quoted-addr)
quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE
host-port = ( host [":" port] )
/ ( ":" port )
extension-addr = 1*qdtext
host = < As defined in RFC 3986>
port = < As defined in RFC 3986>
profile = "AVP" / "SAVP" / "AVPF" / "SAVPF" / token
lower-transport = "TCP" / "UDP" / token
trns-parameter = (SEMI ( "unicast" / "multicast" ))
/ (SEMI "interleaved" EQUAL channel ["-" channel])
/ (SEMI "ttl" EQUAL ttl)
/ (SEMI "layers" EQUAL 1*DIGIT)
/ (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc))
/ (SEMI "mode" EQUAL mode-spec)
/ (SEMI "dest_addr" EQUAL addr-list)
/ (SEMI "src_addr" EQUAL addr-list)
/ (SEMI "setup" EQUAL contrans-setup)
/ (SEMI "connection" EQUAL contrans-con)
/ (SEMI "RTCP-mux")
/ (SEMI "MIKEY" EQUAL MIKEY-Value)
/ (SEMI trn-param-ext)
contrans-setup = "active" / "passive" / "actpass"
contrans-con = "new" / "existing"
trn-param-ext = par-name [EQUAL trn-par-value]
par-name = token
trn-par-value = *(rtsp-unreserved / quoted-string)
ttl = 1*3DIGIT ; 0 to 255
ssrc = 8HEX
channel = 1*3DIGIT ; 0 to 255
MIKEY-Value = base64
mode-spec = ( DQUOTE mode *(COMMA mode) DQUOTE )
mode = "PLAY" / token
addr-list = quoted-addr *(SLASH quoted-addr)
quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE
host-port = ( host [":" port] )
/ ( ":" port )
extension-addr = 1*qdtext
host = < As defined in RFC 3986>
port = < As defined in RFC 3986>
Unsupported = "Unsupported" HCOLON feature-tag-list
User-Agent = "User-Agent" HCOLON ( product / comment )
*(LWS (product / comment))
Via = "Via" HCOLON via-parm *(COMMA via-parm)
via-parm = sent-protocol LWS sent-by *( SEMI via-params )
via-params = via-ttl / via-maddr
/ via-received / via-extension
via-ttl = "ttl" EQUAL ttl
via-maddr = "maddr" EQUAL host
via-received = "received" EQUAL (IPv4address / IPv6address)
IPv4address = < As defined in RFC 3986>
IPv6address = < As defined in RFC 3986>
via-extension = generic-param
sent-protocol = protocol-name SLASH protocol-version
SLASH transport-prot
protocol-name = "RTSP" / token
protocol-version = token
transport-prot = "UDP" / "TCP" / "TLS" / other-transport
other-transport = token
sent-by = host [ COLON port ]
Unsupported = "Unsupported" HCOLON feature-tag-list
User-Agent = "User-Agent" HCOLON ( product / comment )
*(LWS (product / comment))
Via = "Via" HCOLON via-parm *(COMMA via-parm)
via-parm = sent-protocol LWS sent-by *( SEMI via-params )
via-params = via-ttl / via-maddr
/ via-received / via-extension
via-ttl = "ttl" EQUAL ttl
via-maddr = "maddr" EQUAL host
via-received = "received" EQUAL (IPv4address / IPv6address)
IPv4address = < As defined in RFC 3986>
IPv6address = < As defined in RFC 3986>
via-extension = generic-param
sent-protocol = protocol-name SLASH protocol-version
SLASH transport-prot
protocol-name = "RTSP" / token
protocol-version = token
transport-prot = "UDP" / "TCP" / "TLS" / other-transport
other-transport = token
sent-by = host [ COLON port ]
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge-list
WWW Authenticate=“WWW Authenticate”HCOLON挑战列表
This section defines in ABNF the SDP extensions defined for RTSP. See Appendix D for the definition of the extensions in text.
本节在ABNF中定义了为RTSP定义的SDP扩展。有关文本中扩展的定义，请参见附录D。
control-attribute = "a=control:" *SP RTSP-REQ-Ref CRLF
control-attribute = "a=control:" *SP RTSP-REQ-Ref CRLF
a-range-def = "a=range:" ranges-spec CRLF
a-range-def = "a=range:" ranges-spec CRLF
a-mtag-def = "a=mtag:" message-tag CRLF
a-mtag-def = "a=mtag:" message-tag CRLF
The security considerations and threats around RTSP and its usage can be divided into considerations around the signaling protocol itself and the issues related to the media-stream delivery. However, when it comes to mitigation of security threats, a threat depending on the media-stream delivery may in fact be mitigated by a mechanism in the signaling protocol.
围绕RTSP及其使用的安全考虑和威胁可分为围绕信令协议本身的考虑和与媒体流交付相关的问题。然而，当涉及到安全威胁的缓解时，依赖于媒体流交付的威胁实际上可以通过信令协议中的机制来缓解。
There are several chapters and an appendix in this document that define security solutions for the protocol. These sections will be referenced when discussing the threats below. However, the reader should take special notice of the Security Framework (Section 19) and the specification of how to use SRTP and its key-management (Appendix C.1.4) to achieve certain aspects of the media security.
本文档中有几个章节和附录定义了协议的安全解决方案。在讨论以下威胁时，将参考这些章节。但是，读者应特别注意安全框架（第19节）以及如何使用SRTP及其密钥管理的规范（附录C.1.4），以实现媒体安全的某些方面。
This section focuses on issues related to the signaling protocol. Because of the similarity in syntax and usage between RTSP servers and HTTP servers, the security considerations outlined in [RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235] apply as well.
本节重点讨论与信令协议相关的问题。由于RTSP服务器和HTTP服务器在语法和用法上的相似性，[RFC7230]、[RFC7231]、[RFC7232]、[RFC7233]、[RFC7234]和[RFC7235]中概述的安全注意事项也适用。
Specifically, please note the following:
具体而言，请注意以下几点：
Abuse of Server Log Information: A server is in the position to save personal data about a user's requests that might identify their media consumption patterns or subjects of interest. This information is clearly confidential in nature, and its handling can be constrained by law in certain countries. Log information needs to be securely stored and appropriate guidelines followed for its analysis. See Section 9.8 of [RFC7230] for additional guidelines.
滥用服务器日志信息：服务器可以保存有关用户请求的个人数据，这些数据可能会识别用户的媒体消费模式或感兴趣的主题。这些信息在性质上显然是保密的，其处理可能受到某些国家法律的限制。日志信息需要安全存储，并遵循适当的准则进行分析。更多指南见[RFC7230]第9.8节。
Transfer of Sensitive Information: There is no reason to believe that information transferred in RTSP message, such as the URI and the content of headers, especially the Server, Via, Referrer, and From headers, may be any less sensitive than when used in HTTP. Therefore, all of the precautions regarding the protection of data privacy and user privacy apply to implementers of RTSP clients, servers, and proxies. See Sections 9.3-9.6 of [RFC7231] for further details.
敏感信息的传输：没有理由相信在RTSP消息中传输的信息，例如URI和头的内容，特别是服务器、Via、referer和From头的内容，可能比在HTTP中使用时敏感。因此，所有关于保护数据隐私和用户隐私的预防措施都适用于RTSP客户端、服务器和代理的实现者。详见[RFC7231]第9.3-9.6节。
The RTSP methods defined in this document are primarily used to establish and control the delivery of the media data represented by the URI; thus, the RTSP message bodies are generally less sensitive than the ones in HTTP. Where HTTP bodies could contain, for example, your medical records, in RTSP, the sensitive video of your medical operation would be in the media stream over the media-transport protocol, not in the RTSP message. Still, one has to take note of what potential sensitive information is included in RTSP. The protection of the media data is separate, can be applied directly between client and server, and is dependent on the media-transport protocol in use. See Section 21.2 for further discussion. This possibility for separation of security between media-
本文档中定义的RTSP方法主要用于建立和控制由URI表示的媒体数据的传递；因此，RTSP消息体通常不如HTTP中的消息体敏感。在HTTP主体可能包含（例如）RTSP中的医疗记录的情况下，医疗操作的敏感视频将通过媒体传输协议在媒体流中，而不是在RTSP消息中。不过，我们必须注意RTSP中包含哪些潜在的敏感信息。媒体数据的保护是独立的，可以直接在客户端和服务器之间应用，并且取决于使用的媒体传输协议。进一步讨论见第21.2节。媒体之间安全隔离的可能性-
resource content and the signaling protocol mitigates the risk of exposing the media content when using hop-by-hop security for RTSP signaling using proxies (Section 19.3).
资源内容和信令协议降低了使用代理为RTSP信令使用逐跳安全性时暴露媒体内容的风险（第19.3节）。
Attacks Based On File and Path Names: Though RTSP URIs are opaque handles that do not necessarily have file-system semantics, it is anticipated that many implementations will translate portions of the Request-URIs directly to file-system calls. In such cases, file systems SHOULD follow the precautions outlined in Section 9.1 of [RFC7231], such as checking for ".." in path components.
基于文件名和路径名的攻击：尽管RTSP URI是不透明的句柄，不一定具有文件系统语义，但预计许多实现会将部分请求URI直接转换为文件系统调用。在这种情况下，文件系统应遵循[RFC7231]第9.1节中概述的预防措施，例如检查路径组件中的“.”。
Personal Information: RTSP clients are often privy to the same information that HTTP clients are (username, location, etc.) and thus should be equally sensitive. See Section 9.8 of [RFC7230], Sections 9.3-9.7 of [RFC7231], and Section 8 of [RFC7234] for further recommendations.
个人信息：RTSP客户端通常与HTTP客户端拥有相同的信息（用户名、位置等），因此应该同样敏感。更多建议参见[RFC7230]第9.8节、[RFC7231]第9.3-9.7节和[RFC7234]第8节。
Privacy Issues Connected to Accept Headers: Since similar usages of the "Accept" headers exist in RTSP as in HTTP, the same caveats outlined in Section 9.4 of [RFC7231] with regard to their use should be followed.
与Accept头相关的隐私问题：由于RTSP中存在与HTTP中类似的“Accept”头用法，因此应遵循[RFC7231]第9.4节中概述的关于其用法的相同注意事项。
Establishing Authority: RTSP shares with HTTP the question of how a client communicates with the authoritative source for media streams (Section 9.1 of [RFC7230]). The used DNS servers, the security of the communication, and any possibility of a man in the middle, and the trust in any RTSP proxies all affect the possibility that a client has received a non-authoritative response to a request. Ensuring that a client receives an authoritative response is challenging, although using the secure communication for RTSP signaling (rtsps) simplifies it significantly as the server can provide a hostname identity assertion in the TLS handshake.
建立授权：RTSP与HTTP共享一个问题，即客户端如何与媒体流的授权源通信（RFC7230的第9.1节）。所使用的DNS服务器、通信的安全性以及中间人的任何可能性，以及任何RTSP代理中的信任都影响客户端接收到对请求的非权威响应的可能性。尽管使用RTSP信令安全通信（rtsps）可以大大简化这一过程，因为服务器可以在TLS握手中提供主机名标识断言，但确保客户端接收权威响应是一项挑战。
Location Headers and Spoofing: If a single server supports multiple organizations that do not trust each another, then it MUST check the values of the Content-Location header fields in responses that are generated under control of said organizations to make sure that they do not attempt to invalidate resources over which they have no authority (see Section 15.4 of [RFC2616]).
位置头和欺骗：如果一台服务器支持多个彼此不信任的组织，那么它必须检查在所述组织控制下生成的响应中的内容位置头字段的值，以确保它们不会试图使其无权访问的资源无效（见[RFC2616]第15.4节）。
In addition to the recommendations in the current HTTP specifications ([RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235] as of this writing) and also those of the previous relevant RFCs [RFC2068] [RFC2616], future HTTP specifications may provide additional guidance on security issues.
除了当前HTTP规范（[RFC7230]、[RFC7231]、[RFC7232]、[RFC7233]、[RFC7234]和[RFC7235]中的建议，以及之前相关的RFC[RFC2068][RFC2616]中的建议之外，未来的HTTP规范可能会提供关于安全问题的额外指导。
The following are added considerations for RTSP implementations.
以下是RTSP实现的附加注意事项。
Session Hijacking: Since there is no or little relation between a transport-layer connection and an RTSP session, it is possible for a malicious client to issue requests with random session identifiers that could affect other clients of an unsuspecting server. To mitigate this, the server SHALL use a large, random and non-sequential session identifier to minimize the possibility of this kind of attack. However, unless the RTSP signaling is always confidentiality protected, e.g., using TLS, an on-path attacker will be able to hijack a session. Another choice for preventing session hijacking is to use client authentication and only allow the authenticated client creating the session to access that session.
会话劫持：由于传输层连接和RTSP会话之间没有或几乎没有关系，恶意客户端可能会发出带有随机会话标识符的请求，这可能会影响到不知情服务器的其他客户端。为了缓解这种情况，服务器应使用大型、随机和非顺序会话标识符，以最大限度地降低此类攻击的可能性。但是，除非RTSP信令始终受到保密保护，例如使用TLS，否则路径上的攻击者将能够劫持会话。防止会话劫持的另一种选择是使用客户端身份验证，并且只允许创建会话的经过身份验证的客户端访问该会话。
Authentication: Servers SHOULD implement both basic and Digest [RFC2617] authentication. In environments requiring tighter security for the control messages, the transport-layer mechanism TLS [RFC5246] SHOULD be used.
身份验证：服务器应实现基本身份验证和摘要身份验证[RFC2617]。在需要更严格的控制消息安全性的环境中，应使用传输层机制TLS[RFC5246]。
Suspicious Behavior: Upon detecting instances of behavior that is deemed a security risk, RTSP servers SHOULD return error code 403 (Forbidden). RTSP servers SHOULD also be aware of attempts to probe the server for weaknesses and entry points and MAY arbitrarily disconnect and ignore further requests from clients that are deemed to be in violation of local security policy.
可疑行为：在检测到被视为安全风险的行为实例后，RTSP服务器应返回错误代码403（禁止）。RTSP服务器还应该知道有人试图探测服务器的弱点和入口点，并且可能会任意断开和忽略来自被认为违反本地安全策略的客户端的进一步请求。
TLS through Proxies: If one uses the possibility to connect TLS in multiple legs (Section 19.3), one really needs to be aware of the trust model. This procedure requires trust in all proxies part of the path to the server. The proxies one connects through are identified, assuming the proxies so far connected through are well behaved and fulfilling the trust. The accepted proxies are men in the middle and have access to all that goes on over the TLS connection. Thus, it is important to consider if that trust model is acceptable in the actual application. Further discussion of the actual trust model is in Section 19.3. It is important to note what difference in security properties, if any, may exist with the used media-transport protocol and its security mechanism. Using SRTP and the MIKEY-based key-establishment defined in Appendix C.1.4.1 enables media key-establishment to be done end-to-end without revealing the keys to the proxies.
通过代理连接TLS：如果使用多个分支连接TLS的可能性（第19.3节），则确实需要了解信任模型。此过程要求信任服务器路径的所有代理。一个通过连接的代理被识别，假设到目前为止通过连接的代理行为良好并满足信任。被接受的代理是中间人，可以访问TLS连接上的所有内容。因此，重要的是要考虑该信任模型是否在实际应用中是可接受的。第19.3节进一步讨论了实际信任模型。重要的是要注意所使用的媒体传输协议及其安全机制在安全属性（如果有）方面可能存在哪些差异。使用SRTP和附录C.1.4.1中定义的基于MIKEY的密钥建立，可实现端到端的媒体密钥建立，而无需向代理透露密钥。
Resource Exhaustion: As RTSP is a stateful protocol and establishes resource usage on the server, there is a clear possibility to attack the server by trying to overbook these resources to perform a DoS attack. This attack can be both against ongoing sessions and to prevent others from establishing sessions. RTSP agents will need to have mechanisms to prevent single peers from consuming extensive amounts of resources. The methods for guarding against this are varied and depend on the agent's role and capabilities and policies. Each implementation has to carefully consider its methods and policies to mitigate this threat. There are recommendations regarding the handling of connections in Section 10.7.
资源耗尽：由于RTSP是一种有状态协议，并在服务器上建立了资源使用情况，因此很有可能通过试图超额预订这些资源来执行DoS攻击来攻击服务器。此攻击既可以针对正在进行的会话，也可以阻止其他人建立会话。RTSP代理将需要有防止单个对等方消耗大量资源的机制。防范这种情况的方法多种多样，取决于代理的角色、能力和策略。每个实现都必须仔细考虑它的方法和策略来减轻这种威胁。第10.7节中有关于连接处理的建议。
The above threats and considerations have resulted in a set of security functions and mechanisms built into or used by the protocol. The signaling protocol relies on two security features defined in the Security Framework (Section 19): namely client authentication using HTTP authentication and TLS-based transport protection of the signaling messages. Both of these mechanisms are required to be implemented by any RTSP agent.
上述威胁和考虑导致协议内置或使用了一套安全功能和机制。信令协议依赖于安全框架（第19节）中定义的两个安全特性：即使用HTTP身份验证的客户端身份验证和基于TLS的信令消息传输保护。这两种机制都需要由任何RTSP代理实现。
A number of different security mitigations have been designed into the protocol and will be instantiated if the specification is implemented as written, for example, by ensuring sufficient amounts of entropy in the randomly generated session identifiers when not using client authentication to minimize the risk of session hijacking. When client authentication is used, protection against hijacking will be greatly improved by scoping the accessible sessions to the one this client identity has created. Some of the above threats are such that the implementation of the RTSP functionality itself needs to consider which policy and strategy it uses to mitigate them.
协议中已经设计了许多不同的安全缓解措施，如果按照书面形式实施规范，则将对这些措施进行实例化，例如，在不使用客户端身份验证时，通过确保随机生成的会话标识符中有足够的熵来最小化会话劫持的风险。当使用客户机身份验证时，通过将可访问会话的范围限定为该客户机身份创建的会话，将大大提高对劫持的保护。上述一些威胁使得RTSP功能本身的实现需要考虑使用哪些策略和策略来减轻它们。
The fact that RTSP establishes and controls a media-stream delivery results in a set of security issues related to the media streams. This section will attempt to analyze general threats; however, the choice of media-stream transport protocol, such as RTP, will result in some differences in threats and what mechanisms exist to mitigate them. Thus, it becomes important that each specification of a new media-stream transport and delivery protocol usable by RTSP requires its own security analysis. This section includes one for RTP.
RTSP建立并控制媒体流交付的事实导致了一组与媒体流相关的安全问题。本节将尝试分析一般威胁；然而，媒体流传输协议（如RTP）的选择将导致在威胁和现有的缓解机制方面存在一些差异。因此，RTSP可用的新媒体流传输和交付协议的每个规范都需要自己的安全性分析，这一点变得非常重要。本节包括一个RTP。
The set of general threats from or by the media-stream delivery itself are:
来自媒体流传输本身或由媒体流传输本身造成的一组一般威胁包括：
Concentrated Denial-of-Service Attack: The protocol offers the opportunity for a remote-controlled DoS attack, where the media stream is the hammer in that DoS attack. See Section 21.2.1.
集中拒绝服务攻击：该协议提供了远程控制DoS攻击的机会，其中媒体流是DoS攻击的重锤。见第21.2.1节。
Media Confidentiality: The media delivery may contain content of any type, and it is not possible, in general, to determine how sensitive this content is from a confidentiality point. Thus, it is a strong requirement that any media delivery protocol supply a method for providing confidentiality of the actual media content. In addition to the media-level confidentiality, it becomes critical that no resource identifiers used in the signaling be exposed to an attacker as they may have human-understandable names or may be available to the attacker, allowing it to determine the content the user received. Thus, the signaling protocol must also provide confidentiality protection of any information related to the media resource.
媒体机密性：媒体交付可能包含任何类型的内容，通常无法从机密性角度确定此内容的敏感程度。因此，强烈要求任何媒体交付协议提供用于提供实际媒体内容的机密性的方法。除了媒体级机密性之外，信令中使用的任何资源标识符都不得暴露给攻击者，因为这些资源标识符可能具有人类可以理解的名称，或者攻击者可以使用这些资源标识符，从而使攻击者能够确定用户收到的内容。因此，信令协议还必须提供与媒体资源相关的任何信息的机密性保护。
Media Integrity and Authentication: There are several reasons why an attacker will be interested in substituting the media stream sent out from the RTSP server with one of the attacker's creation or selection, such as discrediting the target and misinformation about the target. Therefore, it is important that the media protocol provide mechanisms to verify the source authentication and integrity and to prevent replay attacks on the media stream.
媒体完整性和身份验证：攻击者之所以有兴趣用攻击者创建或选择的媒体流替换从RTSP服务器发送的媒体流，有几个原因，例如破坏目标的信誉和有关目标的错误信息。因此，媒体协议提供验证源身份验证和完整性以及防止对媒体流的重播攻击的机制非常重要。
Scope of Multicast: If RTSP is used to control the transmission of media onto a multicast network, the scope of the delivery must be considered. RTSP supports the TTL Transport header parameter to indicate this scope for IPv4. IPv6 has a different mechanism for the scope boundary. However, such scope control has risks, as it may be set too large and distribute media beyond the intended scope.
多播范围：如果使用RTSP控制媒体在多播网络上的传输，则必须考虑传输范围。RTSP支持TTL传输头参数，以指示IPv4的此作用域。IPv6对作用域边界具有不同的机制。但是，这种范围控制有风险，因为它可能设置得太大，并且分发的媒体超出了预期范围。
Below (Section 21.2.2) a protocol-specific analysis of security considerations for RTP-based media transport is included. In that section, the requirements on implementing security functions for RTSP agents supporting media delivery over RTP are made clear.
下面（第21.2.2节）包括基于RTP的媒体传输的安全注意事项的协议特定分析。在该部分中，明确了支持RTP介质交付的RTSP代理实现安全功能的要求。
The attacker may initiate traffic flows to one or more IP addresses by specifying them as the destination in SETUP requests. While the attacker's IP address may be known in this case, this is not always useful in the prevention of more attacks or ascertaining the attacker's identity. Thus, an RTSP server MUST only allow client-specified destinations for RTSP-initiated traffic flows if the server has ensured that the specified destination address accepts receiving media through different security mechanisms. Security mechanisms that are acceptable in order of increasing generality are:
攻击者可以通过在安装请求中将一个或多个IP地址指定为目标来启动到这些地址的通信流。虽然在这种情况下，攻击者的IP地址可能是已知的，但这在防止更多攻击或确定攻击者身份方面并不总是有用的。因此，如果RTSP服务器已确保指定的目标地址通过不同的安全机制接受接收介质，则RTSP服务器必须仅允许RTSP启动的通信流的客户端指定目标。按照通用性增加的顺序，可接受的安全机制包括：
o Verification of the client's identity against a database of known users using RTSP authentication mechanisms (preferably Digest authentication or stronger)
o 使用RTSP身份验证机制（最好是摘要身份验证或更强的身份验证）对已知用户数据库进行客户身份验证
o A list of addresses that have consented to be media destinations, especially considering user identity
o 已同意作为媒体目的地的地址列表，特别是考虑到用户身份
o Verification based on media path
o 基于媒体路径的验证
The server SHOULD NOT allow the destination field to be set unless a mechanism exists in the system to authorize the request originator to direct streams to the recipient. It is preferred that this authorization be performed by the media recipient (destination) itself and the credentials be passed along to the server. However, in certain cases, such as when the recipient address is a multicast group or when the recipient is unable to communicate with the server in an out-of-band manner, this may not be possible. In these cases, the server may choose another method such as a server-resident authorization list to ensure that the request originator has the proper credentials to request stream delivery to the recipient.
除非系统中存在授权请求发起人将流定向到收件人的机制，否则服务器不应允许设置目标字段。最好由媒体收件人（目的地）自己执行此授权，并将凭据传递给服务器。然而，在某些情况下，例如当接收者地址是多播组或当接收者无法以带外方式与服务器通信时，这可能是不可能的。在这些情况下，服务器可以选择另一种方法，例如驻留在服务器上的授权列表，以确保请求发起人具有向接收方请求流传递的适当凭据。
One solution that performs the necessary verification of acceptance of media suitable for unicast-based delivery is the NAT traversal method based on Interactive Connectivity Establishment (ICE) [RFC5245] described in [RFC7825]. This mechanism uses random passwords and a username so that the probability of unintended indication as a valid media destination is very low. In addition, the server includes in its Session Traversal Utilities for NAT (STUN) [RFC5389] requests a cookie (consisting of random material) that the destination echoes back; thus, the solution also safeguards against having an off-path attacker being able to spoof the STUN checks. This leaves this solution vulnerable only to on-path attackers that can see the STUN requests go to the target of attack and thus forge a response.
一个解决方案是[RFC7825]中描述的基于交互式连接建立（ICE）[RFC5245]的NAT遍历方法，该解决方案对适合单播传输的媒体的接受情况进行必要的验证。此机制使用随机密码和用户名，因此意外指示为有效媒体目标的概率非常低。此外，服务器在其会话遍历实用程序中包括NAT（STUN）[RFC5389]请求一个cookie（由随机材料组成），目的地回显该cookie；因此，该解决方案还可以防止路径外攻击者能够欺骗眩晕检查。这使得此解决方案仅易受路径上攻击者的攻击，这些攻击者可以看到眩晕请求到达攻击目标，从而伪造响应。
For delivery to multicast addresses, there is a need for another solution that is not specified in this memo.
要传送到多播地址，需要另一种解决方案，此备忘录中未指定。
RTP is a commonly used media-transport protocol and has been the most common choice for RTSP 1.0 implementations. The core RTP protocol has been in use for a long time, and it has well-known security properties and the RTP security consideration (Section 9 of [RFC3550]) needs to be reviewed. In perspective of the usage of RTP in the context of RTSP, the following properties should be noted:
RTP是一种常用的媒体传输协议，是RTSP 1.0实现中最常见的选择。核心RTP协议已经使用了很长时间，它具有众所周知的安全特性，需要对RTP安全考虑（RFC3550第9节）进行审查。鉴于RTP在RTSP环境中的使用，应注意以下属性：
Stream Additions: RTP has support for multiple simultaneous media streams in each RTP session. As some use cases require support for non-synchronized adding and removal of media streams and their identifiers, an attacker can easily insert additional media streams into a session context that, according to protocol design, is intended to be played out. Another threat vector is one of DoS by exhausting the resources of the RTP session receiver, for example, by using a large number of SSRC identifiers simultaneously. The strong mitigation of this is to ensure that one cryptographically authenticates any incoming packet flow to the RTP session. Weak mitigations like blocking additional media streams in session contexts easily lead to a DoS vulnerability in addition to preventing certain RTP extensions or use cases that rely on multiple media streams, such as RTP retransmission [RFC4588] to function.
流添加：RTP在每个RTP会话中支持多个同时的媒体流。由于某些用例需要对媒体流及其标识符的非同步添加和删除提供支持，攻击者可以很容易地将其他媒体流插入到会话上下文中，根据协议设计，该会话上下文将被播放。另一个威胁向量是DoS，例如，通过同时使用大量SSRC标识符来耗尽RTP会话接收器的资源。这方面的强大缓解措施是确保通过加密方式对任何进入RTP会话的数据包流进行身份验证。除了防止某些RTP扩展或依赖于多个媒体流的用例（如RTP重传[RFC4588]）正常工作外，会话上下文中阻止额外媒体流之类的弱缓解措施很容易导致DoS漏洞。
Forged Feedback: The built-in RTCP also offers a large attack surface for a couple of different types of attacks. One venue is to send RTCP feedback to the media sender indicating large amounts of packet loss and thus trigger a media bitrate adaptation response from the sender resulting in lowered media quality and potentially a shutdown of the media stream. Another attack is to perform a resource-exhaustion attack on the receiver by using many SSRC identifiers to create large state tables and increase the RTCP-related processing demands.
伪造反馈：内置RTCP还为几种不同类型的攻击提供了较大的攻击面。一种方式是向媒体发送方发送RTCP反馈，指示大量数据包丢失，从而触发来自发送方的媒体比特率自适应响应，从而导致媒体质量降低，并可能导致媒体流关闭。另一种攻击是通过使用许多SSRC标识符来创建大型状态表并增加与RTCP相关的处理需求，从而对接收器执行资源耗尽攻击。
RTP/RTCP Extensions: RTP and RTCP extensions generally provide additional and sometimes extremely powerful tools for DoS attacks or service disruption. For example, the Code Control Message [RFC5104] RTCP extensions enables both the lock down of the bitrate to low values and disruption of video quality by requesting intra-frames.
RTP/RTCP扩展：RTP和RTCP扩展通常为DoS攻击或服务中断提供额外的、有时非常强大的工具。例如，代码控制消息[RFC5104]RTCP扩展通过请求帧内帧来实现比特率低值锁定和视频质量中断。
Taking into account the above general discussion in Section 21.2 and the RTP-specific discussion in this section, it is clear that it is necessary that a strong security mechanism be supported to protect
考虑到第21.2节中的上述一般性讨论和本节中RTP的具体讨论，显然有必要支持强大的安全机制来保护
RTP. Therefore, this specification has the following requirements on RTP security functions for all RTSP agents that handle media streams and where media-stream transport is completed using RTP.
RTP。因此，本规范对所有处理媒体流的RTSP代理以及使用RTP完成媒体流传输的RTP安全功能有以下要求。
RTSP agents supporting RTP MUST implement Secure RTP (SRTP) [RFC3711] and, thus, SAVP. In addition, SAVPF [RFC5124] MUST also be supported if AVPF is implemented. This specification requires no additional cryptographic transforms or configuration values beyond those specified as mandatory to implement in RFC 3711, i.e., AES-CM and HMAC-SHA1. The default key-management mechanism that MUST be implemented is the one defined in MIKEY Key Establishment (Appendix C.1.4.1). The MIKEY implementation MUST implement the necessary functions for MIKEY-RSA-R mode [RFC4738] and the SRTP parameter negotiation necessary to negotiate the supported SRTP transforms and parameters.
支持RTP的RTSP代理必须实现安全RTP（SRTP）[RFC3711]，从而实现SAVP。此外，如果实现AVPF，还必须支持SAVPF[RFC5124]。本规范不需要额外的加密转换或配置值，除了RFC 3711中规定的强制实现值，即AES-CM和HMAC-SHA1。必须实施的默认密钥管理机制是MIKEY密钥建立（附录C.1.4.1）中定义的机制。MIKEY实现必须实现MIKEY-RSA-R模式[RFC4738]的必要功能，以及协商支持的SRTP转换和参数所需的SRTP参数协商。
This section describes a number of registries for RTSP 2.0 that have been established and are maintained by IANA. These registries are separate from any registries existing for RTSP 1.0. For each registry, there is a description of the required content, the registration procedures, and the entries that this document registers. For more information on extending RTSP, see Section 2.7. In addition, this document registers three SDP attributes.
本节描述了由IANA建立和维护的RTSP 2.0的多个注册中心。这些注册表与RTSP 1.0现有的任何注册表是分开的。对于每个注册表，都有对所需内容、注册程序和本文档注册的条目的描述。有关扩展RTSP的更多信息，请参阅第2.7节。此外，本文档还注册了三个SDP属性。
Registries or entries in registries that have been made for RTSP 1.0 are not moved to RTSP 2.0: the registries and entries of RTSP 1.0 and RTSP 2.0 are independent. If any registry or entry in a registry is also required in RTSP 2.0, it MUST follow the procedure defined below to allocate the registry or entry in a registry.
为RTSP 1.0创建的注册表或注册表项不会移动到RTSP 2.0：RTSP 1.0和RTSP 2.0的注册表和注册表项是独立的。如果RTSP 2.0中还需要注册表中的任何注册表或条目，则必须按照下面定义的过程在注册表中分配注册表或条目。
The sections describing how to register an item use some of the registration policies described in [RFC5226] -- namely, "First Come First Served", "Expert Review", "Specification Required", and "Standards Action".
描述如何注册物品的章节使用了[RFC5226]中描述的一些注册政策，即“先到先得”、“专家评审”、“要求规范”和“标准行动”。
In case a registry requires a contact person, the authors (with Magnus Westerlund <magnus.westerlund@ericsson.com> as primary) are the contact persons for any entries created by this document.
如果登记处需要联系人，作者（与Magnus Westerlund<Magnus。westerlund@ericsson.com>作为主要联系人）是本文件创建的任何条目的联系人。
IANA will request the following information for any registration request:
IANA将要求任何注册申请提供以下信息：
o A name of the item to register according to the rules specified by the intended registry
o 根据预期注册表指定的规则注册的项目名称
o Indication of who has change control over the feature (for example, the IETF, ISO, ITU-T, other international standardization bodies, a consortium, a particular company or group of companies, or an individual)
o 表明谁对功能具有变更控制权（例如，IETF、ISO、ITU-T、其他国际标准化机构、联合体、特定公司或公司集团或个人）
o A reference to a further description, if available, for example (in decreasing order of preference), an RFC, a published standard, a published paper, a patent filing, a technical report, documented source code or a computer manual
o 进一步说明的参考，如有，例如（按优先顺序递减）、RFC、已发布标准、已发布论文、专利申请、技术报告、记录的源代码或计算机手册
o For proprietary features, contact information (postal and email address)
o 对于专有功能，联系信息（邮政和电子邮件地址）
When a client and server try to determine what part and functionality of the RTSP specification and any future extensions that its counterpart implements, there is need for a namespace. This registry contains named entries representing certain functionality.
当客户机和服务器试图确定RTSP规范的哪一部分和功能以及它的对等方将来实现的任何扩展时，就需要一个名称空间。此注册表包含表示某些功能的命名项。
The usage of feature tags is explained in Section 11 and Section 13.1.
第11节和第13.1节解释了功能标签的使用。
The registering of feature tags is done on a First Come, First Served [RFC5226] basis.
功能标签的注册是在先到先得[RFC5226]的基础上完成的。
The registry entry for a feature tag has the following information:
功能标记的注册表项包含以下信息：
o The name of the feature tag
o 要素标记的名称
* If the registrant indicates that the feature is proprietary, IANA should request a vendor "prefix" portion of the name. The name will then be the vendor prefix followed by a "." followed by the rest of the provided feature name.
* 如果注册人表示该功能是专有的，IANA应要求供应商提供名称的“前缀”部分。然后，名称将是供应商前缀，后跟“.”，后跟所提供功能名称的其余部分。
* If the feature is not proprietary, then IANA need not collect a prefix for the name.
* 如果该功能不是专有的，那么IANA不需要为该名称收集前缀。
o A one-paragraph description of what the feature tag represents
o 功能标记所代表内容的一段描述
o The applicability (server, client, proxy, or some combination)
o 适用性（服务器、客户端、代理或某些组合）
o A reference to a specification, if applicable
o 参考规范（如适用）
Feature tag names (including the vendor prefix) may contain any non-space and non-control characters. There is no length limit on feature tags.
要素标记名称（包括供应商前缀）可以包含任何非空格和非控制字符。要素标记没有长度限制。
Examples for a vendor tag describing a proprietary feature are:
描述专有功能的供应商标签示例如下：
vendorA.specfeat01
vendorA.specfeat01
vendorA.specfeat02
vendorA.specfeat02
The following feature tags are defined in this specification and hereby registered. The change control belongs to the IETF.
以下特征标签在本规范中定义，特此注册。变更控制属于IETF。
play.basic: The implementation for delivery and playback operations according to the core RTSP specification, as defined in this memo. Applies for clients, servers, and proxies. See Section 11.1.
play.basic：根据本备忘录中定义的核心RTSP规范执行传送和回放操作。适用于客户端、服务器和代理。见第11.1节。
play.scale: Support of scale operations for media playback. Applies only for servers. See Section 18.46.
play.scale：支持媒体播放的缩放操作。仅适用于服务器。见第18.46节。
play.speed: Support of the speed functionality for media delivery. Applies only for servers. See Section 18.50.
play.speed：支持媒体传送的速度功能。仅适用于服务器。见第18.50节。
setup.rtp.rtcp.mux: Support of the RTP and RTCP multiplexing as discussed in Appendix C.1.6.4. Applies for both client and servers and any media caching proxy.
setup.rtp.rtcp.mux：支持rtp和rtcp多路复用，如附录C.1.6.4所述。适用于客户端和服务器以及任何媒体缓存代理。
The IANA registry is a table with the name, description, and reference for each feature tag.
IANA注册表是一个表，其中包含每个功能标记的名称、描述和引用。
Methods are described in Section 13. Extending the protocol with new methods allows for totally new functionality.
方法见第13节。用新方法扩展协议可以实现全新的功能。
A new method is registered through a Standards Action [RFC5226] because new methods may radically change the protocol's behavior and purpose.
通过标准行动[RFC5226]注册新方法，因为新方法可能会从根本上改变协议的行为和目的。
A specification for a new RTSP method consists of the following items:
新RTSP方法的规范包括以下各项：
o A method name that follows the ABNF rules for methods.
o 遵循ABNF方法规则的方法名称。
o A clear specification of what a request using the method does and what responses are expected. In which directions the method is used: C->S, S->C, or both. How the use of headers, if any, modifies the behavior and effect of the method.
o 明确说明使用该方法的请求的作用以及预期的响应。在哪个方向使用该方法：C->S，S->C，或两者兼而有之。标题的使用（如果有）如何修改方法的行为和效果。
o A list or table specifying which of the IANA-registered headers that are allowed to be used with the method in the request or/and response. The list or table SHOULD follow the format of tables in Section 18.
o 一个列表或表格，指定允许在请求或/和响应中与方法一起使用的IANA注册头中的哪一个。列表或表格应遵循第18节表格的格式。
o Describe how the method relates to network proxies.
o 描述该方法与网络代理的关系。
This specification, RFC 7826, registers 10 methods: DESCRIBE, GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY, REDIRECT, SETUP, SET_PARAMETER, and TEARDOWN. The initial table of the registry is provided below.
本规范RFC 7826注册了10种方法：描述、获取参数、选项、暂停、播放、播放通知、重定向、设置、设置参数和拆卸。登记处的初始表格如下所示。
Method Directionality Reference
-----------------------------------------------------
DESCRIBE C->S RFC 7826
GET_PARAMETER C->S, S->C RFC 7826
OPTIONS C->S, S->C RFC 7826
PAUSE C->S RFC 7826
PLAY C->S RFC 7826
PLAY_NOTIFY S->C RFC 7826
REDIRECT S->C RFC 7826
SETUP C->S RFC 7826
SET_PARAMETER C->S, S->C RFC 7826
TEARDOWN C->S, S->C RFC 7826
Method Directionality Reference
-----------------------------------------------------
DESCRIBE C->S RFC 7826
GET_PARAMETER C->S, S->C RFC 7826
OPTIONS C->S, S->C RFC 7826
PAUSE C->S RFC 7826
PLAY C->S RFC 7826
PLAY_NOTIFY S->C RFC 7826
REDIRECT S->C RFC 7826
SETUP C->S RFC 7826
SET_PARAMETER C->S, S->C RFC 7826
TEARDOWN C->S, S->C RFC 7826
A status code is the three-digit number used to convey information in RTSP response messages; see Section 8. The number space is limited, and care should be taken not to fill the space.
状态代码是用于在RTSP响应消息中传递信息的三位数字；见第8节。数字空间有限，应注意不要填满空间。
A new status code registration follows the policy of IETF Review [RFC5226]. New RTSP functionality requiring Status Codes should first be registered in the range of x50-x99. Only when the range is full should registrations be made in the x00-x49 range, unless it is to adopt an HTTP extension to RTSP. This is done to enable any HTTP extension to be adopted to RTSP without needing to renumber any related status codes. A specification for a new status code must include the following:
新的状态码注册遵循IETF审查[RFC5226]的政策。需要状态代码的新RTSP功能应首先在x50-x99范围内注册。只有当范围已满时，才应在x00-x49范围内进行注册，除非它采用RTSP的HTTP扩展。这样做是为了使RTSP能够采用任何HTTP扩展，而无需重新编号任何相关的状态代码。新状态代码的规范必须包括以下内容：
o The registered number.
o 注册号码。
o A description of what the status code means and the expected behavior of the sender and receiver of the code.
o 对状态代码的含义以及代码发送者和接收者的预期行为的描述。
RFC 7826 (this document) registers the numbered status code defined in the ABNF entry "Status-Code", except "extension-code" (that defines the syntax allowed for future extensions) in Section 20.2.2.
RFC 7826（本文件）登记了ABNF条目“状态代码”中定义的编号状态代码，但第20.2.2节中的“扩展代码”（定义了未来扩展所允许的语法）除外。
By specifying new headers, one or more methods can be enhanced in many different ways. An unknown header will be ignored by the receiving agent. If the new header is vital for certain functionality, a feature tag for the functionality can be created and demanded to be used by the counterpart with the inclusion of a Require header carrying the feature tag.
通过指定新的头，可以以多种不同的方式增强一个或多个方法。接收代理将忽略未知标头。如果新标题对某些功能至关重要，则可以创建功能的功能标签，并要求对方使用，同时包括携带功能标签的Require标题。
Registrations can be made following the Expert Review policy [RFC5226]. A specification is recommended to be provided, preferably an RFC or other specification from a Standards Developing Organization. The minimal information in a registration request is the header name and the contact information.
可以按照专家评审政策[RFC5226]进行注册。建议提供规范，最好是RFC或标准开发组织的其他规范。注册请求中的最小信息是标题名和联系人信息。
The expert reviewer verifies that the registration request contains the following information:
专家评审员验证注册请求是否包含以下信息：
o The name of the header.
o 标题的名称。
o An ABNF specification of the header syntax.
o 标头语法的ABNF规范。
o A list or table specifying when the header may be used, encompassing all methods, their request or response, and the direction (C->S or S->C).
o 一种列表或表格，指定何时可以使用标题，包括所有方法、它们的请求或响应以及方向（C->S或S->C）。
o How the header is to be handled by proxies.
o 代理如何处理标头。
o A description of the purpose of the header.
o 标题用途的说明。
All headers specified in Section 18 in RFC 7826 have been registered. The registry includes the header name and reference.
RFC 7826第18节规定的所有标题均已注册。注册表包括头名称和引用。
Furthermore, the following legacy RTSP headers defined in other specifications are registered with header name, and reference according to below list. Note: these references may not fulfill all of the above rules for registrations due to their legacy status.
此外，在其他规范中定义的以下传统RTSP标头使用标头名称注册，并根据下面的列表进行引用。注：由于这些引用文件的遗留状态，它们可能不符合上述所有注册规则。
o x-wap-profile defined in [TS-26234]. The x-wap-profile request-header contains one or more absolute URLs to the requesting agent's device-capability profile.
o [TS-26234]中定义的x-wap-profile。x-wap-profile请求标头包含一个或多个指向请求代理的设备功能配置文件的绝对URL。
o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff request-header contains a subset of a device-capability profile.
o [TS-26234]中定义了x-wap-profile-diff。x-wap-profile-diff请求标头包含设备功能配置文件的子集。
o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile-warning is a response-header that contains error codes explaining to what extent the server has been able to match the terminal request in regard to device-capability profiles, as described using x-wap-profile and x-wap-profile-diff headers.
o [TS-26234]中定义了x-wap-profile-warning。x-wap-profile-warning是一个响应标头，其中包含错误代码，解释服务器能够在多大程度上匹配终端请求的设备功能配置文件，如使用x-wap-profile和x-wap-profile-diff标头所述。
o x-predecbufsize defined in [TS-26234]. This response-header provides an RTSP agent with the TS 26.234 Annex G hypothetical pre-decoder buffer size.
o [TS-26234]中定义的x-predecbufsize。此响应报头为RTSP代理提供TS 26.234附录G假设的预解码器缓冲区大小。
o x-initpredecbufperiod defined in [TS-26234]. This response-header provides an RTSP agent with the TS 26.234 Annex G hypothetical pre-decoder buffering period.
o [TS-26234]中定义的x-initpredecbufperiod。此响应报头为RTSP代理提供TS 26.234附录G假设的预解码器缓冲期。
o x-initpostdecbufperiod defined in [TS-26234]. This response-header provides an RTSP agent with the TS 26.234 Annex G post-decoder buffering period.
o [TS-26234]中定义的x-initpostdecbufperiod。此响应报头为RTSP代理提供TS 26.234附录G解码器后缓冲期。
o 3gpp-videopostdecbufsize defined in [TS-26234]. This response-header provides an RTSP agent with the TS 26.234 defined post-decoder buffer size usable for H.264 (AVC) video streams.
o [TS-26234]中定义的3gpp videopostdecbufsize。此响应报头为RTSP代理提供TS 26.234定义的解码器后缓冲区大小，可用于H.264（AVC）视频流。
o 3GPP-Link-Char defined in [TS-26234]. This request-header provides the RTSP server with the RTSP client's link characteristics as determined from the radio interface. The information that can be provided are guaranteed bitrate, maximum bitrate and maximum transfer delay.
o [TS-26234]中定义的3GPP链路字符。此请求标头向RTSP服务器提供RTSP客户端的链路特性，这些特性由无线电接口确定。可以提供的信息包括保证比特率、最大比特率和最大传输延迟。
o 3GPP-Adaptation defined in [TS-26234]. This general-header is part of the bitrate adaptation solution specified for the Packet-switched Streaming Service (PSS). It provides the RTSP client's buffer sizes and target buffer levels to the server, and responses are used to acknowledge the support and values.
o [TS-26234]中定义的3GPP适配。此通用报头是为分组交换流媒体服务（PSS）指定的比特率自适应解决方案的一部分。它向服务器提供RTSP客户端的缓冲区大小和目标缓冲区级别，并使用响应确认支持和值。
o 3GPP-QoE-Metrics defined in [TS-26234]. This general-header is used by PSS RTSP agents to negotiate the quality of experience metrics that a client should gather and report to the server.
o [TS-26234]中定义的3GPP QoE指标。PSS RTSP代理使用此通用标头协商客户机应收集并向服务器报告的体验质量度量。
o 3GPP-QoE-Feedback defined in [TS-26234]. This request-header is used by RTSP clients supporting PSS to report the actual values of the metrics gathered in its quality of experience metering.
o [TS-26234]中定义的3GPP QoE反馈。支持PSS的RTSP客户端使用此请求头报告在其体验质量度量中收集的度量的实际值。
The use of "x-" is NOT RECOMMENDED, but the above headers in the list were defined prior to the clarification.
不建议使用“x-”，但列表中的上述标题是在澄清之前定义的。
The security framework's TLS connection mechanism has two registerable entities.
安全框架的TLS连接机制有两个可注册实体。
This registry is for policies for an RTSP proxy's handling and verification of TLS certificates when establishing an outbound TLS connection on behalf of a client. In Section 19.3.1, three policies for how to handle certificates are specified. Further policies may be defined; registration is made through Standards Action [RFC5226]. A registration request is required to contain the following information:
此注册表用于RTSP代理在代表客户端建立出站TLS连接时处理和验证TLS证书的策略。在第19.3.1节中，规定了三种处理证书的策略。可确定进一步的政策；通过标准行动[RFC5226]进行注册。注册申请必须包含以下信息：
o Name of the policy.
o 保险单的名称。
o Text that describes how the policy works for handling the certificates.
o 描述策略如何处理证书的文本。
o A contact person.
o 联系人。
This specification registers the following values:
本规范登记了以下值：
Any: A policy requiring the proxy to accept any received certificate.
Any：要求代理接受任何收到的证书的策略。
Proxy: A policy where the proxy applies its own policies to determine which certificates are accepted.
代理：代理应用自己的策略来确定接受哪些证书的策略。
User: A policy where the certificate is required to be forwarded down the proxy chain to the client, thus allowing the user to decided to accept or refuse a certificate.
用户：一种策略，其中需要将证书沿代理链转发到客户端，从而允许用户决定接受或拒绝证书。
The Accept-Credentials header (see Section 18.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 cause interoperability problems. Therefore, the bar for registering new algorithms is intentionally placed high.
Accept Credentials标头（参见第18.2节）允许使用其他算法对接受实体的DER记录进行散列。任何未来算法的注册都极为罕见，还可能导致互操作性问题。因此，注册新算法的门槛被故意设置得很高。
Any registration of a new hash algorithm requires Standards Action [RFC5226]. The registration needs to fulfill the following requirement:
新哈希算法的任何注册都需要标准操作[RFC5226]。注册需要满足以下要求：
o The algorithms identifier meeting the "token" ABNF requirement.
o 满足“令牌”ABNF要求的算法标识符。
o Provide a definition of the algorithm.
o 提供算法的定义。
The registered value is:
注册价值为：
Hash Alg. ID Reference
------------------------
sha-256 RFC 7826
Hash Alg. ID Reference
------------------------
sha-256 RFC 7826
There exist a number of cache directives that can be sent in the Cache-Control header. A registry for these cache directives has been established by IANA. New registrations in this registry require Standards Action or IESG Approval [RFC5226]. A registration request needs to contain the following information.
存在许多可以在缓存控制标头中发送的缓存指令。IANA已经为这些缓存指令建立了一个注册表。此注册表中的新注册需要标准行动或IESG批准[RFC5226]。注册请求需要包含以下信息。
o The name of the cache directive.
o 缓存指令的名称。
o A definition of the parameter value, if any is allowed.
o 参数值的定义（如果允许）。
o The specification if it is a request or response directive.
o 如果是请求或响应指令，则说明。
o Text that explains how the cache directive is used for RTSP-controlled media streams.
o 解释缓存指令如何用于RTSP控制的媒体流的文本。
o A contact person.
o 联系人。
This specification registers the following values:
本规范登记了以下值：
no-cache:
无缓存：
public:
公众：
private:
私人：
no-transform:
无转换：
only-if-cached:
仅当缓存时：
max-stale:
最大过期时间：
min-fresh:
最小新鲜度：
must-revalidate:
必须重新验证：
proxy-revalidate:
代理重新验证日期：
max-age:
最大年龄：
The registry contains the name of the directive and the reference.
注册表包含指令和引用的名称。
The media streams being controlled by RTSP can have many different properties. The media properties required to cover the use cases that were in mind when writing the specification are defined. However, it can be expected that further innovation will result in new use cases or media streams with properties not covered by the ones specified here. Thus, new media properties can be specified. As new media properties may need a substantial amount of new definitions to correctly specify behavior for this property, the bar is intended to be high.
由RTSP控制的媒体流可以具有许多不同的属性。定义了覆盖编写规范时考虑的用例所需的介质属性。然而，可以预期，进一步的创新将产生新的用例或媒体流，其属性不在本文指定的属性中。因此，可以指定新的介质属性。由于新媒体属性可能需要大量新定义才能正确指定此属性的行为，因此该条应较高。
Registering a new media property is done following the Specification Required policy [RFC5226]. The expert reviewer verifies that a registration request fulfills the following requirements.
按照规范要求的策略[RFC5226]注册新媒体属性。专家评审员验证注册请求是否满足以下要求。
o An ABNF definition of the media property value name that meets "media-prop-ext" definition is included.
o 包括符合“媒体属性扩展”定义的媒体属性值名称的ABNF定义。
o A definition of which media property group it belongs to or define a new group is included.
o 包括它所属的媒体属性组的定义或定义新组的定义。
o A description of all changes to the behavior of RTSP as result of these changes is included.
o 包括由于这些更改而对RTSP行为所做的所有更改的描述。
o A contact person for the registration is listed.
o 登记的联系人已列出。
This specification registers the ten values listed in Section 18.29. The registry contains the property group, the name of the media property, and the reference.
本规范登记了第18.29节中列出的十个值。注册表包含属性组、媒体属性名称和引用。
Notify-Reason values are used to indicate the reason the notification was sent. Each reason has its associated rules on what headers and information may or must be included in the notification. New notification behaviors need to be specified to enable interoperable usage; thus, a specification of each new value is required.
通知原因值用于指示发送通知的原因。每个原因都有其相关规则，规定通知中可能包含或必须包含哪些标题和信息。需要指定新的通知行为以实现互操作使用；因此，需要对每个新值进行说明。
Registrations for new Notify-Reason values follow the Specification Required policy [RFC5226]. The expert reviewer verifies that the request fulfills the following requirements:
新通知原因值的注册遵循规范要求的策略[RFC5226]。专家评审员验证请求是否满足以下要求：
o An ABNF definition of the Notify-Reason value name that meets "Notify-Reason-extension" definition is included.
o 包括符合“通知原因扩展”定义的通知原因值名称的ABNF定义。
o A description of which headers shall be included in the request and response, when it should be sent, and any effect it has on the server client state is made clear.
o 说明请求和响应中应包含哪些标头，何时发送，以及对服务器客户端状态的任何影响。
o A contact person for the registration is listed.
o 登记的联系人已列出。
This specification registers three values defined in the Notify-Reas-val ABNF, Section 20.2.3:
本规范登记了Notify Reas val ABNF第20.2.3节中定义的三个值：
end-of-stream: This Notify-Reason value indicates the end of a media stream.
流结束：此通知原因值表示媒体流的结束。
media-properties-update: This Notify-Reason value allows the server to indicate that the properties of the media have changed during the playout.
媒体属性更新：此通知原因值允许服务器指示媒体属性在播放期间已更改。
scale-change: This Notify-Reason value allows the server to notify the client about a change in the scale of the media.
缩放更改：此Notify Reason值允许服务器向客户端通知媒体缩放的更改。
The registry contains the name, description, and reference.
注册表包含名称、说明和引用。
The Range header (Section 18.40) allows for different range formats. These range formats also need an identifier to be used in the Accept-Ranges header (Section 18.5). New range formats may be registered, but moderation should be applied as it makes interoperability more difficult.
范围标题（第18.40节）允许不同的范围格式。这些范围格式还需要在接受范围标题中使用标识符（第18.5节）。可能会注册新的范围格式，但应采用适度，因为这会增加互操作性的难度。
A registration follows the Specification Required policy [RFC5226]. The expert reviewer verifies that the request fulfills the following requirements:
注册遵循规范要求的策略[RFC5226]。专家评审员验证请求是否满足以下要求：
o An ABNF definition of the range format that fulfills the "range-ext" definition is included.
o 包括满足“范围扩展”定义的范围格式ABNF定义。
o The range format identifier used in Accept-Ranges header according to the "extension-format" definition is defined.
o 定义了根据“扩展格式”定义在接受范围标头中使用的范围格式标识符。
o Rules for how one handles the range when using a negative Scale are included.
o 包括使用负比例时如何处理范围的规则。
o A contact person for the registration is listed.
o 登记的联系人已列出。
The registry contains the Range header format identifier, the name of the range format, and the reference. This specification registers the following values.
注册表包含范围标头格式标识符、范围格式名称和引用。本规范注册了以下值。
npt: Normal Play Time
npt：正常播放时间
clock: UTC Absolute Time format
时钟：UTC绝对时间格式
smpte: SMPTE Timestamps
smpte:smpte时间戳
smpte-30-drop: SMPTE Timestamps 29.97 Frames/sec (30 Hz with Drop)
smpte-30-drop:smpte时间戳29.97帧/秒（30 Hz，带drop）
smpte-25: SMPTE Timestamps 25 Frames/sec
smpte-25:smpte时间戳25帧/秒
The Terminate-Reason header (Section 18.52) has two registries for extensions.
终止原因标头（第18.52节）有两个用于扩展的注册表。
This registry contains reasons for session termination that can be included in a Terminate-Reason header (Section 18.52). Registrations follow the Expert Review policy [RFC5226]. The expert reviewer verifies that the registration request contains the following information:
此注册表包含会话终止的原因，可包含在终止原因标题中（第18.52节）。注册遵循专家评审政策[RFC5226]。专家评审员验证注册请求是否包含以下信息：
o That the value follows the Terminate-Reason ABNF, i.e., be a token.
o 该值遵循终止原因ABNF，即为令牌。
o That the specification provide a definition of what procedures are to be followed when a client receives this redirect reason.
o 该规范提供了当客户端收到此重定向原因时应遵循的过程的定义。
o A contact person
o 联系人
This specification registers three values:
本规范登记了三个值：
o Session-Timeout
o 会话超时
o Server-Admin
o 服务器管理员
o Internal-Error
o 内部错误
The registry contains the name of the Redirect Reason and the reference.
注册表包含重定向原因和引用的名称。
This registry contains parameters that may be included in the Terminate-Reason header (Section 18.52) in addition to a reason. Registrations are made under the Specification Required policy [RFC5226]. The expert reviewer verifies that the registration request contains the following:
除原因外，此注册表还包含可能包含在终止原因标题（第18.52节）中的参数。根据规范要求政策[RFC5226]进行注册。专家评审员验证注册请求是否包含以下内容：
o A parameter name.
o 参数名。
o A parameter following the syntax allowed by the RTSP 2.0 specification.
o 遵循RTSP 2.0规范所允许语法的参数。
o A reference to the specification.
o 对规范的参考。
o A contact person.
o 联系人。
This specification registers:
本规范规定：
o time
o 时间
o user-msg
o 用户消息
The registry contains the name of the Terminate Reason and the reference.
注册表包含终止原因的名称和引用。
The RTP-Info header (Section 18.45) 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, new registration is made under the Specification Required policy.
RTP信息头（第18.45节）携带一个或多个参数值对，其中包含RTP流中特定点的信息。RTP扩展或新用法可能需要新类型的信息。由于可能需要的RTP信息可能具有足够的通用性，并且为了最大限度地提高互操作性，根据规范要求的策略进行了新的注册。
Registrations for new RTP-Info values follow the policy of Specification Required [RFC5226]. The expert reviewer verifies that the registration request contains the following information.
新RTP信息值的注册遵循所需规范的政策[RFC5226]。专家评审员验证注册请求是否包含以下信息。
o An ABNF definition that meets the "generic-param" definition.
o 符合“通用参数”定义的ABNF定义。
o A reference to the specification.
o 对规范的参考。
o A contact person for the registration.
o 注册联系人。
This specification registers the following parameter value pairs:
本规范注册了以下参数值对：
o url
o 网址
o ssrc
o ssrc
o seq
o 序号
o rtptime
o 时间
The registry contains the name of the parameter and the reference.
注册表包含参数和引用的名称。
Seek-Style policy defines how the RTSP agent seeks in media content when given a position within the media content. New seek policies may be registered; however, a large number of these will complicate implementation substantially. The impact of unknown policies is that the server will not honor the unknown and will use the server default policy instead.
Seek Style policy定义了RTSP代理在媒体内容中给定位置时如何查找媒体内容。可以注册新的seek策略；然而，其中的大量问题将使实现大大复杂化。未知策略的影响是服务器不会接受未知策略，而是使用服务器默认策略。
Registrations of new Seek-Style policies follow the Specification Required policy [RFC5226]. The expert reviewer verifies that the registration request fulfills the following requirements:
新Seek样式策略的注册遵循规范要求的策略[RFC5226]。专家评审员验证注册申请是否满足以下要求：
o Has an ABNF definition of the Seek-Style policy name that meets "Seek-S-value-ext" definition.
o 具有符合“Seek-S-value-ext”定义的Seek样式策略名称的ABNF定义。
o Includes a short description.
o 包括一个简短的描述。
o Lists a contact person for the registration.
o 列出注册的联系人。
o Includes a description of which headers shall be included in the request and response, when it should be sent, and any affect it has on the server-client state.
o 包括请求和响应中应包含哪些标头、何时发送以及对服务器客户端状态的任何影响的说明。
This specification registers four values (Name - Short Description):
本规范登记了四个值（名称-简短说明）：
o RAP - Using the closest Random Access Point prior to or at the requested start position.
o RAP-在请求的起始位置之前或处使用最近的随机接入点。
o CoRAP - Conditional Random Access Point is like RAP, but only if the RAP is closer prior to the requested start position than current pause point.
o CoRAP-条件随机接入点类似于RAP，但前提是RAP比当前暂停点更靠近请求的开始位置。
o First-Prior - The first-prior policy will start delivery with the media unit that has a playout time first prior to the requested start position.
o First Previor-First Previor策略将首先在请求的开始位置之前具有播放时间的媒体单元开始交付。
o Next - The next media units after the provided start position.
o Next（下一个）-提供的开始位置之后的下一个媒体单元。
The registry contains the name of the Seek-Style policy, the description, and the reference.
注册表包含搜索样式策略的名称、说明和引用。
The transport header (Section 18.54) contains a number of parameters that have possibilities for future extensions. Therefore, registries for these are defined below.
传输标题（第18.54节）包含许多参数，这些参数有可能在将来扩展。因此，下文对这些注册中心进行了定义。
A Transport Protocol specification consists of a transport protocol identifier, representing some combination of transport protocols, and any number of transport header parameters required or optional to use with the identified protocol specification. This registry contains the identifiers used by registered transport protocol identifiers.
传输协议规范由传输协议标识符（表示传输协议的某些组合）以及与所标识的协议规范一起使用所需或可选的任意数量的传输头参数组成。此注册表包含已注册的传输协议标识符使用的标识符。
A registration for the parameter transport protocol identifier follows the Specification Required policy [RFC5226]. The expert reviewer verifies that the registration request fulfills the following requirements:
参数传输协议标识符的注册遵循规范要求的策略[RFC5226]。专家评审员验证注册申请是否满足以下要求：
o A contact person or organization with address and email.
o 有地址和电子邮件的联系人或组织。
o A value definition that follows the ABNF syntax definition of "transport-id" Section 20.2.3.
o 值定义，遵循第20.2.3节“运输id”的ABNF语法定义。
o A descriptive text that explains how the registered values are used in RTSP, which underlying transport protocols are used, and any required Transport header parameters.
o 一种描述性文本，解释如何在RTSP中使用注册值、使用哪些底层传输协议以及任何必需的传输头参数。
The registry contains the protocol ID string and the reference.
注册表包含协议ID字符串和引用。
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 7826, Appendix C.1.
RTP/AVP：将RTP[RFC3550]协议用于媒体传输，并结合UDP上的“音频和视频会议的RTP配置文件”[RFC3551]。RFC 7826附录C.1中解释了该用法。
RTP/AVP/UDP: the same as RTP/AVP.
RTP/AVP/UDP：与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 7826, Appendix C.1.
RTP/AVPF：将RTP[RFC3550]协议用于媒体传输，并结合UDP上的“基于RTP的反馈扩展RTP配置文件（RTP/AVPF）”[RFC4585]。RFC 7826附录C.1中解释了该用法。
RTP/AVPF/UDP: the same as RTP/AVPF.
RTP/AVPF/UDP：与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 7826, Appendix C.1.
RTP/SAVP：将RTP[RFC3550]协议与UDP上的“安全实时传输协议（SRTP）”[RFC3711]结合使用进行媒体传输。RFC 7826附录C.1中解释了该用法。
RTP/SAVP/UDP: the same as RTP/SAVP.
RTP/SAVP/UDP：与RTP/SAVP相同。
RTP/SAVPF: Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] over UDP. The usage is explained in RFC 7826, Appendix C.1.
RTP/SAVPF：将RTP[RFC3550]协议用于媒体传输，并结合UDP上的“基于实时传输控制协议（RTCP）的反馈（RTP/SAVPF）的扩展安全RTP配置文件”[RFC5124]。RFC 7826附录C.1中解释了该用法。
RTP/SAVPF/UDP: the same as RTP/SAVPF.
RTP/SAVPF/UDP：与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 7826, Appendix C.2.2.
RTP/AVP/TCP：将RTP[RFC3550]协议用于媒体传输，并结合TCP上的“音频和视频会议的RTP配置文件”[RFC3551]。RFC 7826附录C.2.2解释了该用法。
RTP/AVPF/TCP: Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)" [RFC4585] over TCP. The usage is explained in RFC 7826, Appendix C.2.2.
RTP/AVPF/TCP：将RTP[RFC3550]协议用于媒体传输，并结合TCP上的“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）扩展RTP配置文件”[RFC4585]。RFC 7826附录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 7826, Appendix C.2.2.
RTP/SAVP/TCP：将RTP[RFC3550]协议与TCP上的“安全实时传输协议（SRTP）”[RFC3711]结合使用进行媒体传输。RFC 7826附录C.2.2解释了该用法。
RTP/SAVPF/TCP: Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ SAVPF)" [RFC5124] over TCP. The usage is explained in RFC 7826, Appendix C.2.2.
RTP/SAVPF/TCP：将RTP[RFC3550]协议用于媒体传输，并结合TCP上的“基于实时传输控制协议（RTCP）的反馈（RTP/SAVPF）扩展安全RTP配置文件”[RFC5124]。RFC 7826附录C.2.2解释了该用法。
The Transport Mode is a Transport header (Section 18.54) parameter. It is used to identify the general mode of media transport. The PLAY value registered defines a PLAYBACK mode, where media flows from server to client.
传输模式是一个传输标头（第18.54节）参数。它用于确定媒体传输的一般模式。注册的播放值定义了播放模式，在此模式下，媒体从服务器流向客户端。
A registration for the transport parameter mode follows the Standards Action policy [RFC5226]. The registration request needs to meet the following requirements:
传输参数模式的注册遵循标准操作策略[RFC5226]。注册申请需要满足以下要求：
o A value definition that follows the ABNF "token" definition Section 20.2.3.
o 遵循ABNF“令牌”定义第20.2.3节的值定义。
o Text that explains how the registered value is used in RTSP.
o 解释如何在RTSP中使用注册值的文本。
This specification registers one value:
本规范登记了一个值：
PLAY: See RFC 7826.
播放：参见RFC 7826。
The registry contains the transport mode value and the reference.
注册表包含传输模式值和引用。
Transport Parameters are different parameters used in a Transport header's transport specification (Section 18.54) to provide additional information required beyond the transport protocol identifier to establish a functioning transport.
传输参数是在传输头的传输规范（第18.54节）中使用的不同参数，用于提供传输协议标识符之外建立正常传输所需的附加信息。
A registration for parameters that may be included in the Transport header follows the Specification Required policy [RFC5226]. The expert reviewer verifies that the registration request fulfills the following requirements:
可能包含在传输报头中的参数的注册遵循规范要求的策略[RFC5226]。专家评审员验证注册申请是否满足以下要求：
o A Transport Parameter Name following the "token" ABNF definition.
o “令牌”ABNF定义后面的传输参数名称。
o A value definition, if the parameter takes a value, that follows the ABNF definition of "trn-par-value" Section 20.2.3.
o 如果参数采用值，则值定义遵循第20.2.3节“trn面值”的ABNF定义。
o Text that explains how the registered value is used in RTSP.
o 解释如何在RTSP中使用注册值的文本。
This specification registers all the transport parameters defined in Section 18.54. This is a copy of that list:
本规范登记了第18.54节中定义的所有运输参数。这是该列表的副本：
o unicast
o 单播
o multicast
o 多播
o interleaved
o 交错
o ttl
o ttl
o layers
o 层
o ssrc
o ssrc
o mode
o 模式
o dest_addr
o 目的地址
o src_addr
o 地址
o setup
o 设置
o connection
o 联系
o RTCP-mux
o RTCP多路复用器
o MIKEY
o 米奇
The registry contains the transport parameter name and the reference.
注册表包含传输参数名称和引用。
This specification updates two URI schemes: one previously registered, "rtsp", and one missing in the registry, "rtspu" (previously only defined in RTSP 1.0 [RFC2326]). One new URI scheme, "rtsps", is also registered. These URI schemes are registered in an existing registry ("Uniform Resource Identifier (URI) Schemes") not created by this memo. Registrations follow [RFC7595].
本规范更新了两个URI方案：一个以前注册的“rtsp”，另一个在注册表中丢失的“rtspu”（以前仅在rtsp 1.0[RFC2326]中定义）。还注册了一个新的URI方案“rtsps”。这些URI方案在现有注册表中注册（“统一资源标识符（URI）方案”），该注册表不是由此备忘录创建的。注册遵循[RFC7595]。
URI scheme name: rtsp
URI方案名称：rtsp
Status: Permanent
地位：永久
URI scheme syntax: See Section 20.2.1 of RFC 7826.
URI方案语法：见RFC 7826第20.2.1节。
URI scheme semantics: The rtsp scheme is used to indicate resources accessible through the usage of the Real-Time Streaming Protocol (RTSP). RTSP allows different operations on the resource identified by the URI, but the primary purpose is the streaming delivery of the resource to a client. However, the operations that are currently defined are DESCRIBE, GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, SETUP, SET_PARAMETER, and TEARDOWN.
URI方案语义：rtsp方案用于指示通过使用实时流协议（rtsp）可访问的资源。RTSP允许对URI标识的资源执行不同的操作，但主要目的是将资源流式交付给客户端。但是，当前定义的操作包括描述、获取参数、选项、播放、播放通知、暂停、重定向、设置、设置参数和拆卸。
Encoding considerations: IRIs in this scheme are defined and need to be encoded as RTSP URIs when used within RTSP. That encoding is done according to RFC 3987.
编码注意事项：此方案中的IRI已定义，在RTSP中使用时需要编码为RTSP URI。该编码是根据RFC 3987进行的。
Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 2326), RTSP 2.0 (RFC 7826).
使用此URI方案名称的应用程序/协议：RTSP 1.0（RFC 2326）、RTSP 2.0（RFC 7826）。
Interoperability considerations: The extensions in the URI syntax performed between RTSP 1.0 and 2.0 can create interoperability issues. The changes are:
互操作性注意事项：在RTSP 1.0和2.0之间执行的URI语法中的扩展可能会产生互操作性问题。这些变化是：
Support for IPv6 literals in the host part and future IP literals through a mechanism as defined in RFC 3986.
通过RFC 3986中定义的机制支持主机部分中的IPv6文本和未来的IP文本。
A new relative format to use in RTSP elements that is not required to start with "/".
RTSP元素中使用的新相对格式，不需要以“/”开头。
The above changes should have no impact on interoperability as discussed in detail in Section 4.2 of RFC 7826.
如RFC 7826第4.2节所详细讨论的，上述变更不应影响互操作性。
Security considerations: All the security threats identified in Section 7 of RFC 3986 also apply to this scheme. They need to be reviewed and considered in any implementation utilizing this scheme.
安全注意事项：RFC 3986第7节中确定的所有安全威胁也适用于此方案。在使用该方案的任何实施中，都需要对其进行审查和考虑。
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
联系人：Magnus Westerlund，Magnus。westerlund@ericsson.com
Author/Change controller: IETF
作者/变更控制员：IETF
References: RFC 2326, RFC 3986, RFC 3987, and RFC 7826
参考文献：RFC 2326、RFC 3986、RFC 3987和RFC 7826
URI scheme name: rtsps
URI方案名称：rtsps
Status: Permanent
地位：永久
URI scheme syntax: See Section 20.2.1 of RFC 7826.
URI方案语法：见RFC 7826第20.2.1节。
URI scheme semantics: The rtsps scheme is used to indicate resources accessible through the usage of the Real-Time Streaming Protocol (RTSP) over TLS. RTSP allows different operations on the resource identified by the URI, but the primary purpose is the streaming delivery of the resource to a client. However, the operations that are currently defined are DESCRIBE, GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, SETUP, SET_PARAMETER, and TEARDOWN.
URI方案语义：rtsps方案用于指示通过使用TLS上的实时流协议（RTSP）可访问的资源。RTSP允许对URI标识的资源执行不同的操作，但主要目的是将资源流式交付给客户端。但是，当前定义的操作包括描述、获取参数、选项、播放、播放通知、暂停、重定向、设置、设置参数和拆卸。
Encoding considerations: IRIs in this scheme are defined and need to be encoded as RTSP URIs when used within RTSP. That encoding is done according to RFC 3987.
编码注意事项：此方案中的IRI已定义，在RTSP中使用时需要编码为RTSP URI。该编码是根据RFC 3987进行的。
Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 2326), RTSP 2.0 (RFC 7826).
使用此URI方案名称的应用程序/协议：RTSP 1.0（RFC 2326）、RTSP 2.0（RFC 7826）。
Interoperability considerations: The "rtsps" scheme was never officially defined for RTSP 1.0; however, it has seen widespread use in actual deployments of RTSP 1.0. Therefore, this section discusses the believed changes between the unspecified RTSP 1.0 "rtsps" scheme and RTSP 2.0 definition. The extensions in the URI syntax performed between RTSP 1.0 and 2.0 can create interoperability issues. The changes are:
互操作性考虑：RTSP 1.0从未正式定义“rtsps”方案；然而，它在RTSP 1.0的实际部署中得到了广泛的应用。因此，本节讨论未指定RTSP 1.0“RTSP”方案和RTSP 2.0定义之间的变化。在RTSP 1.0和2.0之间执行的URI语法中的扩展可能会产生互操作性问题。这些变化是：
Support for IPv6 literals in the host part and future IP literals through a mechanism as defined by RFC 3986.
通过RFC 3986定义的机制支持主机部分中的IPv6文本和未来的IP文本。
A new relative format to use in RTSP elements that is not required to start with "/".
RTSP元素中使用的新相对格式，不需要以“/”开头。
The above changes should have no impact on interoperability as discussed in detail in Section 4.2 of RFC 7826.
如RFC 7826第4.2节所详细讨论的，上述变更不应影响互操作性。
Security considerations: All the security threats identified in Section 7 of RFC 3986 also apply to this scheme. They need to be reviewed and considered in any implementation utilizing this scheme.
安全注意事项：RFC 3986第7节中确定的所有安全威胁也适用于此方案。在使用该方案的任何实施中，都需要对其进行审查和考虑。
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
联系人：Magnus Westerlund，Magnus。westerlund@ericsson.com
Author/Change controller: IETF
作者/变更控制员：IETF
References: RFC 2326, RFC 3986, RFC 3987, and RFC 7826
参考文献：RFC 2326、RFC 3986、RFC 3987和RFC 7826
URI scheme name: rtspu
URI方案名称：rtspu
Status: Permanent
地位：永久
URI scheme syntax: See Section 3.2 of RFC 2326.
URI方案语法：参见RFC2326的第3.2节。
URI scheme semantics: The rtspu scheme is used to indicate resources accessible through the usage of the Real-Time Streaming Protocol (RTSP) over unreliable datagram transport. RTSP allows different operations on the resource identified by the URI, but the primary purpose is the streaming delivery of the resource to a client. However, the operations that are currently defined are DESCRIBE, GET_PARAMETER, OPTIONS, REDIRECT,PLAY, PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER, and TEARDOWN.
URI方案语义：rtspu方案用于指示通过在不可靠数据报传输上使用实时流协议（RTSP）可访问的资源。RTSP允许对URI标识的资源执行不同的操作，但主要目的是将资源流式交付给客户端。但是，当前定义的操作包括描述、获取参数、选项、重定向、播放、播放通知、暂停、设置、设置参数和拆卸。
Encoding considerations: This scheme is not intended to be used with characters outside the US-ASCII repertoire.
编码注意事项：此方案不适用于US-ASCII指令表之外的字符。
Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 2326).
使用此URI方案名称的应用程序/协议：RTSP 1.0（RFC 2326）。
Interoperability considerations: The definition of the transport mechanism of RTSP over UDP has interoperability issues. That makes the usage of this scheme problematic.
互操作性注意事项：UDP上RTSP传输机制的定义存在互操作性问题。这使得该方案的使用成了问题。
Security considerations: All the security threats identified in Section 7 of RFC 3986 also apply to this scheme. They need to be reviewed and considered in any implementation utilizing this scheme.
安全注意事项：RFC 3986第7节中确定的所有安全威胁也适用于此方案。在使用该方案的任何实施中，都需要对其进行审查和考虑。
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
联系人：Magnus Westerlund，Magnus。westerlund@ericsson.com
Author/Change controller: IETF
作者/变更控制员：IETF
References: RFC 2326
参考文献：RFC2326
This specification defines three SDP [RFC4566] attributes that have been registered by IANA.
本规范定义了IANA已注册的三个SDP[RFC4566]属性。
SDP Attribute ("att-field"):
SDP属性（“att字段”）：
Attribute name: range Long form: Media Range Attribute Type of name: att-field Type of attribute: both session and media level Subject to charset: No Purpose: RFC 7826 Reference: RFC 2326, RFC 7826 Values: See ABNF definition.
属性名称：范围长格式：媒体范围属性名称类型：att字段属性类型：会话和媒体级别根据字符集：无用途：RFC 7826参考：RFC 2326，RFC 7826值：请参阅ABNF定义。
Attribute name: control Long form: RTSP control URI Type of name: att-field Type of attribute: both session and media level Subject to charset: No Purpose: RFC 7826 Reference: RFC 2326, RFC 7826 Values: Absolute or Relative URIs.
属性名称：控件长格式：RTSP控件URI名称类型：att字段属性类型：会话和媒体级别受字符集约束：无用途：RFC 7826引用：RFC 2326，RFC 7826值：绝对或相对URI。
Attribute name: mtag Long form: Message Tag Type of name: att-field Type of attribute: both session and media level Subject to charset: No Purpose: RFC 7826 Reference: RFC 7826 Values: See ABNF definition
属性名称：mtag长格式：消息标记名称类型：att字段属性类型：会话和媒体级别受字符集约束：无用途：RFC 7826参考：RFC 7826值：请参阅ABNF定义
Type name: text
类型名称：text
Subtype name: parameters
子类型名称：参数
Required parameters:
所需参数：
Optional parameters: charset: The charset parameter is applicable to the encoding of the parameter values. The default charset is UTF-8, if the 'charset' parameter is not present.
可选参数：charset：charset参数适用于参数值的编码。如果“charset”参数不存在，则默认字符集为UTF-8。
Encoding considerations: 8bit
编码注意事项：8位
Security considerations: This format may carry any type of parameters. Some can have security requirements, like privacy, confidentiality, or integrity requirements. The format has no built-in security protection. For the usage, the transport can be protected between server and client using TLS. However, care must be taken to consider if the proxies are also trusted with the parameters in case hop-by-hop security is used. If stored as a file in a file system, the necessary precautions need to be taken in relation to the parameter requirements including object security such as S/MIME [RFC5751].
安全注意事项：此格式可以携带任何类型的参数。有些可能有安全要求，如隐私、机密性或完整性要求。该格式没有内置的安全保护。对于使用，可以使用TLS在服务器和客户端之间保护传输。然而，必须小心考虑代理是否也被信任的参数，在使用逐跳安全的情况下。如果作为文件存储在文件系统中，则需要针对参数要求采取必要的预防措施，包括对象安全性，如S/MIME[RFC5751]。
Interoperability considerations: This media type was mentioned as a fictional example in [RFC2326], but was not formally specified. This has resulted in usage of this media type that may not match its formal definition.
互操作性注意事项：此媒体类型在[RFC2326]中作为虚构的示例提到，但没有正式指定。这导致使用此媒体类型可能与其正式定义不匹配。
Published specification: RFC 7826, Appendix F.
已发布规范：RFC 7826，附录F。
Applications that use this media type: Applications that use RTSP and have additional parameters they like to read and set using the RTSP GET_PARAMETER and SET_PARAMETER methods.
使用此媒体类型的应用程序：使用RTSP的应用程序，并且具有使用RTSP GET_参数和set_参数方法读取和设置的附加参数。
Additional information:
其他信息：
Magic number(s): N/A
Magic number(s): N/A
File extension(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information: Magnus Westerlund (magnus.westerlund@ericsson.com)
联系人和电子邮件地址，以获取更多信息：Magnus Westerlund（Magnus。westerlund@ericsson.com)
Intended usage: Common
预期用途：普通
Restrictions on usage: None
使用限制：无
Author: Magnus Westerlund (magnus.westerlund@ericsson.com)
作者：Magnus Westerlund（Magnus。westerlund@ericsson.com)
Change controller: IETF
更改控制器：IETF
Addition Notes:
补充说明：
[FIPS180-4] National Institute of Standards and Technology (NIST), "Federal Information Processing Standards Publication: Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.
[FIPS180-4]国家标准与技术研究所（NIST），“联邦信息处理标准出版物：安全哈希标准（SHS）”，DOI 10.6028/NIST.FIPS.180-42015年8月<http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，DOI 10.17487/RFC0768，1980年8月<http://www.rfc-editor.org/info/rfc768>.
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793]Postel，J.，“传输控制协议”，标准7，RFC 793，DOI 10.17487/RFC0793，1981年9月<http://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, <http://www.rfc-editor.org/info/rfc2616>.
[RFC2616]Fielding，R.，Gettys，J.，Mogul，J.，Frystyk，H.，Masinter，L.，Leach，P.，和T.Berners Lee，“超文本传输协议——HTTP/1.1”，RFC 2616，DOI 10.17487/RFC2616，1999年6月<http://www.rfc-editor.org/info/rfc2616>.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, DOI 10.17487/RFC2617, June 1999, <http://www.rfc-editor.org/info/rfc2617>.
[RFC2617]Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 2617，DOI 10.17487/RFC2617，1999年6月<http://www.rfc-editor.org/info/rfc2617>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818]Rescorla，E.，“TLS上的HTTP”，RFC 2818，DOI 10.17487/RFC2818，2000年5月<http://www.rfc-editor.org/info/rfc2818>.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550]Schulzrinne，H.，Casner，S.，Frederick，R.，和V.Jacobson，“RTP：实时应用的传输协议”，STD 64，RFC 3550，DOI 10.17487/RFC3550，2003年7月<http://www.rfc-editor.org/info/rfc3550>.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <http://www.rfc-editor.org/info/rfc3551>.
[RFC3551]Schulzrinne，H.和S.Casner，“具有最小控制的音频和视频会议的RTP配置文件”，STD 65，RFC 3551，DOI 10.17487/RFC3551，2003年7月<http://www.rfc-editor.org/info/rfc3551>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 3711，DOI 10.17487/RFC3711，2004年3月<http://www.rfc-editor.org/info/rfc3711>.
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, DOI 10.17487/RFC3830, August 2004, <http://www.rfc-editor.org/info/rfc3830>.
[RFC3830]Arkko，J.，Carrara，E.，Lindholm，F.，Naslund，M.，和K.Norrman，“米奇：多媒体互联网键控”，RFC 3830，DOI 10.17487/RFC3830，2004年8月<http://www.rfc-editor.org/info/rfc3830>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <http://www.rfc-editor.org/info/rfc3987>.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，DOI 10.17487/RFC3987，2005年1月<http://www.rfc-editor.org/info/rfc3987>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086]Eastlake 3rd，D.，Schiller，J.，和S.Crocker，“安全的随机性要求”，BCP 106，RFC 4086，DOI 10.17487/RFC4086，2005年6月<http://www.rfc-editor.org/info/rfc4086>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 4291，DOI 10.17487/RFC42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <http://www.rfc-editor.org/info/rfc7595>.
[RFC7595]Thaler，D.，Ed.，Hansen，T.和T.Hardie，“URI方案的指南和注册程序”，BCP 35，RFC 7595，DOI 10.17487/RFC7595，2015年6月<http://www.rfc-editor.org/info/rfc7595>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC 4566，DOI 10.17487/RFC4566，2006年7月<http://www.rfc-editor.org/info/rfc4566>.
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 2006, <http://www.rfc-editor.org/info/rfc4571>.
[RFC4571]Lazzaro，J.，“面向连接传输上的帧实时传输协议（RTP）和RTP控制协议（RTCP）数据包”，RFC 4571，DOI 10.17487/RFC4571，2006年7月<http://www.rfc-editor.org/info/rfc4571>.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585]Ott，J.，Wenger，S.，Sato，N.，Burmeister，C.，和J.Rey，“基于实时传输控制协议（RTCP）的反馈（RTP/AVPF）的扩展RTP配置文件”，RFC 4585，DOI 10.17487/RFC4585，2006年7月<http://www.rfc-editor.org/info/rfc4585>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648]Josefsson，S.，“Base16、Base32和Base64数据编码”，RFC 4648，DOI 10.17487/RFC4648，2006年10月<http://www.rfc-editor.org/info/rfc4648>.
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, DOI 10.17487/RFC4738, November 2006, <http://www.rfc-editor.org/info/rfc4738>.
[RFC4738]Ignjatic，D.，Dondeti，L.，Audet，F.，和P.Lin，“MIKEY-RSA-R：多媒体互联网密钥分配（MIKEY）中的另一种密钥分配模式”，RFC 4738，DOI 10.17487/RFC4738，2006年11月<http://www.rfc-editor.org/info/rfc4738>.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124]Ott，J.和E.Carrara，“基于实时传输控制协议（RTCP）的反馈扩展安全RTP配置文件（RTP/SAVPF）”，RFC 5124DOI 10.17487/RFC5124，2008年2月<http://www.rfc-editor.org/info/rfc5124>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，DOI 10.17487/RFC5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，DOI 10.17487/RFC5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<http://www.rfc-editor.org/info/rfc5246>.
[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, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280]Cooper，D.，Santesson，S.，Farrell，S.，Boeyen，S.，Housley，R.，和W.Polk，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 5280，DOI 10.17487/RFC5280，2008年5月<http://www.rfc-editor.org/info/rfc5280>.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322]Resnick，P.，Ed.，“互联网信息格式”，RFC 5322，DOI 10.17487/RFC5322，2008年10月<http://www.rfc-editor.org/info/rfc5322>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <http://www.rfc-editor.org/info/rfc5646>.
[RFC5646]Phillips，A.，Ed.和M.Davis，Ed.，“识别语言的标签”，BCP 47，RFC 5646，DOI 10.17487/RFC5646，2009年9月<http://www.rfc-editor.org/info/rfc5646>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC5751]Ramsdell，B.和S.Turner，“安全/多用途Internet邮件扩展（S/MIME）版本3.2消息规范”，RFC 5751，DOI 10.17487/RFC5751，2010年1月<http://www.rfc-editor.org/info/rfc5751>.
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <http://www.rfc-editor.org/info/rfc5761>.
[RFC5761]Perkins，C.和M.Westerlund，“在单个端口上多路复用RTP数据和控制数据包”，RFC 5761，DOI 10.17487/RFC5761，2010年4月<http://www.rfc-editor.org/info/rfc5761>.
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, <http://www.rfc-editor.org/info/rfc5888>.
[RFC5888]Camarillo，G.和H.Schulzrinne，“会话描述协议（SDP）分组框架”，RFC 5888，DOI 10.17487/RFC5888，2010年6月<http://www.rfc-editor.org/info/rfc5888>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838]Freed，N.，Klensin，J.和T.Hansen，“介质类型规范和注册程序”，BCP 13，RFC 6838，DOI 10.17487/RFC6838，2013年1月<http://www.rfc-editor.org/info/rfc6838>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，DOI 10.17487/RFC7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 7231，DOI 10.17487/RFC72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：有条件请求”，RFC 7232，DOI 10.17487/RFC72322014年6月<http://www.rfc-editor.org/info/rfc7232>.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, <http://www.rfc-editor.org/info/rfc7233>.
[RFC7233]Fielding，R.，Ed.，Lafon，Y.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：范围请求”，RFC 7233，DOI 10.17487/RFC7233，2014年6月<http://www.rfc-editor.org/info/rfc7233>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
[RFC7234]Fielding，R.，Ed.，Nottingham，M.，Ed.，和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：缓存”，RFC 7234，DOI 10.17487/RFC72342014年6月<http://www.rfc-editor.org/info/rfc7234>.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：认证”，RFC 7235，DOI 10.17487/RFC7235，2014年6月<http://www.rfc-editor.org/info/rfc7235>.
[RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields", RFC 7615, DOI 10.17487/RFC7615, September 2015, <http://www.rfc-editor.org/info/rfc7615>.
[RFC7615]Reschke，J.，“HTTP身份验证信息和代理身份验证信息响应头字段”，RFC 7615，DOI 10.17487/RFC7615，2015年9月<http://www.rfc-editor.org/info/rfc7615>.
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <http://www.rfc-editor.org/info/rfc7616>.
[RFC7616]Shekh Yusef，R.，Ed.，Ahrens，D.，和S.Bremer，“HTTP摘要访问认证”，RFC 7616，DOI 10.17487/RFC76162015年9月<http://www.rfc-editor.org/info/rfc7616>.
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <http://www.rfc-editor.org/info/rfc7617>.
[RFC7617]Reschke，J.“基本”HTTP认证方案”，RFC 7617，DOI 10.17487/RFC76172015年9月<http://www.rfc-editor.org/info/rfc7617>.
[RFC7825] Goldberg, J., Westerlund, M., and T. Zeng, "A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by Real-Time Streaming Protocol (RTSP)", RFC 7825, DOI 10.17487/RFC7825, December 2016, <http://www.rfc-editor.org/info/rfc7825>.
[RFC7825]Goldberg，J.，Westerlund，M.，和T.Zeng，“由实时流协议（RTSP）控制的媒体的网络地址转换器（NAT）遍历机制”，RFC 7825，DOI 10.17487/RFC7825，2016年12月<http://www.rfc-editor.org/info/rfc7825>.
[RTP-CIRCUIT-BREAKERS] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", Work in Progress, draft-ietf-avtcore-rtp-circuit-breakers-13, February 2016.
[RTP-断路器]Perkins，C.和V.Singh，“多媒体拥塞控制：单播RTP会话断路器”，正在进行的工作，草稿-ietf-avtcore-RTP-断路器-13，2016年2月。
[SMPTE-TC] Society of Motion Picture and Television Engineers, "ST 12-1:2008 For Television -- Time and Control Code", DOI 10.5594/SMPTE.ST12-1.2008, February 2008, <http://ieeexplore.ieee.org/servlet/ opac?punumber=7289818>.
[SMPTE-TC]电影和电视工程师学会，“ST 12-1:2008电视——时间和控制代码”，DOI 10.5594/SMPTE.ST12-1.2008，2008年2月<http://ieeexplore.ieee.org/servlet/ opac？punumber=7289818>。
[TS-26234] 3rd Generation Partnership Project (3GPP), "Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs", Technical Specification 26.234, Release 13, September 2015, <http://www.3gpp.org/DynaReport/26234.htm>.
[TS-26234]第三代合作伙伴项目（3GPP），“透明端到端分组交换流媒体服务（PSS）；协议和编解码器”，技术规范26.234，第13版，2015年9月<http://www.3gpp.org/DynaReport/26234.htm>.
[ISO.13818-6.1995] International Organization for Standardization, "Information technology -- Generic coding of moving pictures and associated audio information - part 6: Extension for DSM-CC", ISO Draft Standard 13818-6:1998, October 1998, <http://www.iso.org/iso/home/store/catalogue_tc/ catalogue_detail.htm?csnumber=25039>.
[ISO.13818-6.1995]国际标准化组织，“信息技术——运动图像和相关音频信息的通用编码——第6部分：DSM-CC的扩展”，ISO标准草案13818-6:1998，1998年10月<http://www.iso.org/iso/home/store/catalogue_tc/ 目录\u detail.htm？csnumber=25039>。
[ISO.8601.2000] International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO/IEC Standard 8601, December 2000.
[ISO.8601.2000]国际标准化组织，“数据元素和交换格式-信息交换-日期和时间的表示”，ISO/IEC标准86012000年12月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791]Postel，J.，“互联网协议”，STD 5，RFC 791，DOI 10.17487/RFC07911981年9月<http://www.rfc-editor.org/info/rfc791>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <http://www.rfc-editor.org/info/rfc1123>.
[RFC1123]Braden，R.，Ed.“互联网主机的要求-应用和支持”，STD 3，RFC 1123，DOI 10.17487/RFC1123，1989年10月<http://www.rfc-editor.org/info/rfc1123>.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, DOI 10.17487/RFC2068, January 1997, <http://www.rfc-editor.org/info/rfc2068>.
[RFC2068]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，DOI 10.17487/RFC2068，1997年1月<http://www.rfc-editor.org/info/rfc2068>.
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, DOI 10.17487/RFC2326, April 1998, <http://www.rfc-editor.org/info/rfc2326>.
[RFC2326]Schulzrinne，H.，Rao，A.，和R.Lanphier，“实时流协议（RTSP）”，RFC 2326，DOI 10.17487/RFC2326，1998年4月<http://www.rfc-editor.org/info/rfc2326>.
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <http://www.rfc-editor.org/info/rfc2663>.
[RFC2663]Srisuresh，P.和M.Holdrege，“IP网络地址转换器（NAT）术语和注意事项”，RFC 2663，DOI 10.17487/RFC2663，1999年8月<http://www.rfc-editor.org/info/rfc2663>.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <http://www.rfc-editor.org/info/rfc2974>.
[RFC2974]Handley，M.，Perkins，C.，和E.Whelan，“会话公告协议”，RFC 2974，DOI 10.17487/RFC2974，2000年10月<http://www.rfc-editor.org/info/rfc2974>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，DOI 10.17487/RFC3261，2002年6月<http://www.rfc-editor.org/info/rfc3261>.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264]Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，DOI 10.17487/RFC3264，2002年6月<http://www.rfc-editor.org/info/rfc3264>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>.
[RFC3339]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，DOI 10.17487/RFC3339，2002年7月<http://www.rfc-editor.org/info/rfc3339>.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, <http://www.rfc-editor.org/info/rfc4145>.
[RFC4145]Yon，D.和G.Camarillo，“会话描述协议（SDP）中基于TCP的媒体传输”，RFC 4145，DOI 10.17487/RFC4145，2005年9月<http://www.rfc-editor.org/info/rfc4145>.
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, DOI 10.17487/RFC4567, July 2006, <http://www.rfc-editor.org/info/rfc4567>.
[RFC4567]Arkko，J.，Lindholm，F.，Naslund，M.，Norrman，K.，和E.Carrara，“会话描述协议（SDP）和实时流协议（RTSP）的密钥管理扩展”，RFC 4567，DOI 10.17487/RFC4567，2006年7月<http://www.rfc-editor.org/info/rfc4567>.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <http://www.rfc-editor.org/info/rfc4588>.
[RFC4588]Rey，J.，Leon，D.，Miyazaki，A.，Varsa，V.，和R.Hakenberg，“RTP重传有效载荷格式”，RFC 4588，DOI 10.17487/RFC4588，2006年7月<http://www.rfc-editor.org/info/rfc4588>.
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, <http://www.rfc-editor.org/info/rfc4855>.
[RFC4855]Casner，S.，“RTP有效载荷格式的媒体类型注册”，RFC 4855，DOI 10.17487/RFC4855，2007年2月<http://www.rfc-editor.org/info/rfc4855>.
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, DOI 10.17487/RFC4856, February 2007, <http://www.rfc-editor.org/info/rfc4856>.
[RFC4856]Casner，S.，“音频和视频会议RTP配置文件中有效载荷格式的媒体类型注册”，RFC 4856，DOI 10.17487/RFC4856，2007年2月<http://www.rfc-editor.org/info/rfc4856>.
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5104]Wenger，S.，Chandra，U.，Westerlund，M.，和B.Burman，“带反馈的RTP视听配置文件（AVPF）中的编解码器控制消息”，RFC 5104，DOI 10.17487/RFC5104，2008年2月<http://www.rfc-editor.org/info/rfc5104>.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245]Rosenberg，J.，“交互式连接建立（ICE）：提供/应答协议的网络地址转换器（NAT）遍历协议”，RFC 5245，DOI 10.17487/RFC5245，2010年4月<http://www.rfc-editor.org/info/rfc5245>.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT（STUN）的会话遍历实用程序”，RFC 5389，DOI 10.17487/RFC5389，2008年10月<http://www.rfc-editor.org/info/rfc5389>.
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, DOI 10.17487/RFC5583, July 2009, <http://www.rfc-editor.org/info/rfc5583>.
[RFC5583]Schierl，T.和S.Wenger，“会话描述协议（SDP）中的信令媒体解码依赖性”，RFC 5583，DOI 10.17487/RFC5583，2009年7月<http://www.rfc-editor.org/info/rfc5583>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.
[RFC5905]Mills，D.，Martin，J.，Ed.，Burbank，J.，和W.Kasch，“网络时间协议版本4：协议和算法规范”，RFC 5905，DOI 10.17487/RFC59052010年6月<http://www.rfc-editor.org/info/rfc5905>.
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <http://www.rfc-editor.org/info/rfc6298>.
[RFC6298]Paxson，V.，Allman，M.，Chu，J.，和M.Sargent，“计算TCP的重传计时器”，RFC 6298，DOI 10.17487/RFC62982011年6月<http://www.rfc-editor.org/info/rfc6298>.
[Stevens98] Stevens, W., Fenner, B., and A. Rudoff, "Unix Networking Programming, Volume 1: The Sockets Networking API (3rd Edition)", 1998.
[Stevens98]Stevens，W.，Fenner，B.，和A.Rudoff，“Unix网络编程，第1卷：套接字网络API（第3版）”，1998年。
This section contains several different examples trying to illustrate possible ways of using RTSP. The examples can also help with the understanding of how functions of RTSP work. However, remember that these are examples and the normative and syntax descriptions in the other sections take precedence. Please also note that many of the examples have been broken into several lines, where following lines start with whitespace as allowed by the syntax.
本节包含几个不同的示例，试图说明使用RTSP的可能方法。这些示例还有助于理解RTSP的功能是如何工作的。但是，请记住，这些都是示例，其他章节中的规范性和语法描述优先。还请注意，许多示例已被分成几行，其中以下几行以语法允许的空格开头。
This is an example of media-on-demand streaming of media stored in a container file. For the purposes of this example, a container file is a storage entity in which multiple continuous media types pertaining to the same end-user presentation are present. In effect, the container file represents an RTSP presentation, with each of its components being RTSP-controlled media streams. Container files are a widely used means to store such presentations. While the components are transported as independent streams, it is desirable to maintain a common context for those streams at the server end.
这是存储在容器文件中的媒体按需流媒体的示例。在本示例中，容器文件是一种存储实体，其中存在与同一最终用户演示文稿相关的多个连续介质类型。实际上，容器文件表示RTSP表示，其每个组件都是RTSP控制的媒体流。容器文件是存储此类演示文稿的一种广泛使用的方法。当组件作为独立流传输时，希望在服务器端维护这些流的公共上下文。
This enables the server to keep a single storage handle open easily. It also allows treating all the streams equally in case of any prioritization of streams by the server.
这使服务器能够轻松地打开单个存储句柄。它还允许在服务器对流进行任何优先级排序的情况下平等地处理所有流。
It is also possible that the presentation author may wish to prevent selective retrieval of the streams by the client in order to preserve the artistic effect of the combined media presentation. Similarly, in such a tightly bound presentation, it is desirable to be able to control all the streams via a single control message using an aggregate URI.
演示文稿作者还可能希望防止客户端选择性地检索流，以保持组合媒体演示文稿的艺术效果。类似地，在这种紧密绑定的表示中，希望能够通过使用聚合URI的单个控制消息来控制所有流。
The following is an example of using a single RTSP session to control multiple streams. It also illustrates the use of aggregate URIs. In a container file, it is also desirable not to write any URI parts that are not kept when the container is distributed, like the host and most of the path element. Therefore, this example also uses the "*" and relative URI in the delivered SDP.
以下是使用单个RTSP会话控制多个流的示例。它还说明了聚合URI的使用。在容器文件中，也不希望写入容器分发时未保留的任何URI部分，如主机和大部分path元素。因此，本例还使用了交付的SDP中的“*”和相对URI。
Also, this presentation description (SDP) is not cacheable, as the Expires header is set to an equal value with date indicating immediate expiration of its validity.
此外，此演示文稿描述（SDP）不可缓存，因为Expires标头设置为与date相等的值，date指示其有效性立即过期。
Client C requests a presentation from media server M. The movie is stored in a container file. The client has obtained an RTSP URI to the container file.
客户端C从媒体服务器M请求演示文稿。电影存储在容器文件中。客户端已获得容器文件的RTSP URI。
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:32 +0000
Content-Type: application/sdp
Content-Length: 271
Content-Base: rtsp://example.com/twister.3gp/
Expires: Fri, 20 Dec 2013 12:20:32 +0000
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:32 +0000
Content-Type: application/sdp
Content-Length: 271
Content-Base: rtsp://example.com/twister.3gp/
Expires: Fri, 20 Dec 2013 12:20:32 +0000
v=0
o=- 2890844256 2890842807 IN IP4 198.51.100.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
c=IN IP4 0.0.0.0
a=control: *
a=range:npt=00:00:00-00:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
m=video 0 RTP/AVP 26
a=control: trackID=4
v=0
o=- 2890844256 2890842807 IN IP4 198.51.100.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
c=IN IP4 0.0.0.0
a=control: *
a=range:npt=00:00:00-00:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
m=video 0 RTP/AVP 26
a=control: trackID=4
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: npt, smpte, clock
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: npt, smpte, clock
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast; ssrc=93CB001E;
dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="198.51.100.5:9000"/"198.51.100.5:9001"
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:20:33 +0000
Date: Fri, 20 Dec 2013 10:20:33 +0000
Accept-Ranges: npt
Media-Properties: Random-Access=0.02, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast; ssrc=93CB001E;
dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="198.51.100.5:9000"/"198.51.100.5:9001"
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:20:33 +0000
Date: Fri, 20 Dec 2013 10:20:33 +0000
Accept-Ranges: npt
Media-Properties: Random-Access=0.02, Immutable, Unlimited
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Session: OccldOFFq23KwjYpAnBbUr
Accept-Ranges: npt, smpte, clock
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Session: OccldOFFq23KwjYpAnBbUr
Accept-Ranges: npt, smpte, clock
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast; ssrc=A813FC13;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003";
src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast; ssrc=A813FC13;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003";
src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:20:33 +0000
Date: Fri, 20 Dec 2013 10:20:33 +0000
Accept-Range: NPT
Media-Properties: Random-Access=0.8, Immutable, Unlimited
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:20:33 +0000
Date: Fri, 20 Dec 2013 10:20:33 +0000
Accept-Range: NPT
Media-Properties: Random-Access=0.8, Immutable, Unlimited
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=30-
Seek-Style: RAP
Session: OccldOFFq23KwjYpAnBbUr
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=30-
Seek-Style: RAP
Session: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:34 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30-634.10
Seek-Style: RAP
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:34 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30-634.10
Seek-Style: RAP
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889
C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 5
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 5
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
# Pause happens 0.87 seconds after starting to play
#暂停发生在开始播放后0.87秒
M->C: RTSP/2.0 200 OK
CSeq: 5
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:35 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30.87-634.10
M->C: RTSP/2.0 200 OK
CSeq: 5
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:35 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30.87-634.10
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 6
User-Agent: PhonyClient/1.2
Range: npt=30.87-634.10
Seek-Style: Next
Session: OccldOFFq23KwjYpAnBbUr
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 6
User-Agent: PhonyClient/1.2
Range: npt=30.87-634.10
Seek-Style: Next
Session: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK
CSeq: 6
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:22:13 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30.87-634.10
Seek-Style: Next
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12555;rtptime=6330012,
url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=55021;rtptime=3132889
M->C: RTSP/2.0 200 OK
CSeq: 6
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:22:13 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30.87-634.10
Seek-Style: Next
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12555;rtptime=6330012,
url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=55021;rtptime=3132889
C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 7
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 7
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK
CSeq: 7
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:31:53 +0000
M->C: RTSP/2.0 200 OK
CSeq: 7
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:31:53 +0000
This example is basically the example above (Appendix A.1), but now utilizing pipelining to speed up the setup. It requires only two round-trip times until the media starts flowing. First of all, the session description is retrieved to determine what media resources need to be set up. In the second step, one sends the necessary SETUP requests and the PLAY request to initiate media delivery.
此示例基本上与上面的示例（附录A.1）相同，但现在使用管道来加速设置。它只需要两次往返时间，直到介质开始流动。首先，检索会话描述以确定需要设置哪些媒体资源。在第二步中，发送必要的设置请求和播放请求以启动媒体传送。
Client C requests a presentation from media server M. The movie is stored in a container file. The client has obtained an RTSP URI to the container file.
客户端C从媒体服务器M请求演示文稿。电影存储在容器文件中。客户端已获得容器文件的RTSP URI。
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:32 +0000
Content-Type: application/sdp
Content-Length: 271
Content-Base: rtsp://example.com/twister.3gp/
Expires: Fri, 20 Dec 2013 12:20:32 +0000
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:32 +0000
Content-Type: application/sdp
Content-Length: 271
Content-Base: rtsp://example.com/twister.3gp/
Expires: Fri, 20 Dec 2013 12:20:32 +0000
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
c=IN IP4 0.0.0.0
a=control: *
a=range:npt=00:00:00-00:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
m=video 0 RTP/AVP 26
a=control: trackID=4
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
c=IN IP4 0.0.0.0
a=control: *
a=range:npt=00:00:00-00:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
m=video 0 RTP/AVP 26
a=control: trackID=4
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: npt, smpte, clock
Pipelined-Requests: 7654
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: npt, smpte, clock
Pipelined-Requests: 7654
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Accept-Ranges: npt, smpte, clock
Pipelined-Requests: 7654
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Accept-Ranges: npt, smpte, clock
Pipelined-Requests: 7654
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=0-
Seek-Style: RAP
Pipelined-Requests: 7654
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=0-
Seek-Style: RAP
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;
dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="198.51.100.5:9000"/"198.51.100.5:9001";
ssrc=93CB001E
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:20:32 +0000
Date: Fri, 20 Dec 2013 10:20:32 +0000
Accept-Ranges: npt
Pipelined-Requests: 7654
Media-Properties: Random-Access=0.2, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;
dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="198.51.100.5:9000"/"198.51.100.5:9001";
ssrc=93CB001E
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:20:32 +0000
Date: Fri, 20 Dec 2013 10:20:32 +0000
Accept-Ranges: npt
Pipelined-Requests: 7654
Media-Properties: Random-Access=0.2, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003;
src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
ssrc=A813FC13
Session: OccldOFFq23KwjYpAnBbUr
Expires: Sat, 21 Dec 2013 10:20:32 +0000
Date: Fri, 20 Dec 2013 10:20:32 +0000
Accept-Range: NPT
Pipelined-Requests: 7654
Media-Properties: Random-Access=0.8, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003;
src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
ssrc=A813FC13
Session: OccldOFFq23KwjYpAnBbUr
Expires: Sat, 21 Dec 2013 10:20:32 +0000
Date: Fri, 20 Dec 2013 10:20:32 +0000
Accept-Range: NPT
Pipelined-Requests: 7654
Media-Properties: Random-Access=0.8, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:32 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=0-623.10
Seek-Style: RAP
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:32 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=0-623.10
Seek-Style: RAP
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889
Pipelined-Requests: 7654
This example is basically the above example (Appendix A.2), but now including establishment of SRTP crypto contexts to get a secured media delivery. First of all, the client attempts to fetch this insecurely, but the server redirects to a URI indicating a requirement on using a secure connection for the RTSP messages. The client establishes a TCP/TLS connection, and the session description is retrieved to determine what media resources need to be set up. In the this session description, secure media (SRTP) is indicated. In the next step, the client sends the necessary SETUP requests including MIKEY messages. This is pipelined with a PLAY request to initiate media delivery.
该示例基本上是上述示例（附录A.2），但现在包括建立SRTP加密上下文以获得安全的媒体交付。首先，客户端试图不安全地获取该消息，但服务器重定向到一个URI，该URI指示对RTSP消息使用安全连接的要求。客户端建立TCP/TLS连接，并检索会话描述以确定需要设置哪些媒体资源。在此会话描述中，指出了安全介质（SRTP）。在下一步中，客户端发送必要的设置请求，包括MIKEY消息。这是一个通过管道传输的播放请求，以启动媒体传送。
Client C requests a presentation from media server M. The movie is stored in a container file. The client has obtained an RTSP URI to the container file.
客户端C从媒体服务器M请求演示文稿。电影存储在容器文件中。客户端已获得容器文件的RTSP URI。
Note: The MIKEY messages below are not valid MIKEY messages and are Base64-encoded random data to represent where the MIKEY messages would go.
注意：下面的MIKEY消息不是有效的MIKEY消息，是Base64编码的随机数据，用于表示MIKEY消息的去向。
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 301 Moved Permanently
CSeq: 1
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:25:32 +0000
Location: rtsps://example.com/twister.3gp
M->C: RTSP/2.0 301 Moved Permanently
CSeq: 1
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:25:32 +0000
Location: rtsps://example.com/twister.3gp
C->M: Establish TCP/TLS connection and verify server's certificate that represents example.com. Used for all below RTSP messages.
C->M：建立TCP/TLS连接并验证代表example.com的服务器证书。用于以下所有RTSP消息。
C->M: DESCRIBE rtsps://example.com/twister.3gp RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
C->M: DESCRIBE rtsps://example.com/twister.3gp RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:25:33 +0000
Content-Type: application/sdp
Content-Length: 271
Content-Base: rtsps://example.com/twister.3gp/
Expires: Fri, 20 Dec 2013 12:25:33 +0000
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:25:33 +0000
Content-Type: application/sdp
Content-Length: 271
Content-Base: rtsps://example.com/twister.3gp/
Expires: Fri, 20 Dec 2013 12:25:33 +0000
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
c=IN IP4 0.0.0.0
a=control: *
a=range:npt=00:00:00-00:10:34.10
t=0 0
m=audio 0 RTP/SAVP 0
a=control: trackID=1
m=video 0 RTP/SAVP 26
a=control: trackID=4
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
c=IN IP4 0.0.0.0
a=control: *
a=range:npt=00:00:00-00:10:34.10
t=0 0
m=audio 0 RTP/SAVP 0
a=control: trackID=1
m=video 0 RTP/SAVP 26
a=control: trackID=4
C->M: SETUP rtsps://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/SAVP;unicast;dest_addr=":8000"/":8001";
MIKEY=VGhpcyBpcyB0aGUgZmlyc3Qgc3RyZWFtcyBNSUtFWSBtZXNzYWdl
Accept-Ranges: npt, smpte, clock
Pipelined-Requests: 7654
C->M: SETUP rtsps://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/SAVP;unicast;dest_addr=":8000"/":8001";
MIKEY=VGhpcyBpcyB0aGUgZmlyc3Qgc3RyZWFtcyBNSUtFWSBtZXNzYWdl
Accept-Ranges: npt, smpte, clock
Pipelined-Requests: 7654
C->M: SETUP rtsps://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/SAVP;unicast;dest_addr=":8002"/":8003";
MIKEY=TUlLRVkgZm9yIHN0cmVhbSB0d2lzdGVyLjNncC90cmFja0lEPTQ=
Accept-Ranges: npt, smpte, clock
Pipelined-Requests: 7654
C->M: SETUP rtsps://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/SAVP;unicast;dest_addr=":8002"/":8003";
MIKEY=TUlLRVkgZm9yIHN0cmVhbSB0d2lzdGVyLjNncC90cmFja0lEPTQ=
Accept-Ranges: npt, smpte, clock
Pipelined-Requests: 7654
C->M: PLAY rtsps://example.com/twister.3gp/ RTSP/2.0
CSeq: 5
User-Agent: PhonyClient/1.2
Range: npt=0-
Seek-Style: RAP
Pipelined-Requests: 7654
C->M: PLAY rtsps://example.com/twister.3gp/ RTSP/2.0
CSeq: 5
User-Agent: PhonyClient/1.2
Range: npt=0-
Seek-Style: RAP
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/SAVP;unicast;
dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="198.51.100.5:9000"/"198.51.100.5:9001";
ssrc=93CB001E;
MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD0x
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:25:34 +0000
Date: Fri, 20 Dec 2013 10:25:34 +0000
Accept-Ranges: npt
Pipelined-Requests: 7654
Media-Properties: Random-Access=0.2, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/SAVP;unicast;
dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="198.51.100.5:9000"/"198.51.100.5:9001";
ssrc=93CB001E;
MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD0x
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:25:34 +0000
Date: Fri, 20 Dec 2013 10:25:34 +0000
Accept-Ranges: npt
Pipelined-Requests: 7654
Media-Properties: Random-Access=0.2, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Transport: RTP/SAVP;unicast;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003;
src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
ssrc=A813FC13;
MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD00
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:25:34 +0000
Date: Fri, 20 Dec 2013 10:25:34 +0000
Accept-Range: NPT
Pipelined-Requests: 7654
Media-Properties: Random-Access=0.8, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Transport: RTP/SAVP;unicast;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003;
src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
ssrc=A813FC13;
MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD00
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:25:34 +0000
Date: Fri, 20 Dec 2013 10:25:34 +0000
Accept-Range: NPT
Pipelined-Requests: 7654
Media-Properties: Random-Access=0.8, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 5
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:25:34 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=0-623.10
Seek-Style: RAP
RTP-Info: url="rtsps://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsps://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889;
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 5
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:25:34 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=0-623.10
Seek-Style: RAP
RTP-Info: url="rtsps://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsps://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889;
Pipelined-Requests: 7654
An alternative example of media on demand with a few more tweaks is the following. Client C requests a movie distributed from two different media servers A (audio.example.com) and V (video.example.com). The media description is stored on a web server W. The media description contains descriptions of the presentation and all its streams, including the codecs that are available and the protocol stack.
下面是另一个媒体随需应变的例子，还有一些调整。客户端C请求从两个不同的媒体服务器a（audio.example.com）和V（video.example.com）分发电影。媒体描述存储在web服务器W上。媒体描述包含演示文稿及其所有流的描述，包括可用的编解码器和协议堆栈。
In this example, the client is only interested in the last part of the movie.
在本例中，客户只对电影的最后一部分感兴趣。
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
W->C: HTTP/1.1 200 OK
Date: Wed, 23 Jan 2013 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 278
Expires: Thu, 24 Jan 2013 15:35:06 GMT
W->C: HTTP/1.1 200 OK
Date: Wed, 23 Jan 2013 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 278
Expires: Thu, 24 Jan 2013 15:35:06 GMT
v=0
o=- 2890844526 2890842807 IN IP4 198.51.100.5
s=RTSP Session
e=adm@example.com
c=IN IP4 0.0.0.0
a=range:npt=00:00:00-01:49:34
t=0 0
m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video
v=0
o=- 2890844526 2890842807 IN IP4 198.51.100.5
s=RTSP Session
e=adm@example.com
c=IN IP4 0.0.0.0
a=range:npt=00:00:00-01:49:34
t=0 0
m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, smpte, clock
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, smpte, clock
A->C: RTSP/2.0 200 OK
CSeq: 1
Session: OccldOFFq23KwjYpAnBbUr
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
src_addr="198.51.100.5:5000"/"198.51.100.5:5001"
Date: Wed, 23 Jan 2013 15:35:12 +0000
Server: PhonyServer/1.0
Expires: Thu, 24 Jan 2013 15:35:12 +0000
Cache-Control: public
Accept-Ranges: npt, smpte
Media-Properties: Random-Access=0.02, Immutable, Unlimited
A->C: RTSP/2.0 200 OK
CSeq: 1
Session: OccldOFFq23KwjYpAnBbUr
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
src_addr="198.51.100.5:5000"/"198.51.100.5:5001"
Date: Wed, 23 Jan 2013 15:35:12 +0000
Server: PhonyServer/1.0
Expires: Thu, 24 Jan 2013 15:35:12 +0000
Cache-Control: public
Accept-Ranges: npt, smpte
Media-Properties: Random-Access=0.02, Immutable, Unlimited
C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3058"/"192.0.2.53:3059",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, smpte, clock
C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3058"/"192.0.2.53:3059",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, smpte, clock
V->C: RTSP/2.0 200 OK
CSeq: 1
Session: P5it3pMo6xHkjUcDrNkBjf
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3058"/"192.0.2.53:3059";
src_addr="198.51.100.5:5002"/"198.51.100.5:5003"
Date: Wed, 23 Jan 2013 15:35:12 +0000
Server: PhonyServer/1.0
Cache-Control: public
Expires: Thu, 24 Jan 2013 15:35:12 +0000
Accept-Ranges: npt, smpte
Media-Properties: Random-Access=1.2, Immutable, Unlimited
V->C: RTSP/2.0 200 OK
CSeq: 1
Session: P5it3pMo6xHkjUcDrNkBjf
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3058"/"192.0.2.53:3059";
src_addr="198.51.100.5:5002"/"198.51.100.5:5003"
Date: Wed, 23 Jan 2013 15:35:12 +0000
Server: PhonyServer/1.0
Cache-Control: public
Expires: Thu, 24 Jan 2013 15:35:12 +0000
Accept-Ranges: npt, smpte
Media-Properties: Random-Access=1.2, Immutable, Unlimited
C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: P5it3pMo6xHkjUcDrNkBjf
Range: smpte=0:10:00-
C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: P5it3pMo6xHkjUcDrNkBjf
Range: smpte=0:10:00-
V->C: RTSP/2.0 200 OK
CSeq: 2
Session: P5it3pMo6xHkjUcDrNkBjf
Range: smpte=0:10:00-1:49:23
Seek-Style: First-Prior
RTP-Info: url="rtsp://video.example.com/twister/video"
ssrc=A17E189D:seq=12312232;rtptime=78712811
Server: PhonyServer/2.0
Date: Wed, 23 Jan 2013 15:35:13 +0000
V->C: RTSP/2.0 200 OK
CSeq: 2
Session: P5it3pMo6xHkjUcDrNkBjf
Range: smpte=0:10:00-1:49:23
Seek-Style: First-Prior
RTP-Info: url="rtsp://video.example.com/twister/video"
ssrc=A17E189D:seq=12312232;rtptime=78712811
Server: PhonyServer/2.0
Date: Wed, 23 Jan 2013 15:35:13 +0000
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
Range: smpte=0:10:00-
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
Range: smpte=0:10:00-
A->C: RTSP/2.0 200 OK
CSeq: 2
Session: OccldOFFq23KwjYpAnBbUr
Range: smpte=0:10:00-1:49:23
Seek-Style: First-Prior
RTP-Info: url="rtsp://audio.example.com/twister/audio.en"
ssrc=3D124F01:seq=876655;rtptime=1032181
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:35:13 +0000
A->C: RTSP/2.0 200 OK
CSeq: 2
Session: OccldOFFq23KwjYpAnBbUr
Range: smpte=0:10:00-1:49:23
Seek-Style: First-Prior
RTP-Info: url="rtsp://audio.example.com/twister/audio.en"
ssrc=3D124F01:seq=876655;rtptime=1032181
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:35:13 +0000
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
A->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
A->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: P5it3pMo6xHkjUcDrNkBjf
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: P5it3pMo6xHkjUcDrNkBjf
V->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/2.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
V->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/2.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Even though the audio and video track are on two different servers that may start at slightly different times and may drift with respect to each other over time, the client can perform initial synchronization of the two media using RTP-Info and Range received in the PLAY responses. If the two servers are time synchronized, the RTCP packets can also be used to maintain synchronization.
即使音频和视频曲目位于两个不同的服务器上，这两个服务器可能在稍有不同的时间启动，并且可能随着时间的推移彼此漂移，客户端也可以使用播放响应中接收的RTP信息和范围来执行两个媒体的初始同步。如果两台服务器是时间同步的，则RTCP数据包也可用于保持同步。
Some RTSP servers may treat all files as though they are "container files", yet other servers may not support such a concept. Because of this, clients needs to use the rules set forth in the session description for Request-URIs rather than assuming that a consistent URI may always be used throughout. Below is an example of how a multi-stream server might expect a single-stream file to be served:
一些RTSP服务器可能会将所有文件视为“容器文件”，但其他服务器可能不支持这种概念。因此，客户端需要使用会话描述中为请求URI设置的规则，而不是假设始终使用一致的URI。下面是一个多流服务器如何期望提供单个流文件的示例：
C->S: DESCRIBE rtsp://foo.example.com/test.wav RTSP/2.0
Accept: application/x-rtsp-mh, application/sdp
CSeq: 1
User-Agent: PhonyClient/1.2
C->S: DESCRIBE rtsp://foo.example.com/test.wav RTSP/2.0
Accept: application/x-rtsp-mh, application/sdp
CSeq: 1
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 1
Content-base: rtsp://foo.example.com/test.wav/
Content-type: application/sdp
Content-length: 163
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Expires: Thu, 24 Jan 2013 15:36:52 +0000
S->C: RTSP/2.0 200 OK
CSeq: 1
Content-base: rtsp://foo.example.com/test.wav/
Content-type: application/sdp
Content-length: 163
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Expires: Thu, 24 Jan 2013 15:36:52 +0000
v=0
o=- 872653257 872653257 IN IP4 192.0.2.5
s=mu-law wave file
i=audio test
c=IN IP4 0.0.0.0
t=0 0
a=control: *
m=audio 0 RTP/AVP 0
a=control:streamid=0
v=0
o=- 872653257 872653257 IN IP4 192.0.2.5
s=mu-law wave file
i=audio test
c=IN IP4 0.0.0.0
t=0 0
a=control: *
m=audio 0 RTP/AVP 0
a=control:streamid=0
C->S: SETUP rtsp://foo.example.com/test.wav/streamid=0 RTSP/2.0
Transport: RTP/AVP/UDP;unicast;
dest_addr=":6970"/":6971";mode="PLAY"
CSeq: 2
User-Agent: PhonyClient/1.2
Accept-Ranges: npt, smpte, clock
C->S: SETUP rtsp://foo.example.com/test.wav/streamid=0 RTSP/2.0
Transport: RTP/AVP/UDP;unicast;
dest_addr=":6970"/":6971";mode="PLAY"
CSeq: 2
User-Agent: PhonyClient/1.2
Accept-Ranges: npt, smpte, clock
S->C: RTSP/2.0 200 OK
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:6970"/"192.0.2.53:6971";
src_addr="198.51.100.5:6970"/"198.51.100.5:6971";
mode="PLAY";ssrc=EAB98712
CSeq: 2
Session: NYkqQYKk0bb12BY3goyoyO
Expires: Thu, 24 Jan 2013 15:36:52 +0000
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Accept-Ranges: npt
Media-Properties: Random-Access=0.5, Immutable, Unlimited
S->C: RTSP/2.0 200 OK
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:6970"/"192.0.2.53:6971";
src_addr="198.51.100.5:6970"/"198.51.100.5:6971";
mode="PLAY";ssrc=EAB98712
CSeq: 2
Session: NYkqQYKk0bb12BY3goyoyO
Expires: Thu, 24 Jan 2013 15:36:52 +0000
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Accept-Ranges: npt
Media-Properties: Random-Access=0.5, Immutable, Unlimited
C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: NYkqQYKk0bb12BY3goyoyO
C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: NYkqQYKk0bb12BY3goyoyO
S->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Session: NYkqQYKk0bb12BY3goyoyO
Range: npt=0-600
Seek-Style: RAP
RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0"
ssrc=0D12F123:seq=981888;rtptime=3781123
S->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Session: NYkqQYKk0bb12BY3goyoyO
Range: npt=0-600
Seek-Style: RAP
RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0"
ssrc=0D12F123:seq=981888;rtptime=3781123
Note the different URI in the SETUP command and then the switch back to the aggregate URI in the PLAY command. This makes complete sense when there are multiple streams with aggregate control, but it is less than intuitive in the special case where the number of streams is one. However, the server has declared the aggregated control URI in the SDP; therefore, this is legal.
注意SETUP命令中的不同URI，然后切换回PLAY命令中的聚合URI。当有多个具有聚合控制的流时，这是完全有意义的，但在流的数量为一的特殊情况下，这不是直观的。但是，服务器已经在SDP中声明了聚合控制URI；因此，这是合法的。
In this case, it is also required that servers accept implementations that use the non-aggregated interpretation and use the individual media URI, like this:
在这种情况下，还要求服务器接受使用非聚合解释并使用单个媒体URI的实现，如下所示：
C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: NYkqQYKk0bb12BY3goyoyO
C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: NYkqQYKk0bb12BY3goyoyO
The media server M chooses the multicast address and port. Here, it is assumed that the web server only contains a pointer to the full description, while the media server M maintains the full description.
媒体服务器M选择多播地址和端口。这里，假设web服务器仅包含指向完整描述的指针，而媒体服务器M维护完整描述。
C->W: GET /sessions.html HTTP/1.1
Host: www.example.com
C->W: GET /sessions.html HTTP/1.1
Host: www.example.com
W->C: HTTP/1.1 200 OK
Content-Type: text/html
W->C: HTTP/1.1 200 OK
Content-Type: text/html
<html>
...
<a href "rtsp://live.example.com/concert/audio">
Streamed Live Music performance </a>
...
</html>
<html>
...
<a href "rtsp://live.example.com/concert/audio">
Streamed Live Music performance </a>
...
</html>
C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 1
Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2
C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 1
Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: 183
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Supported: play.basic
M->C: RTSP/2.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: 183
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Supported: play.basic
v=0
o=- 2890844526 2890842807 IN IP4 192.0.2.5
s=RTSP Session
t=0 0
m=audio 3456 RTP/AVP 0
c=IN IP4 233.252.0.54/16
a=control: rtsp://live.example.com/concert/audio
a=range:npt=0-
v=0
o=- 2890844526 2890842807 IN IP4 192.0.2.5
s=RTSP Session
t=0 0
m=audio 3456 RTP/AVP 0
c=IN IP4 233.252.0.54/16
a=control: rtsp://live.example.com/concert/audio
a=range:npt=0-
C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 2
Transport: RTP/AVP;multicast;
dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16
Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2
C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 2
Transport: RTP/AVP;multicast;
dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16
Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Transport: RTP/AVP;multicast;
dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16
;ssrc=4D12AB92/0DF876A3
Session: qHj4jidpmF6zy9v9tNbtxr
Accept-Ranges: npt, clock
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Transport: RTP/AVP;multicast;
dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16
;ssrc=4D12AB92/0DF876A3
Session: qHj4jidpmF6zy9v9tNbtxr
Accept-Ranges: npt, clock
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 3
Session: qHj4jidpmF6zy9v9tNbtxr
User-Agent: PhonyClient/1.2
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 3
Session: qHj4jidpmF6zy9v9tNbtxr
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Session: qHj4jidpmF6zy9v9tNbtxr
Seek-Style: Next
Range:npt=1256-
RTP-Info: url="rtsp://live.example.com/concert/audio"
ssrc=0D12F123:seq=1473; rtptime=80000
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Session: qHj4jidpmF6zy9v9tNbtxr
Seek-Style: Next
Range:npt=1256-
RTP-Info: url="rtsp://live.example.com/concert/audio"
ssrc=0D12F123:seq=1473; rtptime=80000
This example illustrates how the client and server determine their capability to support a special feature, in this case, "play.scale". The server, through the client request and the included Supported header, learns that the client supports RTSP 2.0 and also supports the playback time scaling feature of RTSP. The server's response contains the following feature-related information to the client; it supports the basic media delivery functions (play.basic), the extended functionality of time scaling of content (play.scale), and one "example.com" proprietary feature (com.example.flight). The client also learns the methods supported (Public header) by the server for the indicated resource.
此示例说明了客户端和服务器如何确定其支持特殊功能的能力，在本例中为“play.scale”。服务器通过客户端请求和包含的支持标头了解到客户端支持RTSP 2.0，并且还支持RTSP的播放时间缩放功能。服务器的响应包含以下与客户端相关的功能信息：；它支持基本的媒体交付功能（play.basic）、内容时间缩放的扩展功能（play.scale）和一个“example.com”专有功能（com.example.flight）。客户端还学习服务器为指定资源支持的方法（公共头）。
C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0
CSeq: 1
Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2
C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0
CSeq: 1
Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 1
Public:OPTIONS,SETUP,PLAY,PAUSE,TEARDOWN,DESCRIBE,GET_PARAMETER
Allow: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN, DESCRIBE
Server: PhonyServer/2.0
Supported: play.basic, play.scale, com.example.flight
S->C: RTSP/2.0 200 OK
CSeq: 1
Public:OPTIONS,SETUP,PLAY,PAUSE,TEARDOWN,DESCRIBE,GET_PARAMETER
Allow: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN, DESCRIBE
Server: PhonyServer/2.0
Supported: play.basic, play.scale, com.example.flight
When the client sends its SETUP request, it tells the server that it requires support of the play.scale feature for this session by including the Require header.
当客户端发送其设置请求时，它会通过包含Require头通知服务器它需要此会话对play.scale功能的支持。
C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057",
RTP/AVP/TCP;unicast;interleaved=0-1
Require: play.scale
Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2
C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057",
RTP/AVP/TCP;unicast;interleaved=0-1
Require: play.scale
Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 3
Session: OccldOFFq23KwjYpAnBbUr
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
src_addr="198.51.100.5:5000"/"198.51.100.5:5001"
Server: PhonyServer/2.0
Accept-Ranges: npt, smpte
Media-Properties: Random-Access=0.8, Immutable, Unlimited
S->C: RTSP/2.0 200 OK
CSeq: 3
Session: OccldOFFq23KwjYpAnBbUr
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
src_addr="198.51.100.5:5000"/"198.51.100.5:5001"
Server: PhonyServer/2.0
Accept-Ranges: npt, smpte
Media-Properties: Random-Access=0.8, Immutable, Unlimited
The RTSP session state machine describes the behavior of the protocol from RTSP session initialization through RTSP session termination. It is probably easiest to think of this as the server's state and then view the client as needing to track what it believes the server's state will be based on sent or received RTSP messages. Thus, in most cases, the state tables below can be read as: if the client does X, and assuming it fulfills any prerequisite(s), the (server) state will move to the new state and the indicated response will returned. However, there are also server-to-client notifications or requests, where the action describes what
RTSP会话状态机描述从RTSP会话初始化到RTSP会话终止的协议行为。很可能最容易将其视为服务器的状态，然后将客户端视为需要跟踪它认为服务器的状态将基于发送或接收的RTSP消息。因此，在大多数情况下，下面的状态表可以理解为：如果客户端执行X，并且假设它满足任何先决条件，则（服务器）状态将移动到新状态，并返回指示的响应。但是，还有服务器到客户端的通知或请求，其中操作描述了
notification or request will occur, its requisites, what new state will result after the server has received the response, as well as describing the client's response to the action.
将发生通知或请求，通知或请求的条件，服务器收到响应后的新状态，以及描述客户端对操作的响应。
The State machine is defined on a per-session basis, which is uniquely identified by the RTSP session identifier. The session may contain one or more media streams depending on state. If a single media stream is part of the session, it is in non-aggregated control. If two or more are part of the session, it is in aggregated control.
状态机是基于每个会话定义的，由RTSP会话标识符唯一标识。根据状态，会话可以包含一个或多个媒体流。如果单个媒体流是会话的一部分，则它处于非聚合控制中。如果两个或多个会话是会话的一部分，则它处于聚合控制中。
The below state machine is an informative description of the protocol's behavior. In case of ambiguity with the earlier parts of this specification, the description in the earlier parts take precedence.
下面的状态机是协议行为的信息性描述。如果与本规范早期部分不明确，则以早期部分中的说明为准。
The state machine contains three states, described below. For each state, there exists a table that shows which requests and events are allowed and whether they will result in a state change.
状态机包含三种状态，如下所述。对于每个状态，都有一个表，显示允许哪些请求和事件，以及它们是否会导致状态更改。
Init: Initial state, no session exists.
Init：初始状态，不存在会话。
Ready: Session is ready to start playing.
准备就绪：会话已准备好开始播放。
Play: Session is playing, i.e., sending media-stream data in the direction S->C.
播放：正在播放会话，即沿S->C方向发送媒体流数据。
This representation of the state machine needs more than its state to work. A small number of variables are also needed, and they are explained below.
状态机的这种表示需要的不仅仅是它的状态。还需要少量变量，下文将对其进行解释。
NRM: The number of media streams that are part of this session.
NRM：属于此会话的媒体流数。
RP: Resume point, the point in the presentation time line at which a request to continue playing will resume from. A time format for the variable is not mandated.
RP：恢复点，演示时间线中继续播放的请求将从该点恢复。变量的时间格式不是强制性的。
To make the state tables more compact, a number of abbreviations are used, which are explained below.
为了使状态表更加紧凑，使用了许多缩写，如下所述。
IFI: IF Implemented.
IFI：如果实施。
md: Media
md：媒体
PP: Pause Point, the point in the presentation timeline at which the presentation was paused.
PP：暂停点，演示文稿时间线中暂停演示文稿的点。
Prs: Presentation, the complete multimedia presentation.
Prs：演示文稿，完整的多媒体演示文稿。
RedP: Redirect Point, the point in the presentation timeline at which a REDIRECT was specified to occur.
RedP：重定向点，表示时间线中指定发生重定向的点。
SES: Session.
SES：会议。
This section contains a table for each state. The table contains all the requests and events on which this state is allowed to act. The events that are method names are, unless noted, requests with the given method in the direction client to server (C->S). In some cases, there exists one or more requisites. The response column tells what type of response actions should be performed. Possible actions that are requested for an event include: response codes, e.g., 200, headers that need to be included in the response, setting of state variables, or settings of other session-related parameters. The new state column tells which state the state machine changes to.
本节包含每个状态的表。该表包含允许此状态对其执行操作的所有请求和事件。除非另有说明，否则作为方法名的事件是在客户机到服务器（C->S）的方向上使用给定方法的请求。在某些情况下，存在一个或多个必要条件。“响应”列说明应执行哪种类型的响应操作。为事件请求的可能操作包括：响应代码，例如200，响应中需要包含的标题，状态变量的设置，或其他会话相关参数的设置。新状态列告诉状态机更改为哪个状态。
The response to a valid request meeting the requisites is normally a 2xx (SUCCESS) unless otherwise noted in the response column. The exceptions need to be given a response according to the response column. If the request does not meet the requisite, is erroneous, or some other type of error occurs, the appropriate response code is to be sent. If the response code is a 4xx, the session state is unchanged. A response code of 3rr will result in that the session being ended and its state changed to Init. A response code of 304 results in no state change. However, there are restrictions to when a 3rr response may be used. A 5xx response does not result in any change of the session state, except if the error is not possible to recover from. An unrecoverable error results in the ending of the session. In the general case, if it can't be determined whether or not it was an unrecoverable error, the client will be required to test. In the case that the next request after a 5xx is responded to with a 454 (Session Not Found), the client knows that the session has ended. For any request message that cannot be responded to within the time defined in Section 10.4, a 100 response must be sent.
除非响应栏中另有说明，否则对满足要求的有效请求的响应通常为2xx（成功）。需要根据响应列为异常提供响应。如果请求不符合要求、错误或出现其他类型的错误，则发送相应的响应代码。如果响应代码为4xx，则会话状态不变。响应代码3rr将导致会话结束，其状态更改为Init。响应代码304不会导致状态更改。但是，使用3rr响应的时间有限制。5xx响应不会导致会话状态的任何更改，除非无法从中恢复错误。不可恢复的错误将导致会话结束。在一般情况下，如果无法确定这是否是一个不可恢复的错误，则需要客户机进行测试。如果5xx之后的下一个请求被454（未找到会话）响应，则客户端知道会话已结束。对于在第10.4节规定的时间内无法响应的任何请求消息，必须发送100响应。
The server will time out the session after the period of time specified in the SETUP response, if no activity from the client is detected. Therefore, there exists a timeout event for all states except Init.
如果未检测到来自客户端的活动，则服务器将在安装响应中指定的时间段后超时会话。因此，除了Init之外的所有状态都存在超时事件。
In the case that NRM = 1, the presentation URI is equal to the media URI or a specified presentation URI. For NRM > 1, the presentation URI needs to be other than any of the media that are part of the session. This applies to all states.
在NRM=1的情况下，表示URI等于媒体URI或指定的表示URI。对于NRM>1，表示URI需要不是属于会话的任何媒体。这适用于所有国家。
+---------------+-----------------+---------------------------------+
| Event | Prerequisite | Response |
+---------------+-----------------+---------------------------------+
| DESCRIBE | Needs REDIRECT | 3rr, Redirect |
| | | |
| DESCRIBE | | 200, Session description |
| | | |
| OPTIONS | Session ID | 200, Reset session timeout |
| | | timer |
| | | |
| OPTIONS | | 200 |
| | | |
| SET_PARAMETER | Valid parameter | 200, change value of parameter |
| | | |
| GET_PARAMETER | Valid parameter | 200, return value of parameter |
+---------------+-----------------+---------------------------------+
+---------------+-----------------+---------------------------------+
| Event | Prerequisite | Response |
+---------------+-----------------+---------------------------------+
| DESCRIBE | Needs REDIRECT | 3rr, Redirect |
| | | |
| DESCRIBE | | 200, Session description |
| | | |
| OPTIONS | Session ID | 200, Reset session timeout |
| | | timer |
| | | |
| OPTIONS | | 200 |
| | | |
| SET_PARAMETER | Valid parameter | 200, change value of parameter |
| | | |
| GET_PARAMETER | Valid parameter | 200, return value of parameter |
+---------------+-----------------+---------------------------------+
Table 9: Non-State-Machine Changing Events
表9：非状态机更改事件
The methods in Table 9 do not have any effect on the state machine or the state variables. However, some methods do change other session-related parameters, for example, SET_PARAMETER, which will set the parameter(s) specified in its body. Also, all of these methods that allow the Session header will also update the keep-alive timer for the session.
表9中的方法对状态机或状态变量没有任何影响。但是，某些方法确实会更改其他与会话相关的参数，例如SET_参数，它将设置在其主体中指定的参数。此外，所有这些允许会话头的方法也将更新会话的保持活动计时器。
+------------------+----------------+-----------+-------------------+
| Action | Requisite | New State | Response |
+------------------+----------------+-----------+-------------------+
| SETUP | | Ready | NRM=1, RP=0.0 |
| | | | |
| SETUP | Needs Redirect | Init | 3rr Redirect |
| | | | |
| S -> C: REDIRECT | No Session hdr | Init | Terminate all SES |
+------------------+----------------+-----------+-------------------+
+------------------+----------------+-----------+-------------------+
| Action | Requisite | New State | Response |
+------------------+----------------+-----------+-------------------+
| SETUP | | Ready | NRM=1, RP=0.0 |
| | | | |
| SETUP | Needs Redirect | Init | 3rr Redirect |
| | | | |
| S -> C: REDIRECT | No Session hdr | Init | Terminate all SES |
+------------------+----------------+-----------+-------------------+
Table 10: State: Init
表10：状态：Init
The initial state of the state machine (Table 10) can only be left by processing a correct SETUP request. As seen in the table, the two state variables are also set by a correct request. This table also shows that a correct SETUP can in some cases be redirected to another URI or server by a 3rr response.
状态机的初始状态（表10）只能通过处理正确的设置请求来保留。如表中所示，两个状态变量也是由正确的请求设置的。此表还显示，在某些情况下，正确的设置可以通过3rr响应重定向到另一个URI或服务器。
+-------------+------------------------+---------+------------------+
| Action | Requisite | New | Response |
| | | State | |
+-------------+------------------------+---------+------------------+
| SETUP | New URI | Ready | NRM +=1 |
| | | | |
| SETUP | URI Setup prior | Ready | Change transport |
| | | | param |
| | | | |
| TEARDOWN | Prs URI, | Init | No session hdr, |
| | | | NRM = 0 |
| | | | |
| TEARDOWN | md URI,NRM=1 | Init | No Session hdr, |
| | | | NRM = 0 |
| | | | |
| TEARDOWN | md URI,NRM>1 | Ready | Session hdr, NRM |
| | | | -= 1 |
| | | | |
| PLAY | Prs URI, No range | Play | Play from RP |
| | | | |
| PLAY | Prs URI, Range | Play | According to |
| | | | range |
| | | | |
| PLAY | md URI, NRM=1, Range | Play | According to |
| | | | range |
| | | | |
| PLAY | md URI, NRM=1 | Play | Play from RP |
| | | | |
| PAUSE | Prs URI | Ready | Return PP |
| | | | |
| SC:REDIRECT | Terminate-Reason | Ready | Set RedP |
| | | | |
| SC:REDIRECT | No Terminate-Reason | Init | Session is |
| | time parameter | | removed |
| | | | |
| Timeout | | Init | |
| | | | |
| RedP | | Init | TEARDOWN of |
| reached | | | session |
+-------------+------------------------+---------+------------------+
+-------------+------------------------+---------+------------------+
| Action | Requisite | New | Response |
| | | State | |
+-------------+------------------------+---------+------------------+
| SETUP | New URI | Ready | NRM +=1 |
| | | | |
| SETUP | URI Setup prior | Ready | Change transport |
| | | | param |
| | | | |
| TEARDOWN | Prs URI, | Init | No session hdr, |
| | | | NRM = 0 |
| | | | |
| TEARDOWN | md URI,NRM=1 | Init | No Session hdr, |
| | | | NRM = 0 |
| | | | |
| TEARDOWN | md URI,NRM>1 | Ready | Session hdr, NRM |
| | | | -= 1 |
| | | | |
| PLAY | Prs URI, No range | Play | Play from RP |
| | | | |
| PLAY | Prs URI, Range | Play | According to |
| | | | range |
| | | | |
| PLAY | md URI, NRM=1, Range | Play | According to |
| | | | range |
| | | | |
| PLAY | md URI, NRM=1 | Play | Play from RP |
| | | | |
| PAUSE | Prs URI | Ready | Return PP |
| | | | |
| SC:REDIRECT | Terminate-Reason | Ready | Set RedP |
| | | | |
| SC:REDIRECT | No Terminate-Reason | Init | Session is |
| | time parameter | | removed |
| | | | |
| Timeout | | Init | |
| | | | |
| RedP | | Init | TEARDOWN of |
| reached | | | session |
+-------------+------------------------+---------+------------------+
Table 11: State: Ready
表11：状态：就绪
In the Ready state (Table 11), some of the actions depend on the number of media streams (NRM) in the session, i.e., aggregated or non-aggregated control. A SETUP request in the Ready state can either add one more media stream to the session or, if the media stream (same URI) already is part of the session, change the
在就绪状态下（表11），一些操作取决于会话中媒体流（NRM）的数量，即聚合或非聚合控制。处于就绪状态的设置请求可以向会话添加一个或多个媒体流，或者，如果媒体流（相同的URI）已经是会话的一部分，则可以更改
transport parameters. TEARDOWN depends on both the Request-URI and the number of media streams within the session. If the Request-URI is the presentation URI, the whole session is torn down. If a media URI is used in the TEARDOWN request and more than one media exists in the session, the session will remain and a session header is returned in the response. If only a single media stream remains in the session when performing a TEARDOWN with a media URI, the session is removed. The number of media streams remaining after tearing down a media stream determines the new state.
运输参数。拆卸取决于请求URI和会话中媒体流的数量。如果请求URI是表示URI，则整个会话将被中断。如果在拆卸请求中使用了媒体URI，并且会话中存在多个媒体，则会话将保留，并且在响应中返回会话头。使用媒体URI执行拆卸时，如果会话中只保留一个媒体流，则会删除该会话。拆除媒体流后剩余的媒体流数量决定了新状态。
+----------------+-----------------------+--------+-----------------+
| Action | Requisite | New | Response |
| | | State | |
+----------------+-----------------------+--------+-----------------+
| PAUSE | Prs URI | Ready | Set RP to |
| | | | present point |
| | | | |
| End of media | All media | Play | Set RP = End of |
| | | | media |
| | | | |
| End of range | | Play | Set RP = End of |
| | | | range |
| | | | |
| PLAY | Prs URI, No range | Play | Play from |
| | | | present point |
| | | | |
| PLAY | Prs URI, Range | Play | According to |
| | | | range |
| | | | |
| SC:PLAY_NOTIFY | | Play | 200 |
| | | | |
| SETUP | New URI | Play | 455 |
| | | | |
| SETUP | md URI | Play | 455 |
| | | | |
| SETUP | md URI, IFI | Play | Change |
| | | | transport param.|
| | | | |
| TEARDOWN | Prs URI | Init | No session hdr |
| | | | |
| TEARDOWN | md URI,NRM=1 | Init | No Session hdr, |
| | | | NRM=0 |
| | | | |
| TEARDOWN | md URI | Play | 455 |
| | | | |
| SC:REDIRECT | Terminate Reason with | Play | Set RedP |
| | Time parameter | | |
| | | | |
| SC:REDIRECT | | Init | Session is |
| | | | removed |
| | | | |
| RedP reached | | Init | TEARDOWN of |
| | | | session |
| | | | |
| Timeout | | Init | Stop Media |
| | | | playout |
+----------------+-----------------------+--------+-----------------+
Table 12: State: Play
+----------------+-----------------------+--------+-----------------+
| Action | Requisite | New | Response |
| | | State | |
+----------------+-----------------------+--------+-----------------+
| PAUSE | Prs URI | Ready | Set RP to |
| | | | present point |
| | | | |
| End of media | All media | Play | Set RP = End of |
| | | | media |
| | | | |
| End of range | | Play | Set RP = End of |
| | | | range |
| | | | |
| PLAY | Prs URI, No range | Play | Play from |
| | | | present point |
| | | | |
| PLAY | Prs URI, Range | Play | According to |
| | | | range |
| | | | |
| SC:PLAY_NOTIFY | | Play | 200 |
| | | | |
| SETUP | New URI | Play | 455 |
| | | | |
| SETUP | md URI | Play | 455 |
| | | | |
| SETUP | md URI, IFI | Play | Change |
| | | | transport param.|
| | | | |
| TEARDOWN | Prs URI | Init | No session hdr |
| | | | |
| TEARDOWN | md URI,NRM=1 | Init | No Session hdr, |
| | | | NRM=0 |
| | | | |
| TEARDOWN | md URI | Play | 455 |
| | | | |
| SC:REDIRECT | Terminate Reason with | Play | Set RedP |
| | Time parameter | | |
| | | | |
| SC:REDIRECT | | Init | Session is |
| | | | removed |
| | | | |
| RedP reached | | Init | TEARDOWN of |
| | | | session |
| | | | |
| Timeout | | Init | Stop Media |
| | | | playout |
+----------------+-----------------------+--------+-----------------+
Table 12: State: Play
The Play state table (Table 12) contains a number of requests that need a presentation URI (labeled as Prs URI) to work on (i.e., the presentation URI has to be used as the Request-URI). This is due to the exclusion of non-aggregated stream control in sessions with more than one media stream.
播放状态表（表12）包含许多需要表示URI（标记为Prs URI）处理的请求（即，表示URI必须用作请求URI）。这是由于在具有多个媒体流的会话中排除了非聚合流控制。
To avoid inconsistencies between the client and server, automatic state transitions are avoided. This can be seen at, for example, an "End of media" event when all media has finished playing but the session still remains in Play state. An explicit PAUSE request needs to be sent to change the state to Ready. It may appear that there exist automatic transitions in "RedP reached" and "PP reached". However, they are requested and acknowledged before they take place. The time at which the transition will happen is known by looking at the Terminate-Reason header's time parameter and Range header, respectively. If the client sends a request close in time to these transitions, it needs to be prepared for receiving error messages, as the state may or may not have changed.
为了避免客户端和服务器之间的不一致，避免了自动状态转换。例如，在“媒体结束”事件中，当所有媒体都已播放完毕，但会话仍处于播放状态时，可以看到这种情况。需要发送显式暂停请求以将状态更改为就绪。“RedP到达”和“PP到达”中似乎存在自动转换。然而，在它们发生之前，它们是被请求和确认的。通过分别查看Terminate Reason标头的时间参数和范围标头，可以知道转换将发生的时间。如果客户机发送的请求及时接近这些转换，则需要准备接收错误消息，因为状态可能已更改，也可能未更改。
This section defines how certain combinations of protocols, profiles, and lower transports are used. This includes the usage of the Transport header's source and destination address parameters: "src_addr" and "dest_addr".
本节定义如何使用协议、配置文件和较低传输的某些组合。这包括使用传输头的源地址和目标地址参数：“src_addr”和“dest_addr”。
This section defines the interaction of RTSP with respect to the RTP protocol [RFC3550]. It also defines any necessary media-transport signaling with regard to RTP.
本节定义了RTSP与RTP协议[RFC3550]的交互。它还定义了与RTP有关的任何必要的媒体传输信令。
The available RTP profiles and lower-layer transports are described below along with rules on signaling the available combinations.
下面描述了可用的RTP配置文件和较低层传输，以及关于可用组合的信令规则。
The usage of the "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551] when using RTP for media transport over different lower-layer transport protocols is defined below in regard to RTSP.
当使用RTP通过不同的低层传输协议进行媒体传输时，“用于具有最小控制的音频和视频会议的RTP配置文件”[RFC3551]的使用定义如下。
One such case is defined within this document: the use of embedded (interleaved) binary data as defined in Section 14. The usage of this method is indicated by including the "interleaved" parameter.
本文件中定义了一种情况：使用第14节中定义的嵌入（交错）二进制数据。此方法的使用通过包含“交错”参数来表示。
When using embedded binary data, "src_addr" and "dest_addr" MUST NOT be used. This addressing and multiplexing is used as defined with use of channel numbers and the interleaved parameter.
使用嵌入式二进制数据时，不得使用“src_addr”和“dest_addr”。这种寻址和多路复用是使用信道号和交织参数定义的。
This part describes the sending of RTP [RFC3550] over lower-transport-layer UDP [RFC768] according to the profile "RTP Profile for Audio and Video Conferences with Minimal Control" defined in [RFC3551]. Implementations of RTP/AVP/UDP MUST implement RTCP (Appendix C.1.6). This profile requires one or two unidirectional or bidirectional UDP flows per media stream. The first UDP flow is for RTP and the second is for RTCP. Multiplexing of RTP and RTCP (Appendix C.1.6.4) MAY be used, in which case, a single UDP flow is used for both parts. Embedding of RTP data with the RTSP messages, in accordance with Section 14, SHOULD NOT be performed when RTSP messages are transported over unreliable transport protocols, like UDP [RFC768].
本部分描述了根据[RFC3551]中定义的配置文件“具有最小控制的音频和视频会议的RTP配置文件”，通过较低传输层UDP[RFC768]发送RTP[RFC3550]。RTP/AVP/UDP的实现必须实现RTCP（附录C.1.6）。此配置文件要求每个媒体流有一个或两个单向或双向UDP流。第一个UDP流用于RTP，第二个用于RTCP。可以使用RTP和RTCP的多路复用（附录C.1.6.4），在这种情况下，两个部分使用单个UDP流。根据第14节，当RTSP消息通过不可靠的传输协议（如UDP[RFC768]）传输时，不应执行RTP数据与RTSP消息的嵌入。
The RTP/UDP and RTCP/UDP flows can be established using the Transport header's "src_addr" and "dest_addr" parameters.
RTP/UDP和RTCP/UDP流可以使用传输头的“src_addr”和“dest_addr”参数建立。
In RTSP PLAY mode, the transmission of RTP packets from client to server is unspecified. The behavior in regard to such RTP packets MAY be defined in future.
在RTSP播放模式下，未指定RTP数据包从客户端到服务器的传输。关于这种RTP分组的行为可以在将来定义。
The "src_addr" and "dest_addr" parameters are used in the following way for media delivery and playback mode, i.e., Mode=PLAY:
“src_addr”和“dest_addr”参数以以下方式用于媒体交付和播放模式，即模式=播放：
o The "src_addr" and "dest_addr" parameters MUST contain either 1 or 2 address specifications. Note that two address specifications MAY be provided even if RTP and RTCP multiplexing is negotiated.
o “src_addr”和“dest_addr”参数必须包含1或2个地址规范。注意，即使协商RTP和RTCP多路复用，也可以提供两个地址规范。
o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST contain either:
o RTP/AVP/UDP或RTP/AVP/TCP的每个地址规范必须包含：
* both an address and a port number, or
* 地址和端口号，或
* a port number without an address.
* 没有地址的端口号。
o The first address specification given in either of the parameters applies to the RTP stream. The second specification, if present, applies to the RTCP stream, unless in the case RTP and RTCP multiplexing is negotiated where both RTP and RTCP will use the first specification.
o 参数中给出的第一个地址规范适用于RTP流。第二个规范（如果存在）适用于RTCP流，除非在RTP和RTCP多路复用协商的情况下，RTP和RTCP都将使用第一个规范。
o The RTP/UDP packets from the server to the client MUST be sent to the address and port given by the first address specification of the "dest_addr" parameter.
o 从服务器到客户机的RTP/UDP数据包必须发送到“dest_addr”参数的第一个地址规范给出的地址和端口。
o The RTCP/UDP packets from the server to the client MUST be sent to the address and port given by the second address specification of the "dest_addr" parameter, unless RTP and RTCP multiplexing has been negotiated, in which case RTCP MUST be sent to the first address specification. If no second pair is specified and RTP and RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent.
o 从服务器到客户端的RTCP/UDP数据包必须发送到“dest_addr”参数的第二个地址规范给出的地址和端口，除非已协商RTP和RTCP多路复用，在这种情况下，RTCP必须发送到第一个地址规范。如果未指定第二对，且未协商RTP和RTCP多路复用，则不得发送RTCP。
o The RTCP/UDP packets from the client to the server MUST be sent to the address and port given by the second address specification of the "src_addr" parameter, unless RTP and RTCP multiplexing has been negotiated, in which case RTCP MUST be sent to the first address specification. If no second pair is specified and RTP and RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent.
o 从客户端到服务器的RTCP/UDP数据包必须发送到“src_addr”参数的第二个地址规范给出的地址和端口，除非已协商RTP和RTCP多路复用，在这种情况下，RTCP必须发送到第一个地址规范。如果未指定第二对，且未协商RTP和RTCP多路复用，则不得发送RTCP。
o The RTP/UDP packets from the client to the server MUST be sent to the address and port given by the first address specification of the "src_addr" parameter.
o 从客户端到服务器的RTP/UDP数据包必须发送到“src_addr”参数的第一个地址规范所给出的地址和端口。
o RTP and RTCP packets SHOULD be sent from the corresponding receiver port, i.e., RTCP packets from the server should be sent from the "src_addr" parameters second address port pair, unless RTP and RTCP multiplexing has been negotiated in which case the first address port pair is used.
o RTP和RTCP数据包应从相应的接收器端口发送，即，来自服务器的RTCP数据包应从“src_addr”参数第二个地址端口对发送，除非已协商RTP和RTCP多路复用，在这种情况下使用第一个地址端口对。
The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/ AVPF)" [RFC4585] MAY be used as RTP profiles in sessions using RTP. All that is defined for AVP MUST also apply for AVPF.
RTP配置文件“基于RTP的反馈的扩展RTP配置文件（RTP/AVPF）”[RFC4585]可用作使用RTP的会话中的RTP配置文件。为AVP定义的所有内容也必须适用于AVPF。
The usage of AVPF is indicated by the media initialization protocol used. In the case of SDP, it is indicated by media lines ("m=") containing the profile RTP/AVPF. That SDP MAY also contain further AVPF-related SDP attributes configuring the AVPF session regarding reporting interval and feedback messages to be used [RFC4585]. This configuration MUST be followed.
AVPF的使用由使用的媒体初始化协议指示。对于SDP，它由包含配置文件RTP/AVPF的媒体行（“m=”）表示。该SDP还可能包含更多与AVPF相关的SDP属性，这些属性配置AVPF会话，用于报告间隔和要使用的反馈消息[RFC4585]。必须遵循此配置。
The RTP profile "The Secure Real-time Transport Protocol (SRTP)" [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions using RTP. All that is defined for AVP MUST also apply for SAVP.
RTP配置文件“安全实时传输协议（SRTP）”[RFC3711]是一种RTP配置文件（SAVP），可在使用RTP的RTSP会话中使用。为AVP定义的所有内容也必须适用于SAVP。
The usage of SRTP requires that a security context be established. The default key-management unless otherwise signaled SHALL be MIKEY in RSA-R mode as defined in Appendix C.1.4.1 and not according to the procedure defined in "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)" [RFC4567]. The reason is that RFC 4567 sends the initial MIKEY message in SDP, thus, both requiring the usage of the DESCRIBE method and forcing the server to keep state for clients performing DESCRIBE in anticipation that they might require key management.
使用SRTP需要建立安全上下文。除非另有指示，否则默认密钥管理应为附录C.1.4.1中定义的RSA-R模式下的MIKEY，而不是根据“会话描述协议（SDP）和实时流协议（RTSP）的密钥管理扩展”[RFC4567]中定义的程序。原因是RFC4567在SDP中发送初始MIKEY消息，因此，既需要使用descripe方法，又迫使服务器为执行descripe的客户端保持状态，以预期它们可能需要密钥管理。
MIKEY is selected as the default method for establishing SRTP cryptographic context within an RTSP session as it can be embedded in the RTSP messages while still ensuring confidentiality of content of the keying material, even when using hop-by-hop TLS security for the RTSP messages. This method also supports pipelining of the RTSP messages.
MIKEY被选为在RTSP会话中建立SRTP加密上下文的默认方法，因为它可以嵌入RTSP消息中，同时仍然确保密钥材料内容的机密性，即使对RTSP消息使用逐跳TLS安全性。此方法还支持RTSP消息的管道化。
This method for using MIKEY [RFC3830] to establish the SRTP cryptographic context is initiated in the client's SETUP request, and the server's response to the SETUP carries the MIKEY response. This ensures that the crypto context establishment happens simultaneously with the establishment of the media stream being protected. By using MIKEY's RSA-R mode [RFC4738] the client can be the initiator and still allow the server to set the parameters in accordance with the actual media stream.
使用MIKEY[RFC3830]建立SRTP加密上下文的方法在客户端的设置请求中启动，服务器对设置的响应携带MIKEY响应。这确保了加密上下文的建立与受保护的媒体流的建立同时发生。通过使用MIKEY的RSA-R模式[RFC4738]，客户机可以作为启动器，并且仍然允许服务器根据实际媒体流设置参数。
The SRTP cryptographic context establishment is done according to the following process:
SRTP加密上下文的建立是根据以下过程完成的：
1. The client determines that SAVP or SAVPF shall be used from the media-description format, e.g., SDP. If no other key-management method is explicitly signaled, then MIKEY SHALL be used as defined herein. The use of SRTP with RTSP is only defined with MIKEY with keys established as defined in this section. Future documents may define how an RTSP implementation treats SDP that indicates some other key mechanism to be used. The need for such specification includes [RFC4567], which is not defined for use in RTSP 2.0 within this document.
1. 客户确定SAVP或SAVPF应根据媒体描述格式使用，例如SDP。如果没有明确指示其他密钥管理方法，则应按照本文的定义使用MIKEY。SRTP与RTSP的结合使用仅由MIKEY定义，其密钥按照本节中的定义确定。未来的文档可能会定义RTSP实现如何处理指示要使用的其他关键机制的SDP。此类规范的需求包括[RFC4567]，本文件中未定义RTSP 2.0中使用的规范。
2. The client SHALL establish a TLS connection for RTSP messages, directly or hop-by-hop with the server. If hop-by-hop TLS security is used, the User method SHALL be indicated in the Accept-Credentials header. Note that using hop-by-hop does allow the proxy to insert itself as a man in the middle. This can also occur in the MIKEY exchange by the proxy providing one of its certificates rather than the server's in the Connection-Credentials header. Therefore, the client SHALL validate the server certificate.
2. 客户端应直接或逐跳与服务器建立RTSP消息的TLS连接。如果使用逐跳TLS安全，则应在Accept Credentials标头中指示用户方法。注意，使用逐跳确实允许代理将自己作为中间人插入。这也可能发生在MIKEY exchange中，代理在Connection Credentials标头中提供其证书，而不是服务器的证书。因此，客户端应验证服务器证书。
3. The client retrieves the server's certificate from a direct TLS connection or hop-by-hop from a Connection-Credentials header. The client then checks that the server certificate is valid and belongs to the server.
3. 客户端从直接TLS连接或从连接凭据标头逐跳检索服务器的证书。然后，客户端检查服务器证书是否有效并属于服务器。
4. The client forms the MIKEY Initiator message using RSA-R mode in unicast mode as specified in [RFC4738]. The client SHOULD use the same certificate for TLS and MIKEY to enable the server to bind the two together. The client's certificate SHALL be included in the MIKEY message. The client SHALL indicate its SRTP capabilities in the message.
4. 按照[RFC4738]中的规定，客户端在单播模式下使用RSA-R模式形成MIKEY Initiator消息。客户端应该为TLS和MIKEY使用相同的证书，以使服务器能够将两者绑定在一起。客户证书应包含在MIKEY信息中。客户应在信息中说明其SRTP能力。
5. The MIKEY message from the previous step is base64-encoded [RFC4648] and becomes the value of the MIKEY parameter that is included in the transport specification(s) that specifies an SRTP-based profile (SAVP, SAVPF) in the SETUP request.
5. 来自上一步的MIKEY消息是base64编码的[RFC4648]，并成为传输规范中包含的MIKEY参数值，该传输规范在设置请求中指定基于SRTP的配置文件（SAVP，SAVPF）。
6. Any proxy encountering the MIKEY parameter SHALL forward it without modification. A proxy that is required to understand the Transport specifications will need to understand SAVP/SAVPF with MIKEY to enable the default keying for SRTP-protected media streams. If such a proxy does not support SAVP/SAVPF with MIKEY, it will discard the whole transport specification. Most types of proxies can easily support SAVP and SAVPF with MIKEY. If a client encounters a proxy not supporting SAVP/SAVPF with MIKEY, the client should attempt bypassing that proxy.
6. 任何遇到MIKEY参数的代理都应转发该参数，无需修改。理解传输规范所需的代理需要理解SAVP/SAVPF和MIKEY，以便为受SRTP保护的媒体流启用默认键控。如果这样的代理不支持MIKEY的SAVP/SAVPF，它将丢弃整个传输规范。大多数类型的代理都可以轻松支持SAVP和SAVPF与MIKEY。如果客户端遇到MIKEY不支持SAVP/SAVPF的代理，客户端应尝试绕过该代理。
7. The server, upon receiving the SETUP request, will need to decide upon the transport specification to use, if multiple are included by the client. In the determination of which transport specifications are supported and preferred, the server SHOULD decode the MIKEY message to take the embedded SRTP parameters into account. If all transport spec require SRTP but no MIKEY parameter or other supported keying method is included, the server SHALL respond with 403 (Forbidden).
7. 服务器在收到设置请求后，需要决定要使用的传输规范（如果客户端包含多个）。在确定支持和首选哪种传输规范时，服务器应解码MIKEY消息，以考虑嵌入式SRTP参数。如果所有传输规范都要求SRTP，但没有包括MIKEY参数或其他支持的键控方法，服务器应使用403（禁止）进行响应。
8. Upon generating a response, the following outcomes can occur:
8. 生成响应后，可能会出现以下结果：
* A transport spec not using SRTP and MIKEY is selected. Thus, the response will not contain any MIKEY parameters.
* 选择了不使用SRTP和MIKEY的传输规范。因此，响应将不包含任何MIKEY参数。
* A transport spec using SRTP and MIKEY is selected but an error is encountered in the MIKEY processing. In this case, an RTSP error response code of 466 (Key Management Error) SHALL be used. A MIKEY message describing the error MAY be included.
* 已选择使用SRTP和MIKEY的传输规范，但在MIKEY处理中遇到错误。在这种情况下，应使用RTSP错误响应代码466（密钥管理错误）。可能会包含描述错误的MIKEY消息。
* A transport spec using SRTP and MIKEY is selected and a MIKEY response message can be created. The server SHOULD use the same certificate for TLS and in MIKEY to enable the client to bind the two together. If a different certificate is used, it SHALL be included in the MIKEY message. It is RECOMMENDED that the envelope key-cache type be set to 'Cache' and that a single envelope key is reused for all MIKEY messages to the client. That message is included in the MIKEY parameter part of the single selected transport specification in the SETUP response. The server will set the SRTP parameters as preferred for this media stream within the supported range by the client.
* 选择使用SRTP和MIKEY的传输规范，并可以创建MIKEY响应消息。服务器应该为TLS和MIKEY使用相同的证书，以使客户端能够将两者绑定在一起。如果使用了不同的证书，则应将其包含在MIKEY信息中。建议将信封密钥缓存类型设置为“缓存”，并对发送给客户端的所有MIKEY消息重用一个信封密钥。该消息包含在设置响应中单个选定传输规范的MIKEY参数部分。服务器将在客户端支持的范围内为该媒体流设置首选的SRTP参数。
9. The server transmits the SETUP response back to the client.
9. 服务器将设置响应传输回客户端。
10. The client receives the SETUP response and, if the response code indicates a successful request, it decodes the MIKEY message and establishes the SRTP cryptographic context from the parameters in the MIKEY response.
10. 客户端接收设置响应，如果响应代码指示请求成功，则对MIKEY消息进行解码，并根据MIKEY响应中的参数建立SRTP加密上下文。
In the above method, the client's certificate may be self signed in cases where the client's identity is not necessary to authenticate and the security goal is only to ensure that the RTSP signaling client is the same as the one receiving the SRTP security context.
在上述方法中，在不需要客户端的身份来认证并且安全目标仅是确保RTSP信令客户端与接收SRTP安全上下文的客户端相同的情况下，客户端的证书可以自签名。
The RTP profile "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in RTSP sessions using RTP. All that is defined for AVPF MUST also apply for SAVPF.
RTP配置文件“基于实时传输控制协议（RTCP）的反馈扩展安全RTP配置文件（RTP/SAVPF）”[RFC5124]是一个RTP配置文件（SAVPF），可在使用RTP的RTSP会话中使用。为AVPF定义的所有内容也必须适用于SAVPF。
The usage of SRTP requires that a cryptographic context be established. The default mechanism for establishing that security association is to use MIKEY[RFC3830] with RTSP as defined in Appendix C.1.4.1.
SRTP的使用要求建立加密上下文。建立安全关联的默认机制是使用MIKEY[RFC3830]和附录C.1.4.1中定义的RTSP。
RTCP has several usages when RTP is implemented for media transport as explained below. Thus, RTCP MUST be supported if an RTSP agent handles RTP.
当RTP用于媒体传输时，RTCP有多种用途，如下所述。因此，如果RTSP代理处理RTP，则必须支持RTCP。
RTCP provides media synchronization and clock-drift compensation. The initial media synchronization is available from RTP-Info header. However, to be able to handle any clock drift between the media streams, RTCP is needed.
RTCP提供媒体同步和时钟漂移补偿。初始媒体同步可从RTP Info标头获得。然而，为了能够处理媒体流之间的任何时钟漂移，需要RTCP。
RTCP traffic from the RTSP client to the RTSP server MUST function as keep-alive. This requires an RTSP server supporting RTP to use the received RTCP packets as indications that the client desires the related RTSP session to be kept alive.
从RTSP客户端到RTSP服务器的RTCP通信量必须作为保持活动状态运行。这要求支持RTP的RTSP服务器使用接收到的RTCP数据包作为指示，表明客户端希望相关RTSP会话保持活动状态。
RTCP Receiver reports and any additional feedback from the client MUST be used to adapt the bitrate used over the transport for all cases when RTP is sent over UDP. An RTP sender without reserved resources MUST NOT use more than its fair share of the available resources. This can be determined by comparing on short-to-medium terms (some seconds) the used bitrate and adapting it so that the RTP sender sends at a bitrate comparable to what a TCP sender would achieve on average over the same path.
当RTP通过UDP发送时，必须使用RTCP接收器报告和来自客户端的任何附加反馈来调整传输中使用的比特率。没有保留资源的RTP发送方使用的可用资源不得超过其公平份额。这可以通过在短到中期（几秒钟）比较使用的比特率并调整它来确定，以便RTP发送方以与TCP发送方在相同路径上平均实现的比特率相当的比特率发送。
To ensure that the implementation's adaptation mechanism has a well-defined outer envelope, all implementations using a non-congestion-controlled unicast transport protocol, like UDP, MUST implement "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions" [RTP-CIRCUIT-BREAKERS].
为确保实现的自适应机制具有定义良好的外部封套，所有使用非拥塞控制单播传输协议（如UDP）的实现必须实现“多媒体拥塞控制：单播RTP会话断路器”[RTP-断路器]。
RTSP can be used to negotiate the usage of RTP and RTCP multiplexing as described in [RFC5761]. This allows servers and client to reduce the amount of resources required for the session by only requiring one underlying transport stream per media stream instead of two when using RTP and RTCP. This lessens the server-port consumption and also the necessary state and keep-alive work when operating across NATs [RFC2663].
RTSP可用于协商RTP和RTCP多路复用的使用，如[RFC5761]所述。这允许服务器和客户端减少会话所需的资源量，在使用RTP和RTCP时，每个媒体流只需要一个底层传输流，而不是两个。这减少了服务器端口消耗，也减少了跨NAT操作时的必要状态和保持活动工作[RFC2663]。
Content must be prepared with some consideration for RTP and RTCP multiplexing, mainly ensuring that the RTP payload types used do not collide with the ones used for RTCP packet types. This option likely needs explicit support from the content unless the RTP payload types can be remapped by the server and that is correctly reflected in the session description. Beyond that, support of this feature should come at little cost and much gain.
在准备内容时，必须考虑RTP和RTCP多路复用，主要是确保使用的RTP有效负载类型不会与用于RTCP数据包类型的类型发生冲突。此选项可能需要内容的明确支持，除非服务器可以重新映射RTP负载类型，并且会话描述中正确反映了这一点。除此之外，对该特性的支持应该成本低，收益大。
It is recommended that, if the content and server support RTP and RTCP multiplexing, this is indicated in the session description, for example, using the SDP attribute "a=rtcp-mux". If the SDP message contains the "a=rtcp-mux" attribute for a media stream, the server MUST support RTP and RTCP multiplexing. If indicated or otherwise desired by the client, it can include the Transport parameter "RTCP-mux" in any transport specification where it desires to use "RTCP-mux". The server will indicate if it supports "RTCP-mux". Servers and Clients SHOULD support RTP and RTCP multiplexing.
如果内容和服务器支持RTP和RTCP多路复用，建议在会话描述中指出，例如，使用SDP属性“a=RTCP mux”。如果SDP消息包含媒体流的“a=rtcp mux”属性，则服务器必须支持RTP和rtcp多路复用。如果客户机指示或以其他方式需要，它可以在其希望使用“RTCP mux”的任何传输规范中包括传输参数“RTCP mux”。服务器将指示是否支持“RTCP mux”。服务器和客户端应支持RTP和RTCP多路复用。
For capability exchange, an RTSP feature tag for RTP and RTCP multiplexing is defined: "setup.rtp.rtcp.mux".
对于能力交换，RTP和RTCP多路复用的RTSP功能标签定义为：“setup.RTP.RTCP.mux”。
To minimize the risk of negotiation failure while using RTP and RTCP multiplexing, some recommendations are here provided. If the session description includes explicit indication of support ("a=rtcp-mux" in SDP), then an RTSP agent can safely create a SETUP request with a transport specification with only a single "dest_addr" parameter address specification. If no such explicit indication is provided, then even if the feature tag "setup.rtp.rtcp.mux" is provided in a Supported header by the RTSP server or the feature tag included in the Required header in the SETUP request, the media resource may not support RTP and RTCP multiplexing. Thus, to maximize the probability of successful negotiation, the RTSP agent is recommended to include two "dest_addr" parameter address specifications in the first or first set (if pipelining is used) of SETUP request(s) for any media resource aggregate. That way, the RTSP server can accept RTP and RTCP multiplexing and only use the first address specification or, if not, use both specifications. The RTSP agent, after having received the response for a successful negotiation of the usage of RTP and RTCP multiplexing, can then release the resources associated with the second address specification.
为了最大限度地降低使用RTP和RTCP多路复用时协商失败的风险，这里提供了一些建议。如果会话描述包含支持的明确指示（“SDP中的a=rtcp mux”），则RTSP代理可以安全地创建一个设置请求，该请求具有一个传输规范，只有一个“dest_addr”参数地址规范。如果未提供此类明确指示，则即使RTSP服务器在受支持的报头中提供了功能标签“setup.rtp.rtcp.mux”，或者安装请求中所需报头中包含的功能标签，媒体资源也可能不支持rtp和rtcp多路复用。因此，为了最大限度地提高协商成功的概率，建议RTSP代理在任何媒体资源聚合的第一组或第一组（如果使用管道）设置请求中包括两个“dest_addr”参数地址规范。这样，RTSP服务器可以接受RTP和RTCP多路复用，并且只使用第一个地址规范，或者，如果不使用，则使用两个规范。RTSP代理在收到成功协商RTP和RTCP多路复用使用的响应后，可以释放与第二个地址规范相关联的资源。
Transport of RTP over TCP can be done in two ways: over independent TCP connections using [RFC4571] or interleaved in the RTSP connection. In both cases, the protocol MUST be "rtp" and the lower-layer MUST be TCP. The profile may be any of the above specified ones: AVP, AVPF, SAVP, or SAVPF.
通过TCP传输RTP可以通过两种方式完成：使用[RFC4571]通过独立TCP连接或在RTSP连接中交错传输。在这两种情况下，协议必须是“rtp”，下层必须是TCP。配置文件可以是上面指定的任何配置文件：AVP、AVPF、SAVP或SAVPF。
The use of embedded (interleaved) binary data transported on the RTSP connection is possible as specified in Section 14. When using this declared combination of interleaved binary data, the RTSP messages MUST be transported over TCP. TLS may or may not be used. If TLS is used, both RTSP messages and the binary data will be protected by TLS.
按照第14节的规定，可以使用在RTSP连接上传输的嵌入式（交错）二进制数据。当使用这种交错二进制数据的声明组合时，RTSP消息必须通过TCP传输。TLS可以使用，也可以不使用。如果使用TLS，RTSP消息和二进制数据都将受到TLS的保护。
One should, however, consider that this will result in all media streams going through any proxy. Using independent TCP connections can avoid that issue.
但是，应该考虑到这会导致所有媒体流通过任何代理。使用独立的TCP连接可以避免这个问题。
In this section, the sending of RTP [RFC3550] over lower-layer transport TCP [RFC793] according to "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport" [RFC4571] is described. This section adapts the guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work with RTSP.
在本节中，描述了根据“面向连接的传输上的帧实时传输协议（RTP）和RTP控制协议（RTCP）分组”[RFC4571]，通过下层传输TCP[RFC793]发送RTP[RFC3550]。本节修改了在SIP/SDP[RFC4145]中通过TCP使用RTP的指南，以与RTSP配合使用。
A client codes the support of RTP over independent TCP by specifying an RTP/AVP/TCP transport option without an interleaved parameter in the Transport line of a SETUP request. This transport option MUST include the "unicast" parameter.
客户机通过指定RTP/AVP/TCP传输选项，在设置请求的传输线中不使用交错参数，对独立TCP上的RTP支持进行编码。此传输选项必须包括“单播”参数。
If the client wishes to use RTP with RTCP, two address specifications need to be included in the "dest_addr" parameter. If the client wishes to use RTP without RTCP, one address specification is included in the "dest_addr" parameter. If the client wishes to multiplex RTP and RTCP on a single transport flow (see Appendix C.1.6.4), one or two address specifications are included in the "dest_addr" parameter in addition to the "RTCP-mux" transport parameter. Two address specifications are allowed to facilitate successful negotiation when the server or content can't support RTP and RTCP multiplexing. Ordering rules of dest_addr ports follow the rules for RTP/AVP/UDP.
如果客户希望将RTP与RTCP一起使用，“dest_addr”参数中需要包含两个地址规范。如果客户端希望在不使用RTCP的情况下使用RTP，“dest_addr”参数中包含一个地址规范。如果客户希望在单个传输流上多路传输RTP和RTCP（见附录C.1.6.4），“dest_addr”参数中除“RTCP mux”传输参数外还包括一个或两个地址规范。当服务器或内容无法支持RTP和RTCP多路复用时，允许使用两个地址规范来促进成功协商。dest_addr端口的排序规则遵循RTP/AVP/UDP的规则。
If the client wishes to play the active role in initiating the TCP connection, it MAY set the setup parameter (see Section 18.54) on the Transport line to be "active", or it MAY omit the setup parameter, as active is the default. If the client signals the active role, the ports in the address specifications in the "dest_addr" parameter MUST be set to 9 (the discard port).
如果客户端希望在启动TCP连接时扮演主动角色，它可以将传输线路上的设置参数（见第18.54节）设置为“主动”，也可以忽略设置参数，因为默认设置为主动。如果客户端发出激活角色的信号，“dest_addr”参数中地址规范中的端口必须设置为9（丢弃端口）。
If the client wishes to play the passive role in TCP connection initiation, it MUST set the setup parameter on the Transport line to be "passive". If the client is able to assume the active or the
如果客户端希望在TCP连接启动中扮演被动角色，则必须将传输线上的设置参数设置为“被动”。如果客户机能够承担活动或
passive role, it MUST set the setup parameter on the Transport line to be "actpass". In either case, the "dest_addr" parameter's address specification port value for RTP MUST be set to the TCP port number on which the client is expecting to receive the TCP connection for RTP, and the "dest_addr" address specification port value for RTCP MUST be set to the TCP port number on which the client is expecting to receive the TCP connection for RTCP. In the case that the client wishes to multiplex RTP and RTCP on a single transport flow, the "RTCP-mux" parameter is included and one or two "dest_addr" parameter address specifications are included, as mentioned earlier in this section.
被动角色，必须将传输线上的设置参数设置为“actpass”。在任何一种情况下，RTP的“dest_addr”参数的地址规范端口值必须设置为客户端期望接收RTP的TCP连接的TCP端口号和“dest_addr”RTCP的地址规范端口值必须设置为客户端期望接收RTCP TCP连接的TCP端口号。如果客户端希望在单个传输流上多路传输RTP和RTCP，则包括“RTCP mux”参数，并包括一个或两个“dest_addr”参数地址规范，如本节前面所述。
Upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, if a server decides to accept this requested option, the 2xx reply MUST contain a Transport option that specifies RTP/AVP/TCP (without using the interleaved parameter and using the unicast parameter). The "dest_addr" parameter value MUST be echoed from the parameter value in the client request unless the destination address (only port) was not provided; in which case, the server MAY include the source address of the RTSP TCP connection with the port number unchanged.
在收到非交错RTP/AVP/TCP设置请求后，如果服务器决定接受此请求选项，则2xx回复必须包含指定RTP/AVP/TCP的传输选项（不使用交错参数和单播参数）。“dest_addr”参数值必须与客户端请求中的参数值相呼应，除非未提供目标地址（仅端口）；在这种情况下，服务器可能包括RTSP TCP连接的源地址，端口号不变。
In addition, the server reply MUST set the setup parameter on the Transport line, to indicate the role the server will play in the connection setup. Permissible values are "active" (if a client set setup to "passive" or "actpass") and "passive" (if a client set setup to "active" or "actpass").
此外，服务器应答必须在传输线路上设置设置参数，以指示服务器将在连接设置中扮演的角色。允许值为“主动”（如果客户端设置为“被动”或“actpass”）和“被动”（如果客户端设置为“主动”或“actpass”）。
If a server sets setup to "passive", the "src_addr" in the reply MUST indicate the ports on which the server is willing to receive a TCP connection for RTP and (if the client requested a TCP connection for RTCP by specifying two "dest_addr" address specifications) a TCP/ RTCP connection. If a server sets setup to "active", the ports specified in "src_addr" address specifications MUST be set to 9. The server MAY use the "ssrc" parameter, following the guidance in Section 18.54. The server sets only one address specification in the case that the client has indicated only a single address specification or in case RTP and RTCP multiplexing was requested and accepted by the server. Port ordering for "src_addr" follows the rules for RTP/AVP/UDP.
如果服务器将设置设置为“被动”，则回复中的“src_addr”必须指示服务器愿意接收RTP TCP连接的端口，以及（如果客户端通过指定两个“dest_addr”地址规范请求RTCP TCP连接）TCP/RTCP连接的端口。如果服务器将设置设置为“活动”，则“src_addr”地址规范中指定的端口必须设置为9。服务器可根据第18.54节中的指导使用“ssrc”参数。如果客户端仅指示一个地址规范，或者服务器请求并接受RTP和RTCP多路复用，则服务器仅设置一个地址规范。“src_addr”的端口顺序遵循RTP/AVP/UDP的规则。
Servers MUST support taking the passive role and MAY support taking the active role. Servers with a public IP address take the passive role, thus enabling clients behind NATs and firewalls a better chance of successful connect to the server by actively connecting outwards. Therefore, the clients are RECOMMENDED to take the active role.
服务器必须支持扮演被动角色，也可以支持扮演主动角色。具有公共IP地址的服务器扮演被动角色，因此，通过主动向外连接，NAT和防火墙后面的客户端有更好的机会成功连接到服务器。因此，建议客户发挥积极作用。
After sending (receiving) a 2xx reply for a SETUP method for a non-interleaved RTP/AVP/TCP media stream, the active party SHOULD initiate the TCP connection as soon as possible. The client MUST NOT send a PLAY request prior to the establishment of all the TCP connections negotiated using SETUP for the session. In case the server receives a PLAY request in a session that has not yet established all the TCP connections, it MUST respond using the 464 (Data Transport Not Ready Yet) (Section 17.4.28) error code.
在为非交错RTP/AVP/TCP媒体流的设置方法发送（接收）2xx回复后，活动方应尽快启动TCP连接。在建立使用会话设置协商的所有TCP连接之前，客户端不得发送播放请求。如果服务器在尚未建立所有TCP连接的会话中收到播放请求，则必须使用464（数据传输尚未就绪）（第17.4.28节）错误代码进行响应。
Once the PLAY request for a media resource transported over non-interleaved RTP/AVP/TCP occurs, media begins to flow from server to client over the RTP TCP connection, and RTCP packets flow bidirectionally over the RTCP TCP connection. Unless RTP and RTCP multiplexing has been negotiated; in which case, RTP and RTCP will flow over a common TCP connection. As in the RTP/UDP case, client-to-server traffic on an RTP-only TCP session is unspecified by this memo. The packets that travel on these connections MUST be framed using the protocol defined in [RFC4571], not by the framing defined for interleaving RTP over the RTSP connection defined in Section 14.
一旦出现通过非交错RTP/AVP/TCP传输的媒体资源播放请求，媒体开始通过RTP TCP连接从服务器流向客户端，RTCP数据包通过RTCP TCP连接双向流动。除非已协商RTP和RTCP多路复用；在这种情况下，RTP和RTCP将通过公共TCP连接进行传输。与RTP/UDP情况一样，此备忘录未指定仅RTP TCP会话上的客户端到服务器流量。在这些连接上传输的数据包必须使用[RFC4571]中定义的协议，而不是通过第14节中定义的RTSP连接上的交叉RTP定义的帧。
A successful PAUSE request for media being transported over RTP/AVP/ TCP pauses the flow of packets over the connections, without closing the connections. A successful TEARDOWN request signals that the TCP connections for RTP and RTCP are to be closed by the RTSP client as soon as possible.
通过RTP/AVP/TCP传输的媒体的成功暂停请求会暂停连接上的数据包流，而不会关闭连接。成功的拆卸请求表示RTP和RTCP的TCP连接将由RTSP客户端尽快关闭。
Subsequent SETUP requests using a URI already set up in an RTSP session using an RTP/AVP/TCP transport specification may be ambiguous in the following way: does the client wish to open up a new TCP connection for RTP or RTCP for the URI, or does the client wish to continue using the existing TCP connections? The client SHOULD use the "connection" parameter (defined in Section 18.54) on the Transport line to make its intention clear (by setting "connection" to "new" if new connections are needed, and by setting "connection" to "existing" if the existing connections are to be used). After a 2xx reply for a SETUP request for a new connection, parties should close the preexisting connections, after waiting a suitable period for any stray RTP or RTCP packets to arrive.
使用RTP/AVP/TCP传输规范的RTSP会话中已设置的URI的后续安装请求可能会以以下方式不明确：客户端是否希望为RTP或RTCP打开新的TCP连接，或者客户端是否希望继续使用现有的TCP连接？客户应在运输线路上使用“连接”参数（定义见第18.54节），以明确其意图（如果需要新连接，则将“连接”设置为“新”，如果要使用现有连接，则将“连接”设置为“现有”）。在对新连接的设置请求进行2xx回复后，各方应在等待任何游离RTP或RTCP数据包到达的适当时间后关闭先前存在的连接。
The usage of SRTP, i.e., either SAVP or SAVPF profiles, requires that a security association be established. The default mechanism for establishing that security association is to use MIKEY[RFC3830] with RTSP as defined Appendix C.1.4.1.
使用SRTP，即SAVP或SAVPF配置文件，需要建立安全关联。按照附录C.1.4.1的规定，建立安全关联的默认机制是将MIKEY[RFC3830]与RTSP一起使用。
Below, a rewritten version of the example "Media on Demand" (Appendix A.1) shows the use of RTP/AVP/TCP non-interleaved:
下面，示例“媒体点播”（附录a.1）的重写版本显示了RTP/AVP/TCP非交织的使用：
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Content-Type: application/sdp
Content-Length: 227
Content-Base: rtsp://example.com/twister.3gp/
Expires: Thu, 24 Jan 2013 15:36:52 +0000
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Content-Type: application/sdp
Content-Length: 227
Content-Base: rtsp://example.com/twister.3gp/
Expires: Thu, 24 Jan 2013 15:36:52 +0000
v=0
o=- 2890844256 2890842807 IN IP4 198.51.100.34
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
c=IN IP4 0.0.0.0
a=control: *
a=range:npt=00:00:00-00:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
v=0
o=- 2890844256 2890842807 IN IP4 198.51.100.34
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
c=IN IP4 0.0.0.0
a=control: *
a=range:npt=00:00:00-00:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9";
setup=active;connection=new
Accept-Ranges: npt, smpte, clock
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9";
setup=active;connection=new
Accept-Ranges: npt, smpte, clock
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP/TCP;unicast;
dest_addr=":9"/":9";
src_addr="198.51.100.5:53478"/"198.51.100:54091";
setup=passive;connection=new;ssrc=93CB001E
Session: OccldOFFq23KwjYpAnBbUr
Expires: Thu, 24 Jan 2013 15:36:52 +0000
Date: Wed, 23 Jan 2013 15:36:52 +0000
Accept-Ranges: npt
Media-Properties: Random-Access=0.8, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP/TCP;unicast;
dest_addr=":9"/":9";
src_addr="198.51.100.5:53478"/"198.51.100:54091";
setup=passive;connection=new;ssrc=93CB001E
Session: OccldOFFq23KwjYpAnBbUr
Expires: Thu, 24 Jan 2013 15:36:52 +0000
Date: Wed, 23 Jan 2013 15:36:52 +0000
Accept-Ranges: npt
Media-Properties: Random-Access=0.8, Immutable, Unlimited
C->M: TCP Connection Establishment x2
C->M:TCP连接建立x2
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=30-
Session: OccldOFFq23KwjYpAnBbUr
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=30-
Session: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:54 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30-623.10
Seek-Style: First-Prior
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:54 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30-623.10
Seek-Style: First-Prior
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889
RTSP allows media clients to control selected, non-contiguous sections of media presentations, rendering those streams with an RTP media layer [RFC3550]. Two cases occur, the first is when a new PLAY request replaces an old ongoing request and the new request results in a jump in the media. This should produce continuous media stream at the RTP layer. A client may also immediately follow a completed PLAY request with a new PLAY request. This will result in some gap in the media layer. The below text will look into both cases.
RTSP允许媒体客户端控制媒体演示文稿的选定非连续部分，使用RTP媒体层呈现这些流[RFC3550]。出现两种情况，第一种是当新的播放请求替换旧的正在进行的请求时，新的请求导致媒体跳转。这将在RTP层产生连续的媒体流。客户机还可以在完成播放请求后立即发出新的播放请求。这将导致介质层出现一些间隙。下面的文本将研究这两种情况。
A PLAY request that replaces an ongoing PLAY request allows the media layer rendering the RTP stream to do so continuously without being affected by jumps in media-clock time. The RTP timestamps for the new media range are set so that they become continuous with the previous media range in the previous request. The RTP sequence number for the first packet in the new range will be the next following the last packet in the previous range, 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 replaced PLAY requests for media that has random access properties. In this case, care is needed to align frames or similar media-dependent structures.
替换正在进行的播放请求的播放请求允许呈现RTP流的媒体层连续地这样做，而不受媒体时钟时间跳变的影响。设置新媒体范围的RTP时间戳，使其与前一请求中的前一媒体范围保持连续。新范围中第一个分组的RTP序列号将是前一范围中最后一个分组之后的下一个分组，即单调递增。目标是允许媒体渲染层在媒体时钟跳变期间不中断或重新配置地工作。对于具有随机访问属性的媒体，在所有替换播放请求的情况下，这都是可能的。在这种情况下，需要小心对齐帧或类似的媒体相关结构。
In cases where jumps in media-clock time are a result of RTSP signaling operations arriving after a completed PLAY operation, the request timing will result in that media becoming non-continuous. The server becomes unable to send the media so that it arrives timely and still carries timestamps to make the media stream continuous. In these situations, the server will produce RTP streams where there are
如果媒体时钟时间跳变是在完成播放操作后到达的RTSP信令操作的结果，则请求定时将导致该媒体变得不连续。服务器无法发送媒体，使其及时到达，并且仍然带有时间戳以使媒体流连续。在这些情况下，服务器将在存在RTP流的位置生成RTP流
gaps in the RTP timeline for the media. 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.
介质的RTP时间线中的间隙。如果介质具有帧结构，则将下一帧的时间戳与上一帧结构对齐可以减少渲染该介质的负担。间隔应表示服务器未提供媒体服务的时间，例如，媒体流或暂停请求结束与新播放请求之间的时间。在这些情况下，RTP序列号通常会在间隙中单调增加。
For RTSP sessions with media that lacks random access properties, such as live streams, any media-clock jump is commonly the result of a correspondingly long pause of delivery. The RTP timestamp will have increased in direct proportion to the duration of the paused delivery. Note 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. An allowed exception from the above recommendation on monotonically increasing RTP sequence number is live media streams, likely being relayed. In this case, when the client resumes delivery, it will get the media that is currently being delivered to the server itself. For this type of basic delivery of live streams to multiple users over unicast, individual rewriting of RTP sequence numbers becomes quite a burden. For solutions that already cache media or perform time shifting, the rewriting should impose only a minor burden.
对于缺少随机访问属性的媒体（如实时流）的RTSP会话，任何媒体时钟跳变通常都是相应的长时间传输暂停的结果。RTP时间戳将与暂停交付的持续时间成正比地增加。还要注意，在这种情况下，RTP序列号应该是下一个数据包号。如果不是，RTCP数据包丢失报告将在暂停点和稍后恢复点之间将所有未接收到的数据包指示为丢失。这可能触发拥塞避免机制。上述关于单调递增RTP序列号的建议中允许的例外是可能正在中继的实时媒体流。在这种情况下，当客户端恢复传送时，它将获得当前正在传送到服务器本身的媒体。对于这种通过单播向多个用户提供实时流的基本类型，单独重写RTP序列号将成为相当大的负担。对于已经缓存介质或执行时间转移的解决方案，重写只会带来较小的负担。
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, MUST represent the duration that the delivery was halted. An RTP sequence number MUST generally be the next number, i.e., monotonically increasing modulo 65536. For media resources with the properties Time-Progressing and Time-Duration=0.0, the server MAY create RTP media streams with RTP sequence number jumps in them due to the client first halting delivery and later resuming it (PAUSE and then later PLAY). However, servers utilizing this exception must take into consideration the resulting RTCP receiver reports that likely contain loss reports for all the packets that were a part of the discontinuity. A client cannot rely on the fact that a server will align when resuming play, even if it is RECOMMENDED. The RTP-Info header will provide information on how the server acts in each case.
处理媒体时钟时间跳变时的目标是，所提供的流是连续的，RTP时间戳或序列号中没有间隔。但是，当交付由于某种原因而停止时，RTP时间戳在恢复时必须表示交付停止的持续时间。RTP序列号通常必须是下一个数字，即单调递增的模65536。对于属性为Time Progressing和Time Duration=0.0的媒体资源，服务器可能会创建RTP媒体流，其中RTP序列号跳转是由于客户端首先停止传送，然后恢复传送（暂停，然后再播放）。但是，使用此异常的服务器必须考虑生成的RTCP接收器报告，该报告可能包含作为中断一部分的所有数据包的丢失报告。客户端不能依赖服务器在恢复播放时对齐这一事实，即使建议这样做。RTP Info报头将提供关于服务器在每种情况下如何操作的信息。
One cannot assume that the RTSP client can communicate with 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 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
不能假设RTSP客户端可以与RTP媒体代理通信，因为这两个代理可能是独立的进程。如果RTP时间戳显示与NPT相同的间隙，则媒体代理将假定演示中存在暂停。如果NPT中的跳转足够大，RTP时间戳可能会翻滚并损坏介质
agent may believe later packets to be duplicates of packets just played out. Having the RTP timestamp jump will also affect the RTCP measurements based on this.
代理可能认为稍后的数据包是刚刚播放的数据包的副本。RTP时间戳跳转也会影响基于此的RTCP测量。
As an example, assume an RTP timestamp frequency of 8000 Hz, a packetization interval of 100 ms, and an initial sequence number and timestamp of zero.
例如，假设RTP时间戳频率为8000 Hz，打包间隔为100 ms，初始序列号和时间戳为零。
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 4
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15
User-Agent: PhonyClient/1.2
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 4
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 4
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0
S->C: RTSP/2.0 200 OK
CSeq: 4
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0
The ensuing RTP data stream is depicted below:
随后的RTP数据流如下所示：
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
. . .
S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
. . .
S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s
Upon the completion of the requested delivery, the server sends a PLAY_NOTIFY.
完成请求的传递后，服务器发送播放通知。
S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0
CSeq: 5
Notify-Reason: end-of-stream
Request-Status: cseq=4 status=200 reason="OK"
Range: npt=-15
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=49;rtptime=39200
Session: ymIqLXufHkMHGdtENdblWK
S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0
CSeq: 5
Notify-Reason: end-of-stream
Request-Status: cseq=4 status=200 reason="OK"
Range: npt=-15
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=49;rtptime=39200
Session: ymIqLXufHkMHGdtENdblWK
C->S: RTSP/2.0 200 OK
CSeq: 5
User-Agent: PhonyClient/1.2
C->S: RTSP/2.0 200 OK
CSeq: 5
User-Agent: PhonyClient/1.2
Upon the completion of the play range, the client follows up with a request to PLAY from a new NPT.
在完成播放范围后，客户机会向新NPT发出播放请求。
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 6
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=18-20
User-Agent: PhonyClient/1.2
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 6
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=18-20
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 6
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=18-20
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=50;rtptime=40100
S->C: RTSP/2.0 200 OK
CSeq: 6
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=18-20
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=50;rtptime=40100
The ensuing RTP data stream is depicted below:
随后的RTP数据流如下所示：
S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s
S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s
. . .
S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s
S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s
S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s
. . .
S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s
In this example, first, NPT 10 through 15 are played, then the client requests the server to skip ahead and play NPT 18 through 20. The first segment is presented as RTP packets with sequence numbers 0 through 49 and timestamps 0 through 39,200. The second segment consists of RTP packets with sequence numbers 50 through 69, with timestamps 40,100 through 55,200. While there is a gap in the NPT, there is no gap in the sequence-number space of the RTP data stream.
在本例中，首先播放NPT 10到15，然后客户端请求服务器向前跳，播放NPT 18到20。第一段表示为序列号为0到49、时间戳为0到39200的RTP数据包。第二段由序列号为50到69、时间戳为40100到55200的RTP数据包组成。虽然NPT中存在间隙，但RTP数据流的序列号空间中没有间隙。
The RTP timestamp gap is present in the above example due to the time it takes to perform the second play request, in this case, 12.5 ms (100/8000).
由于执行第二次播放请求所需的时间，在上述示例中存在RTP时间戳间隙，在本例中为12.5毫秒（100/8000）。
During a PAUSE/PLAY interaction in an RTSP session, the duration of time for which the RTP transmission was halted MUST be reflected in the RTP timestamp of each RTP stream. The duration can be calculated for each RTP stream as the time elapsed from when the last RTP packet was sent before the PAUSE request was received and when the first RTP packet was sent after the subsequent PLAY request was received. The duration includes all latency incurred and processing time required to complete the request.
在RTSP会话中的暂停/播放交互期间，RTP传输暂停的持续时间必须反映在每个RTP流的RTP时间戳中。可以将每个RTP流的持续时间计算为从接收暂停请求之前发送最后一个RTP数据包到接收后续播放请求之后发送第一个RTP数据包所经过的时间。持续时间包括发生的所有延迟以及完成请求所需的处理时间。
RFC 3550 [RFC3550] states that: "the RTP timestamp for each unit [packet] would be related to the wallclock time at which the unit becomes current on the virtual presentation timeline".
RFC 3550[RFC3550]指出：“每个单元[数据包]的RTP时间戳将与该单元在虚拟表示时间线上成为当前单元的墙时钟时间相关”。
In order to satisfy the requirements of [RFC3550], the RTP timestamp space needs to increase continuously with real time. While this is not optimal for stored media, it is required for RTP and RTCP to function as intended. Using a continuous RTP timestamp space allows the same timestamp model for both stored and live media and allows better opportunity to integrate both types of media under a single control.
为了满足[RFC3550]的要求，RTP时间戳空间需要实时不断增加。虽然这不是存储介质的最佳选择，但RTP和RTCP需要按预期运行。使用连续的RTP时间戳空间，可以为存储介质和活动介质提供相同的时间戳模型，并有更好的机会在单个控制下集成这两种类型的介质。
As an example, assume a clock frequency of 8000 Hz, a packetization interval of 100 ms, and an initial sequence number and timestamp of zero.
例如，假设时钟频率为8000 Hz，打包间隔为100 ms，初始序列号和时间戳为零。
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 4
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 4
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15
User-Agent: PhonyClient/1.2
用户代理：PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 4
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0
S->C: RTSP/2.0 200 OK
CSeq: 4
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0
The ensuing RTP data stream is depicted below:
随后的RTP数据流如下所示：
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s
S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s
S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s
The client then sends a PAUSE request:
然后，客户端发送暂停请求：
C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0
CSeq: 5
Session: ymIqLXufHkMHGdtENdblWK
User-Agent: PhonyClient/1.2
C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0
CSeq: 5
Session: ymIqLXufHkMHGdtENdblWK
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 5
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10.4-15
S->C: RTSP/2.0 200 OK
CSeq: 5
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10.4-15
20 seconds elapse and then the client sends a PLAY request. In addition, the server requires 15 ms to process the request:
20秒后，客户端发送播放请求。此外，服务器需要15 ms来处理请求：
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 6
Session: ymIqLXufHkMHGdtENdblWK
User-Agent: PhonyClient/1.2
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 6
Session: ymIqLXufHkMHGdtENdblWK
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 6
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10.4-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=4;rtptime=164400
S->C: RTSP/2.0 200 OK
CSeq: 6
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10.4-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=4;rtptime=164400
The ensuing RTP data stream is depicted below:
随后的RTP数据流如下所示：
S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s
S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s
S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s
S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s
S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s
S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s
First, NPT 10 through 10.3 is played, then a PAUSE is received by the server. After 20 seconds, a PLAY is received by the server that takes 15 ms to process. The duration of time for which the session was paused is reflected in the RTP timestamp of the RTP packets sent after this PLAY request.
首先，播放NPT 10至10.3，然后服务器接收暂停。20秒后，服务器接收到播放，需要15毫秒才能处理。会话暂停的持续时间反映在该播放请求之后发送的RTP数据包的RTP时间戳中。
A client can use the RTSP Range header and RTP-Info header to map NPT time of a presentation with the RTP timestamp.
客户端可以使用RTSP范围标头和RTP Info标头将演示文稿的NPT时间映射为RTP时间戳。
Note: in RFC 2326 [RFC2326], this matter was not clearly defined and was misunderstood commonly. However, for RTSP 2.0, it is expected that this will be handled correctly and no exception handling will be required.
注：在RFC 2326[RFC2326]中，这一问题没有明确定义，通常被误解。但是，对于RTSP 2.0，预期将正确处理此问题，并且不需要异常处理。
Note further: it may be required to reset some of the state to ensure the correct media decoding and the usual jitter-buffer handling when issuing a PLAY request.
进一步注意：在发出播放请求时，可能需要重置一些状态，以确保正确的媒体解码和通常的抖动缓冲处理。
For certain data types, tight integration between the RTSP layer and the RTP layer will be necessary. This by no means precludes the above restrictions. Combined RTSP/RTP media clients should use the RTP-Info field to determine whether incoming RTP packets were sent before or after a seek or before or after a PAUSE.
对于某些数据类型，RTSP层和RTP层之间的紧密集成是必要的。这并不排除上述限制。组合RTSP/RTP媒体客户端应使用RTP Info字段来确定传入RTP数据包是在查找之前还是之后发送的，还是在暂停之前或之后发送的。
For scaling (see Section 18.46), RTP timestamps should correspond to the rendering timing. For example, when playing video recorded at 30 frames per second at a scale of two and speed (Section 18.50) of one, the server would drop every second frame to maintain and deliver video packets with the normal timestamp spacing of 3,000 per frame, but NPT would increase by 1/15 second for each video frame.
对于缩放（参见第18.46节），RTP时间戳应与渲染时间相对应。例如，当以2的比例和1的速度（第18.50节）播放每秒30帧录制的视频时，服务器将每秒丢弃一帧，以维持和传送每帧3000的正常时间戳间隔的视频数据包，但对于每个视频帧，NPT将增加1/15秒。
Note: the above scaling puts requirements on the media codec or a media stream to support it. For example, motion JPEG or other non-predictive video coding can easier handle the above example.
注意：上述扩展对媒体编解码器或媒体流提出了支持它的要求。例如，运动JPEG或其他非预测性视频编码可以更容易地处理上述示例。
The client can maintain a correct display of NPT by noting the RTP timestamp value of the first packet arriving after repositioning. The sequence parameter of the RTP-Info (Section 18.45) header provides the first sequence number of the next segment.
客户端可以通过记录重新定位后到达的第一个数据包的RTP时间戳值来保持NPT的正确显示。RTP信息（第18.45节）标题的序列参数提供下一段的第一个序列号。
For continuous audio, the server SHOULD set the RTP marker bit at the beginning of serving a new PLAY request or at jumps in timeline. This allows the client to perform playout delay adaptation.
对于连续音频，服务器应在服务新播放请求的开始处或时间线中的跳转处设置RTP标记位。这允许客户端执行播放延迟自适应。
Note that more than one SSRC MAY be sent in the media stream. If it happens, all sources are expected to be rendered simultaneously.
注意，可以在媒体流中发送多个SSRC。如果发生这种情况，所有源都将同时渲染。
The RTCP BYE message indicates the end of use of a given SSRC. If all sources leave an RTP session, it can, in most cases, be assumed to have ended. Therefore, a client or server MUST NOT send an RTCP
RTCP BYE消息表示给定SSRC的使用结束。如果所有源都离开RTP会话，那么在大多数情况下，可以假定它已经结束。因此，客户端或服务器不得发送RTCP
BYE message until it has finished using a SSRC. A server SHOULD keep using an SSRC until the RTP session is terminated. Prolonging the use of a SSRC allows the established synchronization context associated with that SSRC to be used to synchronize subsequent PLAY requests even if the PLAY response is late.
再见消息，直到它使用完SSRC。服务器应该一直使用SSRC，直到RTP会话终止。延长SSRC的使用允许与该SSRC相关联的已建立的同步上下文用于同步后续播放请求，即使播放响应延迟。
An SSRC collision with the SSRC that transmits media does also have consequences, as it will normally force the media sender to change its SSRC in accordance with the RTP specification [RFC3550]. However, an RTSP server may wait and see if the client changes and thus resolve the conflict to minimize the impact. As media sender, SSRC change will result in a loss of synchronization context and require any receiver to wait for RTCP sender reports for all media requiring synchronization before being able to play out synchronized. Due to these reasons, a client joining a session should take care not to select the same SSRC(s) as the server indicates in the ssrc Transport header parameter. Any SSRC signaled in the Transport header MUST be avoided. A client detecting a collision prior to sending any RTP or RTCP messages SHALL also select a new SSRC.
SSRC与传输媒体的SSRC发生冲突也会产生后果，因为它通常会迫使媒体发送方根据RTP规范[RFC3550]更改其SSRC。但是，RTSP服务器可能会等待并查看客户端是否更改，从而解决冲突以将影响降至最低。作为媒体发送方，SSRC更改将导致同步上下文丢失，并要求任何接收方在能够播放同步之前，等待所有需要同步的媒体的RTCP发送方报告。由于这些原因，加入会话的客户端应注意不要选择与服务器在SSRC传输头参数中指示的相同的SSRC。必须避免在传输报头中发出任何SSRC信号。在发送任何RTP或RTCP消息之前检测到冲突的客户端也应选择新的SSRC。
It is the intention that any future protocol or profile regarding media delivery and lower transport should be easy to add to RTSP. This section provides the necessary steps that need to be met.
我们的目的是，任何未来关于媒体交付和较低传输的协议或配置文件都应易于添加到RTSP。本节提供了需要满足的必要步骤。
The following things need to be considered when adding a new protocol or profile for use with RTSP:
添加用于RTSP的新协议或配置文件时，需要考虑以下事项：
o The protocol or profile needs to define a name tag representing it. This tag is required to be an ABNF "token" to be possible to use in the Transport header specification.
o 协议或配置文件需要定义表示它的名称标记。此标记必须是ABNF“令牌”，才能在传输头规范中使用。
o The useful combinations of protocol, profiles, and lower-layer transport for this extension need to be defined. For each combination, declare the necessary parameters to use in the Transport header.
o 需要为该扩展定义协议、配置文件和较低层传输的有用组合。对于每个组合，声明要在传输标头中使用的必要参数。
o For new media protocols, the interaction with RTSP needs to be addressed. One important factor will be the media synchronization. It may be necessary to have new headers similar to RTP info to carry this information.
o 对于新的媒体协议，需要解决与RTSP的交互问题。一个重要因素是媒体同步。可能需要有类似于RTP info的新标题来承载此信息。
o Discussion needs to occur regarding congestion control for media, especially if transport without built-in congestion control is used.
o 需要对媒体的拥塞控制进行讨论，特别是如果使用没有内置拥塞控制的传输。
See the IANA Considerations section (Section 22) for information on how to register new attributes.
有关如何注册新属性的信息，请参见IANA注意事项部分（第22节）。
The Session Description Protocol (SDP, [RFC4566]) may be used to describe streams or presentations in RTSP. This description is typically returned in reply to a DESCRIBE request on a URI from a server to a client or received via HTTP from a server to a client.
会话描述协议（SDP，[RFC4566]）可用于描述RTSP中的流或表示。此描述通常是作为对URI上从服务器到客户端的描述请求的响应返回的，或者通过HTTP从服务器到客户端接收的描述请求。
This appendix describes how an SDP file determines the operation of an RTSP session. Thus, it is worth pointing out that the interpretation of the SDP is done in the context of the SDP receiver, which is the one being configured. This is the same as in SAP [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where each SDP is interpreted in the context of the agent providing it.
本附录描述SDP文件如何确定RTSP会话的操作。因此，值得指出的是，SDP的解释是在SDP接收机的上下文中完成的，SDP接收机是正在配置的接收机。这与SAP[RFC2974]中的相同；这与SDP提供/应答[RFC3264]不同，后者在提供SDP的代理的上下文中解释每个SDP。
SDP as is provides no mechanism by which a client can distinguish, without human guidance, between several media streams to be rendered simultaneously and a set of alternatives (e.g., two audio streams spoken in different languages). The SDP extension found in "The Session Description Protocol (SDP) Grouping Framework" [RFC5888] provides such functionality to some degree. Appendix D.4 describes the usage of SDP media line grouping for RTSP.
SDP as is不提供任何机制，客户机可以在没有人工指导的情况下，区分要同时呈现的多个媒体流和一组备选方案（例如，以不同语言发言的两个音频流）。“会话描述协议（SDP）分组框架”[RFC5888]中的SDP扩展在某种程度上提供了此类功能。附录D.4描述了RTSP的SDP媒体线路分组的使用。
The terms "session-level", "media-level", and other key/attribute names and values used in this appendix are to be used as defined in SDP [RFC4566]:
本附录中使用的术语“会话级别”、“媒体级别”以及其他键/属性名称和值将按照SDP[RFC4566]中的定义使用：
The "a=control" attribute is used to convey the control URI. This attribute is used both for the session and media descriptions. If used for individual media, it indicates the URI to be used for controlling that particular media stream. If found at the session level, the attribute indicates the URI for aggregate control (presentation URI). The session-level URI MUST be different from any media-level URI. The presence of a session-level control attribute MUST be interpreted as support for aggregated control. The control attribute MUST be present on the media level unless the presentation only contains a single media stream; in which case, the attribute MAY be present on the session level only and then also apply to that single media stream.
“a=control”属性用于传递控件URI。此属性用于会话和媒体描述。如果用于单个媒体，则表示用于控制特定媒体流的URI。如果在会话级别找到，则该属性表示聚合控制的URI（表示URI）。会话级别URI必须不同于任何媒体级别URI。会话级控制属性的存在必须解释为对聚合控制的支持。控件属性必须存在于媒体级别，除非表示仅包含单个媒体流；在这种情况下，该属性可能仅存在于会话级别，然后还应用于该单个媒体流。
ABNF for the attribute is defined in Section 20.3.
属性的ABNF在第20.3节中定义。
Example:
例子：
a=control:rtsp://example.com/foo
a=control:rtsp://example.com/foo
This attribute MAY contain either relative or absolute URIs, following the rules and conventions set out in RFC 3986 [RFC3986]. Implementations MUST look for a base URI in the following order:
该属性可以包含相对或绝对URI，遵循RFC 3986[RFC3986]中规定的规则和约定。实现必须按以下顺序查找基本URI：
1. the RTSP Content-Base field;
1. RTSP内容基字段；
2. the RTSP Content-Location field;
2. RTSP内容位置字段；
3. the RTSP Request-URI.
3. RTSP请求URI。
If this attribute contains only an asterisk (*), then the URI MUST be treated as if it were an empty embedded URI; thus, it will inherit the entire base URI.
如果此属性仅包含星号（*），则必须将URI视为空的嵌入URI；因此，它将继承整个基本URI。
Note: RFC 2326 was very unclear on the processing of relative URIs 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 URIs in the SDP.
注：RFC 2326对相关URI的处理非常不清楚，在发布本文档时，几个RTSP 1.0实现没有执行RFC 3986处理以确定结果URI；相反，简单的连接是常见的。为了完全避免此问题，建议在SDP中使用绝对URI。
The URI handling for SDPs from container files needs special consideration. For example, let's assume that a container file has the URI: "rtsp://example.com/container.mp4". Let's further assume this URI is the base URI and that there is an absolute media-level URI: "rtsp://example.com/container.mp4/trackID=2". A relative media-level URI that resolves in accordance with RFC 3986 [RFC3986] to the above given media URI is "container.mp4/trackID=2". It is usually not desirable to need to include or modify the SDP stored within the container file with the server local name of the container file. To avoid this, one can modify the base URI used to include a trailing slash, e.g., "rtsp://example.com/container.mp4/". In this case, the relative URI for the media will only need to be "trackID=2". However, this will also mean that using "*" in the SDP will result in the control URI including the trailing slash, i.e., "rtsp://example.com/container.mp4/".
容器文件中SDP的URI处理需要特别考虑。例如，假设容器文件具有URI:“rtsp://example.com/container.mp4". 让我们进一步假设此URI是基本URI，并且存在绝对媒体级别的URI:“rtsp://example.com/container.mp4/trackID=2". 根据RFC 3986[RFC3986]解析为上述给定媒体URI的相对媒体级URI为“container.mp4/trackID=2”。通常不需要使用容器文件的服务器本地名称包括或修改存储在容器文件中的SDP。为了避免这种情况，可以修改用于包含尾部斜杠的基本URI，例如“rtsp://example.com/container.mp4/". 在这种情况下，媒体的相对URI只需要是“trackID=2”。然而，这也意味着在SDP中使用“*”将导致包含尾部斜杠的控件URI，即“rtsp://example.com/container.mp4/".
Note: the usage of TrackID in the above is not a standardized form, but one example out of several similar strings such as TrackID, Track_ID, StreamID that is used by different server vendors to indicate a particular piece of media inside a container file.
注意：上述TrackID的用法不是标准化的形式，而是几个类似字符串（如TrackID、Track_ID、StreamID）中的一个示例，不同的服务器供应商使用这些字符串来指示容器文件中的特定介质。
The "m=" field is used to enumerate the streams. It is expected that all the specified streams will be rendered with appropriate synchronization. If the session is over multicast, the port number indicated SHOULD be used for reception. The client MAY try to override the destination port, through the Transport header. The servers MAY allow this: the response will indicate whether or not this is allowed. If the session is unicast, the port numbers are the ones RECOMMENDED by the server to the client, about which receiver ports to use; the client MUST still include its receiver ports in its SETUP request. The client MAY ignore this recommendation. If the server has no preference, it SHOULD set the port number value to zero.
“m=”字段用于枚举流。预期所有指定的流都将以适当的同步方式呈现。如果会话通过多播进行，则应使用指示的端口号进行接收。客户端可以尝试通过传输头覆盖目标端口。服务器可能允许这样做：响应将指示是否允许这样做。如果会话是单播的，则端口号是服务器向客户端推荐的端口号，关于要使用的接收器端口；客户端仍必须在其设置请求中包含其接收器端口。客户可忽略此建议。如果服务器没有首选项，则应将端口号值设置为零。
The "m=" lines contain information about which transport protocol, profile, and possibly lower-layer are to be used for the media stream. The combination of transport, profile, and lower layer, like RTP/AVP/UDP, needs to be defined for how to be used with RTSP. The currently defined combinations are discussed in Appendix C; further combinations MAY be specified.
“m=”行包含有关媒体流将使用哪个传输协议、配置文件以及可能的较低层的信息。需要定义传输、配置文件和较低层（如RTP/AVP/UDP）的组合，以了解如何与RTSP一起使用。附录C中讨论了当前定义的组合；可以指定进一步的组合。
Example:
例子：
m=audio 0 RTP/AVP 31
m=音频0 RTP/AVP 31
The payload type or types are specified in the "m=" line. In case the payload type is a static payload type from RFC 3551 [RFC3551], no other information may be required. In case it is a dynamic payload type, the media attribute "rtpmap" is used to specify what the media is. The "encoding name" within the "rtpmap" attribute may be one of those specified in [RFC4856], a media type registered with IANA according to [RFC4855], or an experimental encoding as specified in SDP [RFC4566]). Codec-specific parameters are not specified in this field, but rather in the "fmtp" attribute described below.
有效负载类型在“m=”行中指定。如果有效负载类型是RFC 3551[RFC3551]中的静态有效负载类型，则可能不需要其他信息。如果是动态有效负载类型，则使用介质属性“rtpmap”指定介质类型。“rtpmap”属性中的“编码名称”可以是[RFC4856]中指定的名称之一、根据[RFC4855]向IANA注册的媒体类型或SDP[RFC4566]中指定的实验编码。编解码器特定参数不在此字段中指定，而是在下面描述的“fmtp”属性中指定。
The selection of the RTP payload type numbers used may be required to consider RTP and RTCP Multiplexing [RFC5761], if that is to be supported by the server.
RTP有效载荷类型号的选择可能需要考虑RTP和RTCP多路复用[RCFC661]，如果要由服务器支持的话。
Format-specific parameters are conveyed using the "fmtp" media attribute. The syntax of the "fmtp" attribute is specific to the encoding(s) to which the attribute refers. Note that some of the
使用“fmtp”媒体属性传递特定于格式的参数。“fmtp”属性的语法特定于该属性所指的编码。请注意，一些
format-specific parameters may be specified outside of the "fmtp" parameters, for example, like the "ptime" attribute for most audio encodings.
格式特定参数可以在“fmtp”参数之外指定，例如，与大多数音频编码的“ptime”属性类似。
The SDP attributes "a=sendrecv", "a=recvonly", and "a=sendonly" provide instructions about the direction the media streams flow within a session. When using RTSP, the SDP can be delivered to a client using either RTSP DESCRIBE or a number of RTSP external methods, like HTTP, FTP, and email. Based on this, the SDP applies to how the RTSP client will see the complete session. Thus, media streams delivered from the RTSP server to the client would be given the "a=recvonly" attribute.
SDP属性“a=sendrecv”、“a=recvonly”和“a=sendonly”提供有关会话中媒体流流动方向的说明。使用RTSP时，SDP可以使用RTSP descripe或许多RTSP外部方法（如HTTP、FTP和电子邮件）交付给客户端。基于此，SDP将应用于RTSP客户端如何查看完整会话。因此，从RTSP服务器传送到客户端的媒体流将被赋予“a=recvonly”属性。
"a=recvonly" in an SDP provided to the RTSP client indicates that media delivery will only occur in the direction from the RTSP server to the client. SDP provided to the RTSP client that lacks any of the directionality attributes ("a=recvonly", "a=sendonly", "a=sendrecv") would be interpreted as having "a=sendrecv". At the time of writing, there exists no RTSP mode suitable for media traffic in the direction from the RTSP client to the server. Thus, all RTSP SDP SHOULD have an "a=recvonly" attribute when using the PLAY mode defined in this document. If future modes are defined for media in the client-to-server direction, then usage of "a=sendonly" or "a=sendrecv" may become suitable to indicate intended media directions.
提供给RTSP客户端的SDP中的“a=recvonly”表示介质传递将仅发生在从RTSP服务器到客户端的方向上。提供给RTSP客户端的SDP如果缺少任何方向性属性（“a=RECVOLY”、“a=sendonly”、“a=sendrecv”），将被解释为具有“a=sendrecv”。在编写本文时，不存在适用于从RTSP客户端到服务器方向的媒体流量的RTSP模式。因此，当使用本文档中定义的播放模式时，所有RTSP SDP都应具有“a=recvonly”属性。如果为客户端到服务器方向的介质定义了未来模式，则使用“a=sendonly”或“a=sendrecv”可能适合指示预期的介质方向。
The "a=range" attribute defines the total time range of the stored session or an individual media. Live sessions that are not seekable can be indicated as specified below; whereas the length of live sessions can be deduced from the "t=" and "r=" SDP parameters.
“a=range”属性定义存储会话或单个媒体的总时间范围。不可搜索的实时会话可按以下规定指示；而实时会话的长度可以从“t=”和“r=”SDP参数中推断出来。
The attribute is both a session- and a media-level attribute. For presentations that contain media streams of the same duration, the range attribute SHOULD only be used at the session level. In case of different lengths, the range attribute MUST be given at media level for all media and SHOULD NOT be given at the session level. If the attribute is present at both media level and session level, the media-level values MUST be used.
该属性既是会话级属性，也是媒体级属性。对于包含相同持续时间的媒体流的演示文稿，只能在会话级别使用“范围”属性。如果长度不同，则必须在媒体级别为所有媒体指定范围属性，而不应在会话级别指定范围属性。如果该属性同时存在于媒体级别和会话级别，则必须使用媒体级别值。
Note: usually one will specify the same length for all media, even if there isn't media available for the full duration on all media. However, that requires that the server accept PLAY requests within that range.
注意：通常情况下，用户会为所有介质指定相同的长度，即使所有介质上没有可供使用的介质。但是，这要求服务器接受该范围内的播放请求。
Servers MUST take care to provide RTSP Range (see Section 18.40) values that are consistent with what is presented in the SDP for the content. There is no reason for non dynamic content, like media clips provided on demand to have inconsistent values. Inconsistent values between the SDP and the actual values for the content handled by the server is likely to generate some failure, like 457 "Invalid Range", in case the client uses PLAY requests with a Range header. In case the content is dynamic in length and it is infeasible to provide a correct value in the SDP, the server is recommended to describe this as content that is not seekable (see below). The server MAY override that property in the response to a PLAY request using the correct values in the Range header.
服务器必须注意提供RTSP范围（见第18.40节）值，该值与SDP中针对内容提供的值一致。非动态内容（如按需提供的媒体剪辑）没有理由具有不一致的值。SDP值与服务器处理的内容的实际值之间的不一致很可能会产生一些故障，如457“无效范围”，以防客户端使用带有范围标头的播放请求。如果内容的长度是动态的，并且无法在SDP中提供正确的值，建议服务器将其描述为不可查找的内容（见下文）。服务器可以在响应播放请求时使用范围标头中的正确值覆盖该属性。
The unit is specified first, followed by the value range. The units and their values are as defined in Section 4.4.1, Section 4.4.2, and Section 4.4.3 and MAY be extended with further formats. Any open-ended range (start-), i.e., without stop range, is of unspecified duration and MUST be considered as content that is not seekable unless this property is overridden. Multiple instances carrying different clock formats MAY be included at either session or media level.
首先指定单位，然后指定值范围。单位及其值如第4.4.1节、第4.4.2节和第4.4.3节所定义，并可通过进一步的格式进行扩展。任何开放范围（开始-），即没有停止范围，都具有未指定的持续时间，必须视为不可查找的内容，除非重写此属性。可在会话或媒体级别包括携带不同时钟格式的多个实例。
ABNF for the attribute is defined in Section 20.3.
属性的ABNF在第20.3节中定义。
Examples:
示例：
a=range:npt=0-34.4368
a=range:clock=19971113T211503Z-19971113T220300Z
Non-seekable stream of unknown duration:
a=range:npt=0-
a=range:npt=0-34.4368
a=range:clock=19971113T211503Z-19971113T220300Z
Non-seekable stream of unknown duration:
a=range:npt=0-
The "t=" field defines when the SDP is valid. For on-demand content, the server SHOULD indicate a stop time value for which it guarantees the 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 indicate start and stop times of 0, meaning that the session is always available.
“t=”字段定义SDP何时有效。对于按需内容，服务器应指示其保证描述有效的停止时间值，以及等于或早于收到描述请求的时间的开始时间。它还可能指示开始和停止时间为0，这意味着会话始终可用。
For sessions that are of live type, i.e., specific start time, unknown stop time, likely not seekable, the "t=" and "r=" field SHOULD be used to indicate the start time of the event. The stop time SHOULD be given so that the live event will have ended at that time, while still not being unnecessary far into the future.
对于实时类型的会话，即特定开始时间、未知停止时间、可能不可查找的会话，“t=”和“r=”字段应用于指示事件的开始时间。应给出停止时间，以便现场活动在该时间结束，同时在未来很长一段时间内仍然没有必要。
In SDP used with RTSP, the "c=" field contains the destination address for the media stream. If a multicast address is specified, the client SHOULD use this address in any SETUP request as destination address, including any additional parameters, such as TTL. For on-demand unicast streams and some multicast streams, the destination address MAY be specified by the client via the SETUP request, thus overriding any specified address. To identify streams without a fixed destination address, where the client is required to specify a destination address, the "c=" field SHOULD be set to a null value. For addresses of type "IP4", this value MUST be "0.0.0.0"; and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be written as "::"), i.e., the unspecified address according to RFC 4291 [RFC4291].
在与RTSP一起使用的SDP中，“c=”字段包含媒体流的目标地址。如果指定了多播地址，客户端应在任何设置请求中使用该地址作为目标地址，包括任何附加参数，如TTL。对于按需单播流和一些多播流，客户端可通过设置请求指定目的地地址，从而覆盖任何指定的地址。要识别没有固定目标地址的流，客户机需要指定目标地址，“c=”字段应设置为空值。对于“IP4”类型的地址，该值必须为“0.0.0.0”；对于“IP6”类型，该值必须为“0:0:0:0:0:0:0”（也可以写为“：”），即根据RFC 4291[RFC4291]未指定的地址。
The optional "a=mtag" attribute identifies a version of the session description. It is opaque to the client. SETUP requests may include this identifier in the If-Match field (see Section 18.24) to allow session establishment only if this attribute value still corresponds to that of the current description. The attribute value is opaque and may contain any character allowed within SDP attribute values.
可选的“a=mtag”属性标识会话描述的版本。这对客户来说是不透明的。设置请求可以在If Match字段（参见第18.24节）中包含该标识符，以便仅当该属性值仍与当前描述的属性值相对应时，才允许建立会话。属性值不透明，可能包含SDP属性值中允许的任何字符。
ABNF for the attribute is defined in Section 20.3.
属性的ABNF在第20.3节中定义。
Example:
例子：
a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a"
a=mtag:“158bb3e7c7fd62ce67f12b533f06b83a”
One could argue that the "o=" field provides identical functionality. However, it does so in a manner that would put constraints on servers that need to support multiple session description types other than SDP for the same piece of media content.
可以说“o=”字段提供了相同的功能。但是，它这样做的方式会对需要支持多个会话描述类型（SDP除外）的服务器施加约束，而SDP不支持同一段媒体内容。
If a presentation does not support aggregate control, no session-level "a=control" attribute is specified. For an SDP with multiple media sections specified, each section will have its own control URI specified via the "a=control" attribute.
如果演示文稿不支持聚合控件，则不会指定会话级别的“a=control”属性。对于指定了多个媒体节的SDP，每个节都将通过“a=control”属性指定自己的控件URI。
Example:
例子：
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.56
s=I came from a web page
e=adm@example.com
c=IN IP4 0.0.0.0
t=0 0
m=video 8002 RTP/AVP 31
a=control:rtsp://audio.example.com/movie.aud
m=audio 8004 RTP/AVP 3
a=control:rtsp://video.example.com/movie.vid
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.56
s=I came from a web page
e=adm@example.com
c=IN IP4 0.0.0.0
t=0 0
m=video 8002 RTP/AVP 31
a=control:rtsp://audio.example.com/movie.aud
m=audio 8004 RTP/AVP 3
a=control:rtsp://video.example.com/movie.vid
Note that the position of the control URI in the description implies that the client establishes separate RTSP control sessions to the servers audio.example.com and video.example.com.
请注意，描述中控制URI的位置意味着客户端建立到服务器audio.example.com和video.example.com的单独RTSP控制会话。
It is recommended that an SDP file contain the complete media-initialization information even if it is delivered to the media client through non-RTSP means. This is necessary as there is no mechanism to indicate that the client should request more detailed media stream information via DESCRIBE.
建议SDP文件包含完整的介质初始化信息，即使它是通过非RTSP方式传送到介质客户端的。这是必要的，因为没有机制表明客户端应该通过descripe请求更详细的媒体流信息。
In this scenario, the server has multiple streams that can be controlled as a whole. In this case, there are both a media-level "a=control" attribute, which is used to specify the stream URIs, and a session-level "a=control" attribute, which is used as the Request-URI for aggregate control. If the media-level URI is relative, it is resolved to absolute URIs according to Appendix D.1.1 above.
在这个场景中，服务器有多个可以作为一个整体控制的流。在这种情况下，既有用于指定流URI的媒体级“a=control”属性，也有用作聚合控制的请求URI的会话级“a=control”属性。如果媒体级URI是相对的，则根据上述附录D.1.1将其解析为绝对URI。
Example:
例子：
C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Date: Wed, 23 Jan 2013 15:36:52 +0000
Expires: Wed, 23 Jan 2013 16:36:52 +0000
Content-Type: application/sdp
Content-Base: rtsp://example.com/movie/
Content-Length: 227
M->C: RTSP/2.0 200 OK
CSeq: 1
Date: Wed, 23 Jan 2013 15:36:52 +0000
Expires: Wed, 23 Jan 2013 16:36:52 +0000
Content-Type: application/sdp
Content-Base: rtsp://example.com/movie/
Content-Length: 227
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.211
s=I contain
i=<more info>
e=adm@example.com
c=IN IP4 0.0.0.0
a=control:*
t=0 0
m=video 8002 RTP/AVP 31
a=control:trackID=1
m=audio 8004 RTP/AVP 3
a=control:trackID=2
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.211
s=I contain
i=<more info>
e=adm@example.com
c=IN IP4 0.0.0.0
a=control:*
t=0 0
m=video 8002 RTP/AVP 31
a=control:trackID=1
m=audio 8004 RTP/AVP 3
a=control:trackID=2
In this example, the client is recommended to establish a single RTSP session to the server, and it uses the URIs rtsp://example.com/movie/ trackID=1 and rtsp://example.com/movie/trackID=2 to set up the video and audio streams, respectively. The URI rtsp://example.com/movie/, which is resolved from the "*", controls the whole presentation (movie).
在此示例中，建议客户端与服务器建立单个RTSP会话，并使用URIrtsp://example.com/movie/ trackID=1和rtsp://example.com/movie/trackID=2 分别设置视频和音频流。URIrtsp://example.com/movie/，由“*”解析，控制整个演示文稿（电影）。
A client is not required to issue SETUP requests for all streams within an aggregate object. Servers should allow the client to ask for only a subset of the streams.
客户端不需要为聚合对象中的所有流发出设置请求。服务器应允许客户端仅请求流的一个子集。
For some types of media, it is desirable to express a relationship between various media components, for instance, for lip synchronization or Scalable Video Codec (SVC) [RFC5583]. This relationship is expressed on the SDP level by grouping of media lines, as described in [RFC5888], and can be exposed to RTSP.
对于某些类型的媒体，希望表示各种媒体组件之间的关系，例如，对于lip同步或可伸缩视频编解码器（SVC）[RFC5583]。如[RFC5888]中所述，这种关系在SDP级别上通过媒体线分组表示，并且可以暴露于RTSP。
For RTSP, it is mainly important to know how to handle grouped media received by means of SDP, i.e., if the media are under aggregate control (see Appendix D.3) or if aggregate control is not available (see Appendix D.2).
对于RTSP而言，了解如何处理通过SDP接收的分组介质非常重要，即介质是否处于聚合控制之下（见附录D.3）或聚合控制不可用（见附录D.2）。
It is RECOMMENDED that grouped media are handled by aggregate control, to give the client the ability to control either the whole presentation or single media.
建议通过聚合控制来处理分组媒体，以使客户端能够控制整个演示文稿或单个媒体。
There are some considerations that need to be made when the session description is delivered to the client outside of RTSP, for example via HTTP or email.
在将会话描述传递到RTSP之外的客户端时，需要考虑一些因素，例如通过HTTP或电子邮件。
First of all, the SDP needs to contain absolute URIs, since relative will, in most cases, not work as the delivery will not correctly forward the base URI.
首先，SDP需要包含绝对URI，因为在大多数情况下，相对URI不起作用，因为传递不会正确地转发基本URI。
The writing of the SDP session availability information, i.e., "t=" and "r=", needs to be carefully considered. When the SDP is fetched by the DESCRIBE method, the probability that it is valid is very high. However, the same is much less certain for SDPs distributed using other methods. Therefore, the publisher of the SDP should take care to follow the recommendations about availability in the SDP specification [RFC4566] in Section 4.2.
SDP会话可用性信息的编写，即“t=”和“r=”，需要仔细考虑。当使用descripe方法获取SDP时，它有效的概率非常高。然而，对于使用其他方法分发的SDP，这一点就不那么确定了。因此，SDP的发布者应注意遵守第4.2节SDP规范[RFC4566]中关于可用性的建议。
This appendix describes the most important and considered use cases for RTSP. They are listed in descending order of importance in regard to ensuring that all necessary functionality is present. This specification only fully supports usage of the two first. Also, in these first two cases, there are special cases or exceptions that are not supported without extensions, e.g., the redirection of media delivery to an address other than the controlling agent's (client's).
本附录描述了RTSP最重要和考虑过的用例。它们按重要性降序列出，以确保所有必要的功能都存在。本规范仅完全支持使用前两种。此外，在前两种情况下，有一些特殊情况或例外情况在没有扩展的情况下不受支持，例如，将媒体传递重定向到控制代理（客户端）以外的地址。
An RTSP-capable server stores content suitable for being streamed to a client. A client desiring playback of any of the stored content uses RTSP to set up the media transport required to deliver the desired content. RTSP is then used to initiate, halt, and manipulate the actual transmission (playout) of the content. RTSP is also required to provide the necessary description and synchronization information for the content.
支持RTSP的服务器存储适合流式传输到客户端的内容。希望回放任何存储内容的客户机使用RTSP设置交付所需内容所需的媒体传输。然后使用RTSP启动、暂停和操纵内容的实际传输（播放）。RTSP还需要为内容提供必要的描述和同步信息。
The above high-level description can be broken down into a number of functions of which RTSP needs to be capable.
上述高层描述可以分解为RTSP需要具备的许多功能。
Presentation Description: Provide initialization information about the presentation (content); for example, which media codecs are needed for the content. Other information that is important includes the number of media streams the presentation contains, the transport protocols used for the media streams, and identifiers for these media streams. This information is required before setup of the content is possible and to determine if the client is even capable of using the content.
演示文稿说明：提供演示文稿（内容）的初始化信息；例如，内容需要哪些媒体编解码器。其他重要信息包括表示包含的媒体流的数量、用于媒体流的传输协议以及这些媒体流的标识符。在可以设置内容之前，需要此信息，以确定客户端是否能够使用内容。
This information need not be sent using RTSP; other external protocols can be used to transmit the transport presentation descriptions. Two good examples are the use of HTTP [RFC7230] or email to fetch or receive presentation descriptions like SDP [RFC4566]
此信息无需使用RTSP发送；其他外部协议可用于传输传输表示描述。两个很好的例子是使用HTTP[RFC7230]或电子邮件获取或接收演示文稿描述，如SDP[RFC4566]
Setup: Set up some or all of the media streams in a presentation. The setup itself consists of selecting the protocol for media transport and the necessary parameters for the protocol, like addresses and ports.
设置：设置演示文稿中的部分或全部媒体流。设置本身包括选择媒体传输协议和协议的必要参数，如地址和端口。
Control of Transmission: After the necessary media streams have been established, the client can request the server to start transmitting the content. The client must be allowed to start or stop the transmission of the content at arbitrary times. The client must also be able to start the transmission at any point in the timeline of the presentation.
传输控制：在建立必要的媒体流后，客户端可以请求服务器开始传输内容。必须允许客户端在任意时间启动或停止内容传输。客户机还必须能够在演示时间线的任何点开始传输。
Synchronization: For media-transport protocols like RTP [RFC3550], it might be beneficial to carry synchronization information within RTSP. This may be due to either the lack of inter-media synchronization within the protocol itself or the potential delay before the synchronization is established (which is the case for RTP when using RTCP).
同步：对于像RTP[RFC3550]这样的媒体传输协议，在RTSP中携带同步信息可能是有益的。这可能是由于协议本身缺乏媒体间同步，或者在建立同步之前存在潜在延迟（使用RTCP时RTP就是这种情况）。
Termination: Terminate the established contexts.
终止：终止已建立的上下文。
For this use case, there are a number of assumptions about how it works. These are:
对于这个用例，有许多关于它如何工作的假设。这些是：
On-Demand content: The content is stored at the server and can be accessed at any time during a time period when it is intended to be available.
按需内容：内容存储在服务器上，可以在预定可用的时间段内随时访问。
Independent sessions: A server is capable of serving a number of clients simultaneously, including from the same piece of content at different points in that presentations timeline.
独立会话：服务器能够同时为多个客户机提供服务，包括在该演示时间线的不同点上从同一内容片段提供服务。
Unicast Transport: Content for each individual client is transmitted to them using unicast traffic.
单播传输：使用单播通信量将每个客户端的内容传输给它们。
It is also possible to redirect the media traffic to a different destination than that of the agent controlling the traffic. However, allowing this without appropriate mechanisms for checking that the destination approves of this allows for Distributed DoS (DDoS).
还可以将媒体流量重定向到与控制流量的代理不同的目的地。但是，在没有适当的机制检查目的地是否同意的情况下允许此操作允许分布式拒绝服务（DDoS）。
This use case is similar to the above on-demand content case (see Appendix E.1), the difference is the nature of the content itself. Live content is continuously distributed as it becomes available from a source; i.e., the main difference from on-demand is that one starts distributing content before the end of it has become available to the server.
该用例类似于上述按需内容案例（见附录E.1），区别在于内容本身的性质。实时内容在从某个来源获得时不断分发；i、 例如，与随需应变的主要区别在于，在内容的末尾可供服务器使用之前就开始分发内容。
In many cases, the consumer of live content is only interested in consuming what actually happens "now"; i.e., very similar to broadcast TV. However, in this case, it is assumed that there exists no broadcast or multicast channel to the users, and instead the server functions as a distribution node, sending the same content to multiple receivers, using unicast traffic between server and client. This unicast traffic and the transport parameters are individually negotiated for each receiving client.
在许多情况下，直播内容的消费者只对“现在”实际发生的事情感兴趣；i、 与广播电视非常相似。然而，在这种情况下，假设不存在到用户的广播或多播信道，并且取而代之的是，服务器充当分发节点，使用服务器和客户端之间的单播通信量向多个接收机发送相同的内容。该单播通信量和传输参数分别为每个接收客户端协商。
Another aspect of live content is that it often has a very limited time of availability, as it is only available for the duration of the event the content covers. An example of such live content could be a music concert that lasts two hours and starts at a predetermined time. Thus, there is a need to announce when and for how long the live content is available.
直播内容的另一个方面是，它的可用时间通常非常有限，因为它仅在内容涵盖的活动期间可用。这种直播内容的一个例子是持续两小时并在预定时间开始的音乐会。因此，需要宣布实时内容的可用时间和持续时间。
In some cases, the server providing live content may be saving some or all of the content to allow clients to pause the stream and resume it from the paused point, or to "rewind" and play continuously from a point earlier than the live point. Hence, this use case does not necessarily exclude playing from other than the live point of the stream, playing with scales other than 1.0, etc.
在某些情况下，提供实时内容的服务器可能正在保存部分或全部内容，以允许客户端暂停流并从暂停点恢复流，或从早于实时点的点“倒带”并连续播放。因此，此用例不一定排除从流的活动点以外的位置播放、使用1.0以外的音阶播放等。
It is possible to use RTSP to request that media be delivered to a multicast group. The entity setting up the session (the controller) will then control when and what media is delivered to the group. This use case has some potential for DoS attacks by flooding a multicast group. Therefore, a mechanism is needed to indicate that the group actually accepts the traffic from the RTSP server.
可以使用RTSP请求将媒体传送到多播组。然后，设置会话的实体（控制器）将控制何时以及向组传送什么介质。此用例通过淹没多播组，可能会导致DoS攻击。因此，需要一种机制来指示组实际接受来自RTSP服务器的流量。
An open issue in this use case is how one ensures that all receivers listening to the multicast or broadcast receives the session presentation configuring the receivers. This specification has to rely on an external solution to solve this issue.
本用例中的一个公开问题是如何确保所有收听多播或广播的接收器接收配置接收器的会话表示。本规范必须依靠外部解决方案来解决此问题。
If one has an established conference or group session, it is possible to have an RTSP server distribute media to the whole group. Transmission to the group is simplest when controlled by a single participant or leader of the conference. Shared control might be possible, but would require further investigation and possibly extensions.
如果有一个已建立的会议或组会话，则可以让RTSP服务器向整个组分发媒体。当由会议的单个参与者或领导者控制时，向小组传递信息是最简单的。共享控制可能是可能的，但需要进一步的调查和可能的扩展。
This use case assumes that there exists either a multicast or a conference focus that redistributes media to all participants.
本用例假设存在多播或会议焦点，将媒体重新分发给所有参与者。
This use case is intended to be able to handle the following scenario: a conference leader or participant (hereafter called the "controller") has some pre-stored content on an RTSP server that he wants to share with the group. The controller sets up an RTSP session at the streaming server for this content and retrieves the session description for the content. The destination for the media content is set to the shared multicast group or conference focus. When desired by the controller, he/she can start and stop the transmission of the media to the conference group.
此用例旨在处理以下场景：会议主持人或参与者（以下称为“控制器”）在RTSP服务器上有一些预存储的内容，他希望与团队共享。控制器在流媒体服务器上为此内容设置RTSP会话，并检索该内容的会话描述。媒体内容的目标设置为共享多播组或会议焦点。当控制器需要时，他/她可以启动和停止向会议组传输媒体。
There are several issues with this use case that are not solved by this core specification for RTSP:
此用例有几个问题没有通过RTSP核心规范解决：
DoS: To avoid an RTSP server from being an unknowing participant in a DoS attack, the server needs to be able to verify the destination's acceptance of the media. Such a mechanism to verify the approval of received media does not yet exist; instead, only policies can be used, which can be made to work in controlled environments.
DoS：为了避免RTSP服务器成为DoS攻击的未知参与者，服务器需要能够验证目的地是否接受介质。目前还不存在这样一种机制来核实收到的媒体的批准情况；相反，只能使用策略，这些策略可以在受控环境中工作。
Distributing the presentation description to all participants in the group: To enable a media receiver to correctly decode the content, the media configuration information needs to be distributed reliably to all participants. This will most likely require support from an external protocol.
将演示文稿描述分发给组中的所有参与者：为了使媒体接收器能够正确解码内容，需要将媒体配置信息可靠地分发给所有参与者。这很可能需要外部协议的支持。
Passing control of the session: If it is desired to pass control of the RTSP session between the participants, some support will be required by an external protocol to exchange state information and possibly floor control of who is controlling the RTSP session.
传递会话控制权：如果希望在参与者之间传递RTSP会话控制权，则外部协议将需要一些支持，以交换状态信息，并可能需要控制RTSP会话的人的楼层控制权。
This use case in its simplest form does not require any use of RTSP at all; this is what multicast conferences being announced with SAP [RFC2974] and SDP are intended to handle. However, in use cases where more advanced features like access control to the multicast session are desired, RTSP could be used for session establishment.
这个最简单形式的用例根本不需要使用RTSP；这就是SAP[RFC2974]和SDP宣布的多播会议的目的。然而，在需要对多播会话进行访问控制等更高级功能的用例中，RTSP可用于会话建立。
A client desiring to join a live multicasted media session with cryptographic (encryption) access control could use RTSP in the following way. The source of the session announces the session and gives all interested an RTSP URI. The client connects to the server and requests the presentation description, allowing configuration for reception of the media. In this step, it is possible for the client to use secured transport and any desired level of authentication; for example, for billing or access control. An RTSP link also allows for load balancing between multiple servers.
希望通过加密（encryption）访问控制加入实时多播媒体会话的客户端可以通过以下方式使用RTSP。会话的源将宣布会话，并向所有感兴趣的用户提供一个RTSP URI。客户端连接到服务器并请求演示文稿描述，从而允许对媒体接收进行配置。在该步骤中，客户端可以使用安全传输和任何期望级别的认证；例如，用于计费或访问控制。RTSP链路还允许在多台服务器之间进行负载平衡。
If these were the only goals, they could be achieved by simply using HTTP. However, for cases where the sender likes to keep track of each individual receiver of a session, and possibly use the session as a side channel for distributing key-updates or other information on a per-receiver basis, and the full set of receivers is not known prior to the session start, the state establishment that RTSP provides can be beneficial. In this case, a client would establish an RTSP session for this multicast group with the RTSP server. The RTSP server will not transmit any media, but instead will point to the multicast group. The client and server will be able to keep the session alive for as long as the receiver participates in the session thus enabling, for example, the server to push updates to the client.
如果这些是唯一的目标，那么它们可以通过简单地使用HTTP来实现。然而，对于发送方喜欢跟踪会话的每个单独接收方，并且可能将会话用作在每个接收方的基础上分发密钥更新或其他信息的侧信道，并且在会话开始之前不知道完整的接收方集合的情况，RTSP提供的国家机构可能是有益的。在这种情况下，客户端将为此多播组与RTSP服务器建立RTSP会话。RTSP服务器不会传输任何媒体，而是指向多播组。只要接收方参与会话，客户机和服务器就能够保持会话的活动状态，因此，例如，服务器能够将更新推送到客户机。
This use case will most likely not be able to be implemented without some extensions to the server-to-client push mechanism. Here the PLAY_NOTIFY method (see Section 13.5) with a suitable extension could provide clear benefits.
如果没有对服务器到客户端推送机制的一些扩展，这个用例很可能无法实现。在这里，PLAY_NOTIFY方法（见第13.5节）和适当的扩展可以提供明显的好处。
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 values (for a response or setting of the parameter). Each entry of the list is a single line of text. Parameters are separated from values by a colon. The parameter name MUST only use US-ASCII visible characters while the values are UTF-8 text strings. The media type registration form is in Section 22.16.
“文本/参数”类型的资源由1）参数列表（用于查询）或2）参数列表和相关值（用于参数的响应或设置）组成。列表中的每个条目都是一行文本。参数与值之间用冒号分隔。当值为UTF-8文本字符串时，参数名称只能使用US-ASCII可见字符。媒体类型登记表见第22.16节。
There is a potential interoperability issue for this format. It 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 syntax supports the examples provided. However, it goes further by allowing UTF-8 in the value part; thus, usage of UTF-8 strings may not be supported. However, as individual parameters are not defined, the implementing application needs to have out-of-band agreement or using feature tag anyway to determine if the endpoint supports the parameters.
此格式存在潜在的互操作性问题。它在RFC2326中命名，但从未定义，即使在提示语法的示例中使用。此格式符合目的，其语法支持提供的示例。然而，它更进一步，在值部分允许UTF-8；因此，可能不支持使用UTF-8字符串。但是，由于未定义单个参数，实现应用程序需要具有带外协议，或者无论如何都要使用功能标记来确定端点是否支持这些参数。
The ABNF [RFC5234] grammar for "text/parameters" content is:
“文本/参数”内容的ABNF[RFC5234]语法为：
file = *((parameter / parameter-value) CRLF)
parameter = 1*visible-except-colon
parameter-value = parameter *WSP ":" value
visible-except-colon = %x21-39 / %x3B-7E ; VCHAR - ":"
value = *(TEXT-UTF8char / WSP)
TEXT-UTF8char = <as defined in Section 20.1>
WSP = <See RFC 5234> ; Space or HTAB
VCHAR = <See RFC 5234>
CRLF = <See RFC 5234>
file = *((parameter / parameter-value) CRLF)
parameter = 1*visible-except-colon
parameter-value = parameter *WSP ":" value
visible-except-colon = %x21-39 / %x3B-7E ; VCHAR - ":"
value = *(TEXT-UTF8char / WSP)
TEXT-UTF8char = <as defined in Section 20.1>
WSP = <See RFC 5234> ; Space or HTAB
VCHAR = <See RFC 5234>
CRLF = <See RFC 5234>
Appendix G. Requirements for Unreliable Transport of RTSP
附录G.RTSP不可靠运输的要求
This appendix provides guidance for those who want to implement RTSP messages over unreliable transports as has been defined in RTSP 1.0 [RFC2326]. RFC 2326 defined the "rtspu" URI scheme and provided some basic information for the transport of RTSP messages over UDP. The information is being provided here as there has been at least one commercial implementation and compatibility with that should be maintained.
本附录为那些希望通过RTSP 1.0[RFC2326]中定义的不可靠传输实现RTSP消息的人提供了指导。RFC2326定义了“rtspu”URI方案，并为通过UDP传输RTSP消息提供了一些基本信息。这里提供的信息是因为至少有一个商业实现，并且应该保持与该实现的兼容性。
The following points should be considered for an interoperable implementation:
对于可互操作的实现，应考虑以下几点：
o Requests shall be acknowledged by the receiver. If there is no acknowledgement, the sender may resend the same message after a timeout of one round-trip time (RTT). Any retransmissions due to lack of acknowledgement must carry the same sequence number as the original request.
o 接收方应确认请求。如果没有确认，发送方可以在一个往返时间（RTT）超时后重新发送相同的消息。由于缺少确认而导致的任何重传必须携带与原始请求相同的序列号。
o The RTT can be estimated as in TCP (RFC 6298) [RFC6298], with an initial round-trip value of 500 ms. An implementation may cache the last RTT measurement as the initial value for future connections.
o RTT可以按照TCP（RFC 6298）[RFC6298]中的方法进行估计，初始往返值为500毫秒。实现可以缓存最后的RTT测量值作为未来连接的初始值。
o The Timestamp header (Section 18.53) is used to avoid the retransmission ambiguity problem [Stevens98].
o 时间戳报头（第18.53节）用于避免重传歧义问题[Stevens98]。
o The registered default port for RTSP over UDP for the server is 554.
o 服务器的UDP上RTSP注册的默认端口为554。
o RTSP messages can be carried over any lower-layer transport protocol that is 8-bit clean.
o RTSP消息可以通过任何8位干净的低层传输协议传输。
o RTSP messages are vulnerable to bit errors and should not be subjected to them.
o RTSP消息易受位错误的影响，不应受到位错误的影响。
o Source authentication, or at least validation that RTSP messages comes from the same entity becomes extremely important, as session hijacking may be substantially easier for RTSP message transport using an unreliable protocol like UDP than for TCP.
o 源身份验证，或者至少验证RTSP消息来自同一实体变得极其重要，因为会话劫持对于使用不可靠协议（如UDP）的RTSP消息传输来说可能比TCP更容易。
There are two RTSP headers that are primarily intended for being used by the unreliable handling of RTSP messages and which will be maintained:
有两个RTSP报头主要用于不可靠的RTSP消息处理，将予以维护：
o CSeq: See Section 18.20. It should be noted that the CSeq header is also required to match requests and responses independent whether a reliable or unreliable transport is used.
o CSeq：见第18.20节。应该注意的是，CSeq报头还需要与请求和响应相匹配，而不管使用的是可靠的还是不可靠的传输。
o Timestamp: See Section 18.53
o 时间戳：见第18.53节
Appendix H. Backwards-Compatibility Considerations
附录H.向后兼容性注意事项
This section contains notes on issues about backwards compatibility with clients or servers being implemented according to RFC 2326 [RFC2326]. Note that there exists no requirement to implement RTSP 1.0; in fact, this document recommends against it as it is difficult to do in an interoperable way.
本节包含关于根据RFC 2326[RFC2326]实现的客户端或服务器向后兼容性问题的说明。注意，不存在实现RTSP 1.0的要求；事实上，本文档建议不要这样做，因为很难以可互操作的方式进行。
A server implementing RTSP 2.0 MUST include an RTSP-Version of "RTSP/2.0" in all responses to requests containing RTSP-Version value of "RTSP/2.0". If a server receives an RTSP 1.0 request, it MAY respond with an RTSP 1.0 response if it chooses to support RFC 2326. If the server chooses not to support RFC 2326, it MUST respond with a 505 (RTSP Version Not Supported) status code. A server MUST NOT respond to an RTSP 1.0 request with an RTSP 2.0 response.
实现RTSP 2.0的服务器必须在对包含RTSP版本值“RTSP/2.0”的请求的所有响应中包含RTSP版本的“RTSP/2.0”。如果服务器接收到RTSP 1.0请求，如果它选择支持RFC 2326，则可以使用RTSP 1.0响应进行响应。如果服务器选择不支持RFC 2326，则必须使用505（不支持RTSP版本）状态代码进行响应。服务器不得使用RTSP 2.0响应响应RTSP 1.0请求。
Clients implementing RTSP 2.0 MAY use an OPTIONS request with an RTSP-Version of "RTSP/2.0" to determine whether a server supports RTSP 2.0. If the server responds with either an RTSP-Version of "RTSP/1.0" or a status 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 2.0的客户端可以使用带有RTSP版本“RTSP/2.0”的选项请求来确定服务器是否支持RTSP 2.0。如果服务器响应RTSP版本为“RTSP/1.0”或状态代码为505（不支持RTSP版本），则如果客户端选择支持RFC 2326，则必须使用RTSP 1.0请求。
The behavior in the server when a Play is received in Play state has changed (Section 13.4). In RFC 2326, the new PLAY request would be queued until the current Play completed. Any new PLAY request now takes effect immediately replacing the previous request.
在播放状态下接收播放时，服务器中的行为发生了变化（第13.4节）。在RFC2326中，新播放请求将排队，直到当前播放完成。任何新的播放请求现在立即生效，取代以前的请求。
Some server implementations of RFC 2326 maintain a one-to-one relationship between a connection and an RTSP session. Such implementations require clients to use a persistent connection to communicate with the server and when a client closes its connection, the server may remove the RTSP session. This is worth noting if an RTSP 2.0 client also supporting 1.0 connects to a 1.0 server.
RFC2326的一些服务器实现在连接和RTSP会话之间保持一对一的关系。此类实现要求客户端使用持久连接与服务器通信，当客户端关闭其连接时，服务器可能会删除RTSP会话。如果同时支持1.0的RTSP 2.0客户端连接到1.0服务器，则值得注意。
Appendix I. Changes
附录一.更改
This appendix briefly lists the differences between RTSP 1.0 [RFC2326] and RTSP 2.0 for an informational purpose. For implementers of RTSP 2.0, it is recommended to read carefully through this memo and not to rely on the list of changes below to adapt from RTSP 1.0 to RTSP 2.0, as RTSP 2.0 is not intended to be backwards compatible with RTSP 1.0 [RFC2326] other than the version negotiation mechanism.
本附录简要列出了RTSP 1.0[RFC2326]和RTSP 2.0之间的差异，以供参考。对于RTSP 2.0的实施者，建议仔细阅读本备忘录，不要依赖下面的更改列表从RTSP 1.0调整到RTSP 2.0，因为RTSP 2.0不打算与RTSP 1.0[RFC2326]向后兼容，而不是版本协商机制。
The following protocol elements were removed in RTSP 2.0 compared to RTSP 1.0:
与RTSP 1.0相比，RTSP 2.0中删除了以下协议元素：
o the RECORD and ANNOUNCE methods and all related functionality (including 201 (Created) and 250 (Low On Storage Space) status codes);
o 记录和宣布方法以及所有相关功能（包括201（已创建）和250（存储空间不足）状态代码）；
o the use of UDP for RTSP message transport (due to missing interest and to broken specification);
o 使用UDP进行RTSP消息传输（由于兴趣缺失和规范不规范）；
o the use of PLAY method for keep-alive in Play state.
o 在播放状态下使用播放方法保持活动状态。
The following protocol elements were added or changed in RTSP 2.0 compared to RTSP 1.0:
与RTSP 1.0相比，在RTSP 2.0中添加或更改了以下协议元素：
o RTSP session TEARDOWN from the server to the client;
o 从服务器到客户端的RTSP会话断开；
o IPv6 support;
o IPv6支持；
o extended IANA registries (e.g., transport headers parameters, transport-protocol, profile, lower-transport, and mode);
o 扩展IANA注册表（例如，传输头参数、传输协议、配置文件、较低传输和模式）；
o request pipelining for quick session start-up;
o 请求快速启动会话的管道；
o fully reworked state machine;
o 完全返工的状态机；
o RTSP messages now use URIs rather than URLs;
o RTSP消息现在使用URI而不是URL；
o incorporated much of related HTTP text ([RFC2616]) in this memo, compared to just referencing the sections in HTTP, to avoid ambiguities;
o 与仅引用HTTP中的章节相比，在本备忘录中纳入了大量相关HTTP文本（[RFC2616]），以避免歧义；
o the REDIRECT method was expanded and diversified for different situations;
o 重定向方法针对不同情况进行了扩展和多样化；
o Includes a new section about how to set up different media-transport alternatives and their profiles in addition to lower-layer protocols. This caused the appendix on RTP interaction to be moved to the new section instead of being in the part that describes RTP. The section also includes guidelines what to consider when writing usage guidelines for new protocols and profiles;
o 包括一个新的部分，介绍如何设置不同的媒体传输备选方案及其配置文件以及较低层协议。这导致关于RTP交互的附录被移至新的部分，而不是描述RTP的部分。该部分还包括在编写新协议和配置文件使用指南时应考虑的指导原则；
o Added an asynchronous notification method PLAY_NOTIFY. This method is used by the RTSP server to asynchronously notify clients about session changes while in Play state. To a limited extent, this is comparable with some implementations of ANNOUNCE in RTSP 1.0 not intended for Recording.
o 添加了异步通知方法PLAY\u NOTIFY。RTSP服务器使用此方法在播放状态下异步通知客户端会话更改。在一定程度上，这与RTSP 1.0中的一些不用于录制的公告实现相当。
The below changes have been made to RTSP 1.0 (RFC 2326) when defining RTSP 2.0. Note that this list does not reflect minor changes in wording or correction of typographical errors.
在定义RTSP 2.0时，对RTSP 1.0（RFC 2326）进行了以下更改。请注意，此列表不反映措辞上的细微变化或印刷错误的更正。
o The section on minimal implementation was deleted. Instead, the main part of the specification defines the core of RTSP 2.0.
o 删除了关于最低限度实施的部分。相反，规范的主要部分定义了RTSP 2.0的核心。
o The Transport header has been changed in the following ways:
o 传输标头已通过以下方式更改：
* The ABNF has been changed to define that extensions are possible and that unknown parameters result in servers ignoring the transport specification.
* ABNF已更改为定义扩展是可能的，并且未知参数会导致服务器忽略传输规范。
* To prevent backwards compatibility issues, any extension or new parameter requires the usage of a feature tag combined with the Require header.
* 为了防止向后兼容性问题，任何扩展或新参数都需要使用与Require头结合使用的feature标记。
* Syntax ambiguities with the Mode parameter have been resolved.
* 模式参数的语法歧义已得到解决。
* Syntax error with ";" for multicast and unicast has been resolved.
* 已解决多播和单播的“；”语法错误。
* Two new addressing parameters have been defined: src_addr and dest_addr. These replace the parameters "port", "client_port", "server_port", "destination", and "source".
* 定义了两个新的寻址参数：src_addr和dest_addr。这些替换参数“端口”、“客户端端口”、“服务器端口”、“目的地”和“源”。
* Support for IPv6 explicit addresses in all address fields has been included.
* 包括在所有地址字段中支持IPv6显式地址。
* To handle URI definitions that contain ";" or ",", a quoted-URI format has been introduced and is required.
* 为了处理包含“；”或“，”的URI定义，引入了带引号的URI格式，这是必需的。
* IANA registries for the transport header parameters, transport-protocol, profile, lower-transport, and mode have been defined.
* 已定义传输头参数、传输协议、配置文件、较低传输和模式的IANA注册表。
* The Transport header's interleaved parameter's text was made more strict and uses formal requirements levels. It was also clarified that the interleaved channels are symmetric and that it is the server that sets the channel numbers.
* 传输头的交错参数的文本变得更加严格，并使用正式的需求级别。还澄清了交织信道是对称的，并且是服务器设置信道号。
* It has been clarified that the client can't request of the server to use a certain RTP SSRC, using a request with the transport parameter SSRC.
* 已经澄清，客户端不能使用带有传输参数SSRC的请求请求服务器使用某个RTP SSRC。
* Syntax definition for SSRC has been clarified to require 8HEX. It has also been extended to allow multiple values for clients supporting this version.
* SSRC的语法定义已经澄清，需要8HEX。它还被扩展以允许支持此版本的客户端具有多个值。
* Clarified the text on the Transport header's "dest_addr" parameters regarding what security precautions the server is required to perform.
* 澄清了传输标头“dest_addr”参数中有关服务器需要执行哪些安全预防措施的文本。
o The Range formats have been changed in the following way:
o 范围格式已按以下方式更改：
* The NPT format has been given an initial NPT identifier that must now be used.
* NPT格式已获得初始NPT标识符，现在必须使用该标识符。
* All formats now support initial open-ended formats of type "npt=-10" and also format only "Range: smpte" ranges for usage with GET_PARAMETER requests.
* 所有格式现在都支持类型为“npt=-10”的初始开放式格式，并且还支持仅格式化“Range:smpte”范围，以便与GET_参数请求一起使用。
* The npt-hhmmss notation now follows ISO 8601 more strictly.
* npt hhmmss符号现在更严格地遵循ISO 8601。
o RTSP message handling has been changed in the following ways:
o RTSP消息处理已通过以下方式更改：
* RTSP messages now use URIs rather than URLs.
* RTSP消息现在使用URI而不是URL。
* It has been clarified that a 4xx message due to a missing CSeq header shall be returned without a CSeq header.
* 已经澄清的是，由于缺少CSeq报头而导致的4xx消息应在没有CSeq报头的情况下返回。
* The 300 (Multiple Choices) response code has been removed.
* 300（多选）响应代码已删除。
* Rules for how to handle the timing out RTSP messages have been added.
* 添加了有关如何处理超时RTSP消息的规则。
* Extended Pipelining rules allowing for quick session startup.
* 允许快速启动会话的扩展管道规则。
* Sequence numbering and proxy handling of sequence numbers have been defined, including cases when responses arrive out of order.
* 序列号和序列号的代理处理已经定义，包括响应无序到达的情况。
o The HTTP references have been updated to first RFCs 2616 and 2617 and then to RFC 7230-7235. Most of the text has been copied and then altered to fit RTSP into this specification. The Public and the Content-Base headers have also been imported from RFC 2068 so that they are defined in the RTSP specification. Known effects on RTSP due to HTTP clarifications:
o HTTP引用已首先更新为RFC 2616和2617，然后更新为RFC 7230-7235。大部分文本已被复制，然后进行修改，以使RTSP符合本规范。还从RFC 2068导入了Public和Content-Base头，以便在RTSP规范中定义它们。HTTP澄清对RTSP的已知影响：
* Content-Encoding header can include encoding of type "identity".
* 内容编码头可以包括“标识”类型的编码。
o The state machine section has been completely rewritten. It now includes more details and is also more clear about the model used.
o 状态机部分已完全重写。它现在包含了更多的细节，并且对所使用的模型也更加清楚。
o An IANA section has been included that contains a number of registries and their rules. This will allow us to use IANA to keep track of RTSP extensions.
o 已包括一个IANA部分，其中包含许多注册中心及其规则。这将允许我们使用IANA跟踪RTSP扩展。
o The transport of RTSP messages has seen the following changes:
o RTSP消息的传输发生了以下变化：
* The use of UDP for RTSP message transport has been deprecated due to missing interest and to broken specification.
* 由于缺少兴趣和不符合规范，已不推荐将UDP用于RTSP消息传输。
* The rules for how TCP connections are to be handled have been clarified. Now it is made clear that servers should not close the TCP connection unless they have been unused for significant time.
* 关于如何处理TCP连接的规则已经澄清。现在很清楚，服务器不应该关闭TCP连接，除非它们已经被闲置了很长时间。
* Strong recommendations why servers and clients should use persistent connections have also been added.
* 还添加了关于服务器和客户端应使用持久连接的强烈建议。
* There is now a requirement on the servers to handle non-persistent connections as this provides fault tolerance.
* 现在服务器上需要处理非持久性连接，因为这提供了容错能力。
* Added wording on the usage of Connection:Close for RTSP.
* 增加了关于连接用法的措辞：关闭RTSP。
* Specified usage of TLS for RTSP messages, including a scheme to approve a proxy's TLS connection to the next hop.
* 为RTSP消息指定TLS的用法，包括批准代理与下一跳的TLS连接的方案。
o The following header-related changes have been made:
o 已进行以下与标题相关的更改：
* Accept-Ranges response-header has been added. This header clarifies which range formats can be used for a resource.
* 已添加接受范围响应标头。此标题说明可用于资源的范围格式。
* Fixed the missing definitions for the Cache-Control header. Also added to the syntax definition the missing delta-seconds for max-stale and min-fresh parameters.
* 修复了缓存控件标头缺少的定义。还将max stale和min fresh参数缺少的增量秒添加到语法定义中。
* Put requirement on CSeq header that the value is increased by one for each new RTSP request. A recommendation to start at 0 has also been added.
* 在CSeq头上放置一个要求，即每个新RTSP请求的值增加一个。还添加了从0开始的建议。
* Added a requirement that the Date header must be used for all messages with a message body and the Server should always include it.
* 添加了一个要求，即日期头必须用于所有具有消息正文的消息，并且服务器应始终包含该消息。
* Removed the possibility of using Range header with Scale header to indicate when it is to be activated, since it can't work as defined. Also, added a rule that lack of Scale header in a response indicates lack of support for the header. feature tags for scaled playback have been defined.
* 删除了使用范围标头和刻度标头指示何时激活的可能性，因为它无法按定义工作。此外，还添加了一条规则，即响应中缺少Scale头表示缺少对头的支持。已定义缩放播放的特征标记。
* The Speed header must now be responded to in order to indicate support and the actual speed going to be used. A feature tag is defined. Notes on congestion control were also added.
* 现在必须响应速度收割台，以指示支持和将要使用的实际速度。定义了一个特征标记。还增加了关于拥塞控制的说明。
* The Supported header was borrowed from SIP [RFC3261] to help with the feature negotiation in RTSP.
* 受支持的标头是从SIP[RFC3261]借用的，以帮助RTSP中的功能协商。
* Clarified that the Timestamp header can be used to resolve retransmission ambiguities.
* 阐明时间戳标头可用于解决重传歧义。
* The Session header text has been expanded with an explanation on keep-alive and which methods to use. SET_PARAMETER is now recommended to use if only keep-alive within RTSP is desired.
* 会话标题文本已展开，并解释了“保持活动”以及使用哪些方法。如果只需要在RTSP内保持活动状态，现在建议使用SET_参数。
* It has been clarified how the Range header formats are used to indicate pause points in the PAUSE response.
* 已经澄清了如何使用范围标题格式来指示暂停响应中的暂停点。
* Clarified that RTP-Info URIs that are relative use the Request-URI as base URI. Also clarified that the used URI must be the one that was used in the SETUP request. The URIs are now also
* 阐明了相对的RTP信息URI使用请求URI作为基本URI。还澄清了使用的URI必须是安装请求中使用的URI。uri现在也在使用中
required to be quoted. The header also expresses the SSRC for the provided RTP timestamp and sequence number values.
需要报价。标头还表示所提供RTP时间戳和序列号值的SSRC。
* Added text that requires the Range to always be present in PLAY responses. Clarified what should be sent in case of live streams.
* 添加了要求范围始终出现在播放响应中的文本。澄清在实时流情况下应发送的内容。
* The headers table has been updated using a structure borrowed from SIP. Those tables convey much more information and should provide a good overview of the available headers.
* headers表已使用从SIP借用的结构进行了更新。这些表传递了更多的信息，应该能够很好地概述可用的标题。
* It has been clarified that any message with a message body is required to have a Content-Length header. This was the case in RFC 2326, but could be misinterpreted.
* 已经澄清，任何具有消息正文的消息都需要具有内容长度头。RFC 2326中就是这种情况，但可能会被误解。
* ETag has changed its name to MTag.
* ETag已将其名称更改为MTag。
* To resolve functionality around MTag, the MTag and If-None-Match header have been added from HTTP with necessary clarification in regard to RTSP operation.
* 为了解决有关MTag的功能，从HTTP添加了MTag和If None Match标头，并对RTSP操作进行了必要的说明。
* Imported the Public header from HTTP (RFC 2068 [RFC2068]) since it has been removed from HTTP due to lack of use. Public is used quite frequently in RTSP.
* 已从HTTP（RFC 2068[RFC2068]）导入公共标头，因为由于缺少使用，它已从HTTP中删除。公共在RTSP中使用非常频繁。
* Clarified rules for populating the Public header so that it is an intersection of the capabilities of all the RTSP agents in a chain.
* 阐明了填充公共头的规则，使其成为链中所有RTSP代理功能的交叉点。
* Added the Media-Range header for listing the current availability of the media range.
* 添加了媒体范围标题，以列出媒体范围的当前可用性。
* Added the Notify-Reason header for giving the reason when sending PLAY_NOTIFY requests.
* 添加了Notify Reason标头，用于在发送PLAY_Notify请求时给出原因。
* A new header Seek-Style has been defined to direct and inform how any seek operation should/have been performed.
* 定义了一种新的标头搜索样式，用于指示和通知应如何执行任何搜索操作。
o The Protocol Syntax has been changed in the following way:
o 协议语法已按以下方式更改：
* All ABNF definitions are updated according to the rules defined in RFC 5234 [RFC5234] and have been gathered in a separate section (Section 20).
* 所有ABNF定义均根据RFC 5234[RFC5234]中定义的规则进行更新，并收集在单独的章节（第20节）中。
* The ABNF for the User-Agent and Server headers have been corrected.
* 已更正用户代理和服务器头的ABNF。
* Some definitions in the introduction regarding the RTSP session have been changed.
* 介绍中有关RTSP会话的一些定义已更改。
* The protocol has been made fully IPv6 capable.
* 该协议已完全支持IPv6。
* The CHAR rule has been changed to exclude NULL.
* CHAR规则已更改为排除NULL。
o The Status codes have been changed in the following ways:
o 状态代码已通过以下方式更改：
* The use of status code 303 (See Other) has been deprecated as it does not make sense to use in RTSP.
* 由于在RTSP中使用状态代码303没有意义，因此不推荐使用状态代码303（请参阅其他）。
* The never-defined status code 411 "Length Required" has been completely removed.
* 从未定义的状态代码411“所需长度”已完全删除。
* When sending response 451 (Parameter Not Understood) and 458 (Parameter Is Read-Only), the response body should contain the offending parameters.
* 当发送响应451（参数不可理解）和458（参数为只读）时，响应正文应包含有问题的参数。
* Clarification on when a 3rr redirect status code can be received has been added. This includes receiving 3rr as a result of a request within an established session. This provides clarification to a previous unspecified behavior.
* 已添加关于何时可以接收3rr重定向状态代码的说明。这包括在已建立的会话中根据请求接收3rr。这为以前未指定的行为提供了说明。
* Removed the 201 (Created) and 250 (Low On Storage Space) status codes as they are only relevant to recording, which is deprecated.
* 删除了201（已创建）和250（存储空间不足）状态代码，因为它们仅与录制相关，已弃用。
* Several new status codes have been defined: 464 (Data Transport Not Ready Yet), 465 (Notification Reason Unknown), 470 (Connection Authorization Required), 471 (Connection Credentials Not Accepted), and 472 (Failure to Establish Secure Connection).
* 已经定义了几个新的状态代码：464（数据传输尚未就绪）、465（通知原因未知）、470（需要连接授权）、471（未接受连接凭据）和472（无法建立安全连接）。
o The following functionality has been deprecated from the protocol:
o 以下功能已从协议中弃用：
* The use of Queued Play.
* 排队播放的使用。
* The use of PLAY method for keep-alive in Play state.
* 在播放状态下使用播放方法保持活动状态。
* The RECORD and ANNOUNCE methods and all related functionality. Some of the syntax has been removed.
* 记录和宣布方法以及所有相关功能。某些语法已被删除。
* The possibility to use timed execution of methods with the time parameter in the Range header.
* 在范围标头中使用时间参数的方法的定时执行的可能性。
* The description on how rtspu works is not part of the core specification and will require external description. Only that it exists is mentioned here and some requirements for the transport are provided.
* 关于rtspu如何工作的描述不是核心规范的一部分，需要外部描述。这里只提到它的存在，并提供了一些运输要求。
o The following changes have been made in relation to methods:
o 对方法进行了以下更改：
* The OPTIONS method has been clarified with regard to the use of the Public and Allow headers.
* 已就公共和允许标题的使用澄清了选项方法。
* Added text clarifying the usage of SET_PARAMETER for keep-alive and usage without a body.
* 添加的文本澄清了“保持活动”的SET_参数的用法以及无正文的用法。
* PLAY method is now allowed to be pipelined with the pipelining of one or more SETUP requests following the initial that generates the session for aggregated control.
* PLAY方法现在允许与一个或多个安装请求的管道连接，在生成聚合控制会话的初始设置之后。
* REDIRECT has been expanded and diversified for different situations.
* 重定向已针对不同的情况进行了扩展和多样化。
* Added a new method PLAY_NOTIFY. This method is used by the RTSP server to asynchronously notify clients about session changes.
* 添加了一个新方法PLAY_NOTIFY。RTSP服务器使用此方法异步通知客户端会话更改。
o Wrote a new section about how to set up different media-transport alternatives and their profiles as well as lower-layer protocols. This caused the appendix on RTP interaction to be moved to the new section instead of being in the part that describes RTP. The new section also includes guidelines what to consider when writing usage guidelines for new protocols and profiles.
o 写了一个关于如何设置不同的媒体传输方案及其配置文件以及低层协议的新章节。这导致关于RTP交互的附录被移至新的部分，而不是描述RTP的部分。新的章节还包含了在编写新协议和配置文件使用指南时要考虑的指导原则。
o Setup and usage of independent TCP connections for transport of RTP has been specified.
o 已指定用于传输RTP的独立TCP连接的设置和使用。
o Added a new section describing the available mechanisms to determine if functionality is supported, called "Capability Handling". Renamed option-tags to feature tags.
o 添加了一个新的部分，描述用于确定功能是否受支持的可用机制，称为“功能处理”。将选项标记重命名为要素标记。
o Added a Contributors section with people who have contributed actual text to the specification.
o 添加了“贡献者”部分，其中包含为规范贡献实际文本的人员。
o Added a section "Use Cases" that describes the major use cases for RTSP.
o 添加了一节“用例”，描述RTSP的主要用例。
o Clarified the usage of a=range and how to indicate live content that are not seekable with this header.
o 阐明了a=range的用法，以及如何指示不可通过此标题查找的实时内容。
o Text specifying the special behavior of PLAY for live content.
o 指定实时内容播放的特殊行为的文本。
o Security features of RTSP have been clarified:
o RTSP的安全特性已得到澄清：
* HTTP-based authorization has been clarified requiring both Basic and Digest support
* 基于HTTP的授权已得到澄清，需要基本和摘要支持
* TLS support has been mandated
* TLS支持已获授权
* If one implements RTP, then SRTP and defined MIKEY-based key-exchange must be supported
* 如果实现RTP，则必须支持SRTP和定义的基于MIKEY的密钥交换
* Various minor mitigations discussed or resulted in protocol changes.
* 讨论或导致协议变更的各种次要缓解措施。
Acknowledgements
致谢
This memorandum defines RTSP version 2.0, which is a revision of the Proposed Standard RTSP version 1.0 defined in [RFC2326]. The authors of RFC 2326 are Henning Schulzrinne, Anup Rao, and Robert Lanphier.
本备忘录定义了RTSP版本2.0，它是[RFC2326]中定义的拟议标准RTSP版本1.0的修订版。RFC2326的作者是Henning Schulzrinne、Anup Rao和Robert Lanphier。
Both RTSP version 1.0 and RTSP version 2.0 borrow format and descriptions from HTTP/1.1.
RTSP版本1.0和RTSP版本2.0都借用了HTTP/1.1中的格式和说明。
Robert Sparks and especially Elwyn Davies provided very valuable and detailed reviews in the IETF Last Call that greatly improved the document and resolved many issues, especially regarding consistency.
Robert Sparks，尤其是Elwyn Davies在IETF上次通话中提供了非常有价值和详细的审查，极大地改进了文档并解决了许多问题，特别是在一致性方面。
This document has benefited greatly from the comments of all those participating in the MMUSIC WG. In addition to those already mentioned, the following individuals have contributed to this specification:
本文件从所有参与MMUSIC工作组的人员的意见中受益匪浅。除上述人员外，以下人员对本规范做出了贡献：
Rahul Agarwal, Claudio Allocchio, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, Bruce Butterfield, Steve Casner, Maureen Chesire, Jinhang Choi, Francisco Cortes, Elwyn Davies, Spencer Dawkins, Kelly Djahandari, Martin Dunsmuir, Adrian Farrel, Stephen Farrell, Ross Finlayson, Eric Fleischman, Jay Geagan, Andy Grignon, Christian Groves, V. Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, John K. Ho, Patrick Hoffman, Go Hori, Philipp Hoschka, Anne Jones, Ingemar Johansson, Jae-Hwan Kim, Anders Klemets, Ruth Lang, Barry Leiba, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Chris Lonvick, Xavier Marjou, Thomas Marshall, Rob McCool, Martti Mela, David Oran, Joerg Ott, Joe Pallas, Maria Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Pekka Pessi, Igor Plotnikov, Pete Resnick, Peter Saint-Andre, Holger Schmidt, Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Francis Stracke, Geetha Srikantan, Scott Taylor, David Walker, Stephan Wenger, Dale R. Worley, and Byungjo Yoon, and especially Flemming Andreasen.
Rahul Agarwal、Claudio Allocchio、Jeff Ayars、Milko Boic、Torsten Braun、Brent Browning、Bruce Butterfield、Steve Casner、Maureen Chesire、Jinhang Choi、Francisco Cortes、Elwyn Davies、Spencer Dawkins、Kelly Djahandari、Martin Dunsmuir、Adrian Farrel、Stephen Farrell、Ross Finlayson、Eric Fleischman、Jay Geagan、Andy Grignon、Christian Groves、，V.古鲁帕萨德、彼得·海特、马克·汉德利、布拉德·赫夫塔·高布、沃尔克·希尔特、约翰·霍夫曼、帕特里克·霍夫曼、戈·霍里、菲利普·霍什卡、安妮·琼斯、英格玛·约翰森、杰焕·金、安德斯·克莱梅茨、露丝·朗、巴里·莱巴、斯蒂芬妮·莱夫、乔纳森·伦诺克斯、爱德华多·拉赫、克里斯·隆维克、泽维尔·马约、托马斯·马歇尔、罗布·麦库尔、玛蒂·梅拉、大卫·奥兰、，约格·奥特、乔·帕拉斯、玛丽亚·帕帕佐普利、苏哈尔·帕特尔、埃玛·帕奇、阿拉古·佩里扬南、科林·帕金斯、佩卡·佩西、伊戈尔·普洛特尼科夫、皮特·雷斯尼克、彼得·圣安德烈、霍尔格·施密特、乔纳森·塞根、皮纳基·沙阿、大卫·辛格、利奥·西翁、杰夫·史密斯、亚历山大·索科尔斯基、戴尔·斯坦曼、约翰·弗朗西斯·斯特拉克、吉塔·斯里坎坦、斯科特·泰勒、大卫·沃克、，斯蒂芬·温格、戴尔·R·沃利和比昂乔·尹，尤其是弗莱明·安德烈森。
Contributors
贡献者
The following people have made written contributions that were included in the specification:
以下人员提供了规范中包含的书面意见：
o Tom Marshall contributed text on the usage of 3rr status codes.
o Tom Marshall提供了关于3rr状态代码使用的文本。
o Thomas Zheng contributed text on the usage of the Range in PLAY responses and proposed an earlier version of the PLAY_NOTIFY method.
o 托马斯·郑（Thomas Zheng）提供了关于在游戏响应中使用范围的文本，并提出了早期版本的PLAY_NOTIFY方法。
o Sean Sheedy contributed text on the timeout behavior of RTSP messages and connections, the 463 (Destination Prohibited) status code, and proposed an earlier version of the PLAY_NOTIFY method.
o Sean Sheedy就RTSP消息和连接的超时行为、463（禁止目的地）状态代码提供了文本，并提出了PLAY_NOTIFY方法的早期版本。
o Greg Sherwood proposed an earlier version of the PLAY_NOTIFY method.
o Greg Sherwood提出了PLAY_NOTIFY方法的早期版本。
o Fredrik Lindholm contributed text about the RTSP security framework.
o Fredrik Lindholm提供了关于RTSP安全框架的文本。
o John Lazzaro contributed the text for RTP over Independent TCP.
o John Lazzaro通过独立TCP为RTP提供了文本。
o Aravind Narasimhan contributed by rewriting "Media-Transport Alternatives" (Appendix C) and making editorial improvements on a number of places in the specification.
o Aravind Narasimhan通过重写“媒体传输备选方案”（附录C）并对规范中的一些地方进行编辑改进做出了贡献。
o Torbjorn Einarsson has done some editorial improvements of the text.
o Torbjorn Einarsson对文本进行了一些编辑改进。
Authors' Addresses
作者地址
Henning Schulzrinne Columbia University 1214 Amsterdam Avenue New York, NY 10027 United States of America
美国纽约州纽约市阿姆斯特丹大道1214号亨宁·舒尔兹林内哥伦比亚大学，邮编：10027
Email: schulzrinne@cs.columbia.edu
Email: schulzrinne@cs.columbia.edu
Anup Rao Cisco United States of America
Anup Rao思科美国公司
Email: anrao@cisco.com
Email: anrao@cisco.com
Rob Lanphier San Francisco, CA United States of America
美利坚合众国旧金山Rob Lanphier
Email: robla@robla.net
Email: robla@robla.net
Magnus Westerlund Ericsson Faeroegatan 2 Stockholm SE-164 80 Sweden
Magnus Westerlund Ericsson Faeroegatan 2斯德哥尔摩SE-164 80瑞典
Email: magnus.westerlund@ericsson.com
Email: magnus.westerlund@ericsson.com
Martin Stiemerling (editor) University of Applied Sciences Darmstadt Haardtring 100 64295 Darmstadt Germany
Martin Stiemerling（编辑）应用科学大学达姆施塔特哈德林100德国达姆施塔特64295
Email: mls.ietf@gmail.com
URI: http://www.stiemerling.org
Email: mls.ietf@gmail.com
URI: http://www.stiemerling.org