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
        
1. Introduction
1. 介绍

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是三个规范性附录。其他附录包括许多讨论变更、用例、不同注意事项或动机的信息部分。

2. Protocol Overview
2. 协议概述

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消息的强制传输。

2.1. Presentation Description
2.1. 演示文稿说明

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]来描述演示文稿。

2.2. Session Establishment
2.2. 会议设立

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节)通知客户当前可用介质的时间范围。

2.3. Media Delivery Control
2.3. 媒体传送控制

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小时。在内容中的特定点暂停的客户端可能无法再检索内容。如果客户端在恢复暂停点之前等待的时间过长,则内容可能不再可用。在这种情况下,暂停点将调整到可用介质中最近的点。

2.4. Session Parameter Manipulations
2.4. 会话参数操作

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节)预先确定可用的功能。

2.5. Media Delivery
2.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序列号,从而使客户端能够顺利清空缓冲区。

2.5.1. Media Delivery Manipulations
2.5.1. 媒体传递操纵

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的上限,以强制服务器以低于标称媒体速率的速度传输。

2.6. Session Maintenance and Termination
2.6. 会话维护和终止

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方法。

2.7. Extending RTSP
2.7. 扩展RTSP

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_参数的参数格式来完成。

3. Document Conventions
3. 文件惯例
3.1. Notational Conventions
3.1. 符号约定

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扩展规范中的进一步定义,则无法以标准化方式使用此类功能。

3.2. Terminology
3.2. 术语

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,而不是通过名称或该资源的其他属性标识资源。

4. Protocol Parameters
4. 协议参数
4.1. RTSP Version
4.1. RTSP版本

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。不应发送前导零,收件人必须忽略前导零。

4.2. RTSP IRI and URI
4.2. RTSP IRI和URI

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媒体控制协议一起使用。

4.3. Session Identifiers
4.3. 会话标识符

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节)。但是,请注意,会话标识符不提供任何防止会话劫持的安全性,除非客户端、服务器和受信任的代理对其保密。

4.4. Media-Time Formats
4.4. 媒体时间格式

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节)中也用于请求响应中使用的时间格式。

4.4.1. SMPTE-Relative Timestamps
4.4.1. 相对时间戳

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
        
4.4.2. Normal Play Time
4.4.2. 正常播放时间

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”常量允许客户端请求接收实时提要,而不是存储或延迟的版本。这是必要的,因为绝对时间和零时间都不适合这种情况。

4.4.3. Absolute Time
4.4.3. 绝对时间

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

4.5. Feature Tags
4.5. 要素标签

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节中作了进一步描述,该节涉及功能处理。

4.6. Message Body Tags
4.6. 消息正文标记

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报头验证相同的会话描述是否适用于新位置的媒体。

4.7. Media Properties
4.7. 媒体属性

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.

为了涵盖上述用途,指定了以下具有适当值的介质属性。

4.7.1. Random Access and Seeking
4.7.1. 随机存取和搜索

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节)。

4.7.2. Retention
4.7.2. 保持

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.

持续时间:介质(以片段或单位为单位)将保留指定的持续时间。

4.7.3. Content Modifications
4.7.3. 内容修改

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.

时间进度:随着时间的推移,新内容将变得可用。如果内容也被保留,它将变得更长,因为可以访问起点和当前可用点之间的所有内容。如果媒体服务器使用滑动窗口策略进行保留,则起始点也会随着时间的推移而改变。

4.7.4. Supported Scale Factors
4.7.4. 支持比例因子

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”。由于由拼接片段组成的内容或由带外机制动态更新的内容,可以在内容中的任何点更新“缩放”属性。

4.7.5. Mapping to the Attributes
4.7.5. 映射到属性

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
        
5. RTSP Message
5. RTSP消息

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.

请求包含一个方法、该方法所操作的对象以及进一步描述该方法的参数。方法是幂等的,除非另有说明。方法还被设计为只需要很少或不需要在媒体服务器上进行状态维护。

5.1. Message Types
5.1. 消息类型

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。

5.2. Message Headers
5.2. 消息头

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节)头中。

5.3. Message Body
5.3. 消息体

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节))不允许发送消息体,则请求或响应中不得包含消息体。如果在非预期的情况下在消息中接收到消息正文,则应丢弃消息正文数据。这是为了允许将来的扩展定义消息体的可选使用。

5.4. Message Length
5.4. 消息长度

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.

给定返回的表示描述的中等长度,服务器应该始终能够确定其长度,即使它是动态生成的,这使得分块传输编码变得不必要。

6. General-Header Fields
6. 常规标题字段

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中使用的常规标头

7. Request
7. 要求

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 (可选)消息正文,由一行或多行组成。消息正文的长度(以八位字节为单位)由内容长度消息头指示。

7.1. Request Line
7.1. 请求行

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
        
7.2. Request-Header Fields
7.2. 请求头字段

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标头中包含相应的功能标签,以确保标头的处理。

8. Response
8. 回答

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列出了有效的响应代码及其可使用的方法。

8.1. Status-Line
8.1. 状态行

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
        
8.1.1. Status Code and Reason Phrase
8.1.1. 状态代码和原因短语

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方法的使用

8.2. Response Headers
8.2. 响应头

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.

只有结合协议版本的更改,才能可靠地扩展响应头名称。然而,在请求中使用特征标记允许响应方了解响应接收方的能力。如果通信中的所有各方都将响应头识别为响应头,则可以为新的或实验性的头赋予响应头的语义。必须忽略响应中无法识别的标题。

9. Message Body
9. 消息体

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.

在本节中,发件人和收件人都指客户机或服务器,具体取决于谁发送和谁接收消息正文。

9.1. Message Body Header Fields
9.1. 消息正文头字段

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.

扩展头机制允许在不更改协议的情况下定义其他消息正文头字段,但不能假定收件人可以识别这些字段。收件人必须忽略无法识别的标题字段,并由代理转发。

9.2. Message Body
9.2. 消息体

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.

消息的内容长度是内容的长度,以八位字节为单位。

9.3. Message Body Format Negotiation
9.3. 消息体格式协商

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.

支持的格式及其协商是按照每个方法和方向(请求或响应主体)单独完成的。还应根据每个方法和每个方向规定支持用作请求和响应中消息体的特定媒体类型的要求。

10. Connections
10. 连接

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连接上聚合多个客户端请求时,它还可以用于跟踪不同的请求。

10.1. Reliability and Acknowledgements
10.1. 可靠性和确认

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节)。

10.2. Using Connections
10.2. 使用连接

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.

这种情况可能发生在两种涉及代理的情况下。第一种是客户端使用公共客户端到代理连接在不同服务器上发出会话请求。第二种是用于服务器到客户端的请求,例如服务器通过公共传输连接发送重定向,该传输连接是代理为其不同的连接客户端创建的。

10.3. Closing Connections
10.3. 关闭连接

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节的定义正确终止。

10.4. Timing Out Connections and RTSP Messages
10.4. 超时连接和RTSP消息

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秒值是超时的一半,在请求方发生超时之前,有合理的成功传递机会。

10.5. Showing Liveness
10.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秒。在已建立的会话中,不能更改会话超时的长度。

10.6. Use of IPv6
10.6. IPv6的使用

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节))。

10.7. Overload Control
10.7. 过载控制

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倍范围内选择一个随机值。

11. Capability Handling
11. 能力处理

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头的结果,其中一个或多个功能不受支持。此信息允许请求者充分利用情况,因为它知道哪些功能不受支持。

11.1. Feature Tag: play.basic
11.1. 功能标签:play.basic

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的特性,还不如将本规范作为一个整体,并包括规范定义为必需的必要特性。

12. Pipelining Support
12. 管道支撑

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.

如果管道化请求建立在成功完成一个或多个先前请求的基础上,请求者必须验证所有请求是否按预期执行。一个常见的例子是两个设置请求和一个播放请求。如果其中一个设置请求意外失败,则仍可成功执行播放请求。但是,由于只播放一种媒体而不是两种媒体,因此生成的演示文稿不会如请求客户端所预期的那样。在这种情况下,客户端可以发送暂停请求,更正失败的设置请求,然后请求播放。

13. Method Definitions
13. 方法定义

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头。

13.1. OPTIONS
13.1. 选择权

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消息”功能标记是一个虚构的功能。

13.2. DESCRIBE
13.2. 描述

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支持充当“助手应用程序”的功能,该应用程序从用户界面或适合于客户端操作环境的其他方式接受媒体初始化文件。

13.3. SETUP
13.3. 设置

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.

如果会话上的设置请求因任何原因失败,则会话状态以及关联流的传输和其他参数的值必须保持不变,就像服务器从未收到设置请求一样。

13.3.1. Changing Transport Parameters
13.3.1. 改变运输参数

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,则服务器必须在设置响应中包含必要的同步信息。但是,如果可能,服务器应该避免更改同步信息。

13.4. PLAY
13.4. 玩

This section describes the usage of the PLAY method in general, for aggregated sessions, and in different usage scenarios.

本节介绍PLAY方法的一般用法、聚合会话以及在不同使用场景中的用法。

13.4.1. General Usage
13.4.1. 一般用法

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
        
13.4.2. Aggregated Sessions
13.4.2. 聚合会话

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)之间的延迟。然而,客户机需要知道,使用此过程将导致在处理播放时建立的服务器状态的播放,即,在处理管道中播放请求之前的所有请求之后。由于任何先前请求的失败,该状态可能不是预期状态。客户机可以根据这些请求的响应轻松确定这一点。如果出现故障,客户端可以使用“暂停”停止媒体播放,并在发出另一个播放请求之前再次尝试建立预期状态。

13.4.3. Updating Current PLAY Requests
13.4.3. 更新当前播放请求

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
        
13.4.4. Playing On-Demand Media
13.4.4. 按需播放媒体

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节所述的一般用法。

13.4.5. Playing Dynamic On-Demand Media
13.4.5. 播放动态点播媒体

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节)。

13.4.6. Playing Live Media
13.4.6. 播放现场媒体

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标头表示支持绝对时间格式时,才能使用绝对时间格式。

13.4.7. Playing Live with Recording
13.4.7. 现场播放录音

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节中的注意事项适用。

13.4.8. Playing Live with Time-Shift
13.4.8. 实时播放时间转换

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节中的注意事项适用。

13.5. PLAY_NOTIFY
13.5. 播放通知

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节)。

13.5.1. End-of-Stream
13.5.1. 断流

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
        
13.5.2. Media-Properties-Update
13.5.2. 媒体属性更新

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
        
13.5.3. Scale-Change
13.5.3. 尺度变化

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
        
13.6. PAUSE
13.6. 暂停

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
        
13.7. TEARDOWN
13.7. 拆卸
13.7.1. Client to Server
13.7.1. 客户端到服务器

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
        
13.7.2. Server to Client
13.7.2. 服务器到客户端

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.

注意:代理负责接受其客户的拆卸响应;这些响应不得传递到重定向中的原始服务器或目标服务器。

13.8. GET_PARAMETER
13.8. 获取参数

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

13.9. SET_PARAMETER
13.9. 设置参数

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

13.10. REDIRECT
13.10. 重新使用

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
        
14. Embedded (Interleaved) Binary Data
14. 嵌入(交错)二进制数据

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}
        
15. Proxies
15. 代理

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的未来发展和使用。

15.1. Proxies and Protocol Extensions
15.1. 代理和协议扩展

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.

如果扩展必须被“传输修改”类型的代理所理解,那么扩展必须被分类为必须为代理实现的扩展。

15.2. Multiplexing and Demultiplexing of Messages
15.2. 消息的多路复用和解多路复用

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节定义了如何重写请求和响应。

16. Caching
16. 缓存

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缓存必须存储其缓存对象的内容类型、内容语言等,媒体缓存也必须存储表示描述。通常,缓存从表示描述中消除所有传输引用(例如,多播信息),因为这些传输引用独立于从缓存到客户端的数据交付。有关编码的信息保持不变。如果缓存能够转换缓存的媒体数据,它将创建一个新的表示描述,并提供所有可能的编码。

16.1. Validation Model
16.1. 验证模型

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.

根据服务器和缓存之间的传输容量调整的媒体流使缓存更加困难。服务器需要考虑它如何看待它所适应的媒体流的缓存,并可能指示任何缓存不缓存这些流。

16.1.1. Last-Modified Dates
16.1.1. 最后修改日期

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节)值通常用作缓存验证程序。简单来说,如果缓存项是在上次修改时间之后创建的,则认为缓存项有效。

16.1.2. Message Body Tag Cache Validators
16.1.2. 消息正文标记缓存验证程序

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节描述了消息正文标记

16.1.3. Weak and Strong Validators
16.1.3. 弱验证器和强验证器

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.

如果客户端希望对其只有上次修改时间且没有不透明验证器的值执行子范围检索,则仅当上次修改时间在此处描述的意义上很强时,它才可以执行此操作。

16.1.4. Rules for When to Use Message Body Tags and Last-Modified Dates
16.1.4. 何时使用邮件正文标记和上次修改日期的规则

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系统将对其接收的验证器做出最保守的假设。

16.1.5. Non-validating Conditionals
16.1.5. 非验证条件句

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.

消息体标记背后的原理是,只有服务作者足够了解资源的语义,能够选择适当的缓存验证机制,并且任何比八位字节相等更复杂的验证器比较函数的规范都会引发一系列蠕虫。因此,任何其他头的比较都不会用于验证缓存项。

16.2. Invalidation after Updates or Deletions
16.2. 更新或删除后无效

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引用的任何实体无效。

17. Status Code Definitions
17. 状态代码定义

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)都可能返回一个正文,其中包含有关错误的更多信息。

17.1. Informational 1xx
17.1. 信息性1xx
17.1.1. 100 Continue
17.1.1. 100继续

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节)。响应代理必须在请求完成后发送最终响应。

17.2. Success 2xx
17.2. 成功2xx

This class of status code indicates that the agent's request was successfully received, understood, and accepted.

此类状态代码表示代理的请求已成功接收、理解和接受。

17.2.1. 200 OK
17.2.1. 200行

The request has succeeded. The information returned with the response is dependent on the method used in the request.

请求已成功。随响应返回的信息取决于请求中使用的方法。

17.3. Redirection 3xx
17.3. 重定向3xx

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节)。

17.3.1. 300
17.3.1. 300

The 300 response code is not used in RTSP 2.0.

RTSP 2.0中未使用300响应代码。

17.3.2. 301 Moved Permanently
17.3.2. 301永久搬迁

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。此响应不得包含消息正文。响应中必须包含位置标头。

17.3.3. 302 Found
17.3.3. 302发现

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
        
17.3.4. 303 See Other
17.3.4. 303见其他

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]中允许使用此选项。

17.3.5. 304 Not Modified
17.3.5. 304未修改

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节)可用于以这种方式链接描述和设置。

17.3.6. 305 Use Proxy
17.3.6. 305使用代理

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响应只能由源服务器生成。

17.4. Client Error 4xx
17.4. 客户端错误4xx
17.4.1. 400 Bad Request
17.4.1. 400错误请求

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。

17.4.2. 401 Unauthorized
17.4.2. 401未经授权

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响应包含与先前响应相同的质询,并且用户代理已至少尝试了一次身份验证,则应向用户呈现响应中给出的消息正文,因为该消息正文可能包括相关诊断信息。

17.4.3. 402 Payment Required
17.4.3. 402需要付款

This code is reserved for future use.

此代码保留供将来使用。

17.4.4. 403 Forbidden
17.4.4. 403禁止

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(未找到)。

17.4.5. 404 Not Found
17.4.5. 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.

当代理不想透露请求被拒绝的确切原因或没有其他响应适用时,通常使用此状态代码。

17.4.6. 405 Method Not Allowed
17.4.6. 405方法不允许

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标头,其中包含请求资源的有效方法列表。如果请求试图使用安装过程中未指示的方法,也将使用此状态代码。

17.4.7. 406 Not Acceptable
17.4.7. 406不可接受

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.

如果响应可能不可接受,则用户代理应暂时停止接收更多数据,并向用户查询有关进一步操作的决定。

17.4.8. 407 Proxy Authentication Required
17.4.8. 407需要代理身份验证

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节),其中包含适用于所请求资源的代理的质询。

17.4.9. 408 Request Timeout
17.4.9. 408请求超时

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.

代理在准备等待的时间内未生成请求。代理可以在以后的任何时间重复请求而不进行修改。

17.4.10. 410 Gone
17.4.10. 410不见了

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响应主要用于通过通知接收者资源有意不可用以及服务器所有者希望删除指向该资源的远程链接来协助存储库维护任务。此类活动在有限的时间、促销服务和不再在服务器站点工作的个人资源中很常见。无需将所有永久不可用的资源标记为“已消失”,也无需将标记保留任何时间长度——这由服务器所有者自行决定。

17.4.11. 412 Precondition Failed
17.4.11. 412先决条件失败

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节匹配。此响应代码允许代理对当前资源元信息(头字段数据)设置前提条件,从而防止请求的方法应用于预期资源以外的资源。

17.4.12. 413 Request Message Body Too Large
17.4.12. 413请求消息正文太大

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标头字段,以指示该条件是临时的,并且在请求代理可以重试的时间之后。

17.4.13. 414 Request-URI Too Long
17.4.13. 414请求URI太长

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。

17.4.14. 415 Unsupported Media Type
17.4.14. 415不支持的媒体类型

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.

服务器拒绝为请求提供服务,因为请求的消息体的格式不受请求方法的请求资源支持。

17.4.15. 451 Parameter Not Understood
17.4.15. 451参数不理解

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).

请求的收件人不支持请求中包含的一个或多个参数。返回此错误消息时,代理应返回包含有问题参数的消息正文。

17.4.16. 452 Illegal Conference Identifier
17.4.16. 452非法会议标识符

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]中允许使用此选项。

17.4.17. 453 Not Enough Bandwidth
17.4.17. 453带宽不足

The request was refused because there was insufficient bandwidth. This may, for example, be the result of a resource reservation failure.

由于带宽不足,请求被拒绝。例如,这可能是资源保留失败的结果。

17.4.18. 454 Session Not Found
17.4.18. 454找不到会话

The RTSP session identifier in the Session header is missing, is invalid, or has timed out.

会话头中的RTSP会话标识符丢失、无效或已超时。

17.4.19. 455 Method Not Valid in This State
17.4.19. 455方法在此状态下无效

The agent cannot process this request in its current state. The response MUST contain an Allow header to make error recovery possible.

代理无法在其当前状态下处理此请求。响应必须包含允许标头,以使错误恢复成为可能。

17.4.20. 456 Header Field Not Valid for Resource
17.4.20. 456头字段对资源无效

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标头以通知代理允许哪些格式。

17.4.21. 457 Invalid Range
17.4.21. 457无效范围

The Range value given is out of bounds, e.g., beyond the end of the presentation.

给定的范围值超出范围,例如,超出演示文稿的结尾。

17.4.22. 458 Parameter Is Read-Only
17.4.22. 458参数是只读的

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_参数设置的参数可以读取,但不能修改。返回此错误消息时,发件人应返回包含有问题参数的消息正文。

17.4.23. 459 Aggregate Operation Not Allowed
17.4.23. 459不允许聚合操作

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。

17.4.24. 460 Only Aggregate Operation Allowed
17.4.24. 460仅允许聚合操作

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。

17.4.25. 461 Unsupported Transport
17.4.25. 461无支撑运输

The Transport field did not contain a supported transport specification.

传输字段不包含受支持的传输规范。

17.4.26. 462 Destination Unreachable
17.4.26. 462无法到达目的地

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参数的结果。

17.4.27. 463 Destination Prohibited
17.4.27. 463禁止前往目的地

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参数将媒体流量重定向到另一个目标而导致的。

17.4.28. 464 Data Transport Not Ready Yet
17.4.28. 464数据传输尚未就绪

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连接成功建立之前(违反本规范),向服务器发送播放请求。服务器将使用此错误代码指示由于无法完成连接建立而无法执行请求的操作。

17.4.29. 465 Notification Reason Unknown
17.4.29. 465通知原因未知

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节)客户不知道。

17.4.30. 466 Key Management Error
17.4.30. 466密钥管理错误

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]可能会导致此错误。

17.4.31. 470 Connection Authorization Required
17.4.31. 470需要连接授权

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标头中。

17.4.32. 471 Connection Credentials Not Accepted
17.4.32. 471未接受连接凭据

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.

在通过多个连接执行安全连接时,由于所用策略的凭据不可接受,中介已拒绝连接到下一个跃点并执行请求。

17.4.33. 472 Failure to Establish Secure Connection
17.4.33. 472未能建立安全连接

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握手时的致命故障造成的,例如,由于代理不接受任何密码套件。

17.5. Server Error 5xx
17.5. 服务器错误5xx

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”开头的响应状态代码表示服务器意识到出错或无法执行请求的情况。服务器应该包含一个消息体,其中包含对错误情况的解释,以及错误是暂时的还是永久的。用户代理应向用户显示任何包含的消息正文。这些响应代码适用于任何请求方法。

17.5.1. 500 Internal Server Error
17.5.1. 500内部服务器错误

The agent encountered an unexpected condition that prevented it from fulfilling the request.

代理遇到意外情况,无法满足请求。

17.5.2. 501 Not Implemented
17.5.2. 501未实施

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.

代理不支持满足请求所需的功能。当代理无法识别请求方法并且无法为任何资源支持该方法时,这是适当的响应。

17.5.3. 502 Bad Gateway
17.5.3. 502坏网关

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.

代理在充当网关或代理时,从试图完成请求时访问的上游代理接收到无效响应。

17.5.4. 503 Service Unavailable
17.5.4. 503服务不可用

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服务器。

17.5.5. 504 Gateway Timeout
17.5.5. 504网关超时

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)收到及时响应。

17.5.6. 505 RTSP Version Not Supported
17.5.6. 不支持505 RTSP版本

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版本。代理表示它无法或不愿意使用与代理相同的主版本完成请求,除了此错误消息。响应应该包含一个消息体,描述为什么不支持该版本以及该代理支持哪些其他协议。

17.5.7. 551 Option Not Supported
17.5.7. 不支持551选项

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字段中给定的功能标记。必须返回不支持的标题,说明不支持的功能。

17.5.8. 553 Proxy Unavailable
17.5.8. 553代理服务器不可用

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会话,则该请求适用于此代理的所有此类请求。

18. Header Field Definitions
18. 标题域定义
       +---------------+----------------+--------+---------+------+
       | 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)概述

18.1. Accept
18.1. 接受

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(不可接受)响应。

18.2. Accept-Credentials
18.2. 接受凭据

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=
        
18.3. Accept-Encoding
18.3. 接受编码

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.

如果请求中不存在接受编码字段,服务器可能会假定客户端将接受任何内容编码。在这种情况下,如果“标识”是可用的内容编码之一,那么服务器应该使用“标识”内容编码,除非它有其他信息表明不同的内容编码对客户端有意义。

18.4. Accept-Language
18.4. 接受语言

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的所有语言都是可接受的。

18.5. Accept-Ranges
18.5. 接受范围

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节对语法进行了定义。

18.6. Allow
18.6. 允许

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

允许:设置、播放、设置参数、描述

18.7. Authentication-Info
18.7. 身份验证信息

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]。此标头只能用于与客户端到服务器请求相关的响应消息。

18.8. Authorization
18.8. 批准

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指令,则可以返回该指令以响应任何后续请求。

18.9. Bandwidth
18.9. 带宽

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

18.10. Blocksize
18.10. 块大小

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)。

18.11. Cache-Control
18.11. 缓存控制

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)响应的新消息体。

18.12. Connection
18.12. 联系

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”的使用应限于服务器无法恢复时的错误消息,因此认为有必要关闭连接。原因是客户端可以选择无限期地继续使用连接,只要它发送有效消息。

18.13. Connection-Credentials
18.13. 连接凭据

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:连接凭据头证书的格式示例

18.14. Content-Base
18.14. 内容库

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可以在该消息体中重新定义。

18.15. Content-Encoding
18.15. 内容编码

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.

如果对消息正文应用了多个编码,则必须按照应用的顺序列出内容编码,从左到右依次排列。关于编码参数的附加信息可由本规范未定义的其他标题字段提供。

18.16. Content-Language
18.16. 内容语言

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.

内容语言可以应用于任何媒体类型——它不限于文本文档。

18.17. Content-Length
18.17. 内容长度

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消息头部分之外的消息体的消息中。如果缺少,则假定默认值为零。任何大于或等于零的内容长度都是有效值。

18.18. Content-Location
18.18. 内容位置

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。

18.19. Content-Type
18.19. 内容类型

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的内容类型在实践中可能仅限于表示描述和参数值类型。

18.20. CSeq
18.20. CSeq

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.

客户机连接到代理,并使用该传输将请求发送到多个服务器,这会造成一种情况,即很可能接收到无序的响应。这是因为代理将建立从代理到服务器的单独传输,在服务器上转发客户端的请求。当来自不同服务器的响应到达时,它们将按照到达代理并可以处理的顺序转发到客户端,而不是按照客户端原始序列号的顺序。这是为了避免某些会话的请求被另一台服务器处理请求的速度缓慢所阻止。

18.21. Date
18.21. 日期

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.

此外,请注意,语法允许在日期末尾添加注释。

18.22. Expires
18.22. 到期

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服务器不应发送超过一年的过期日期。

18.23. From
18.23. 从…起

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.

未经用户批准,客户端不应发送“发件人”标题字段,因为这可能会与用户的隐私利益或其网站的安全策略相冲突。强烈建议用户能够在请求之前随时禁用、启用和修改此字段的值。

18.24. If-Match
18.24. 如果匹配

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.

如果会话已从一台服务器重定向到另一台服务器,此验证检查也非常有用。

18.25. If-Modified-Since
18.25. 如果修改自

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
        
18.26. If-None-Match
18.26. 如果没有匹配

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标头字段的请求的结果未指定,必须视为非法请求。

18.27. Last-Modified
18.27. 最后修改

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服务器应发送上次修改。

18.28. Location
18.28. 地方

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节。

18.29. Media-Properties
18.29. 媒体属性

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
        
18.30. Media-Range
18.30. 媒体范围

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的发展,媒体范围也将不断扩大。但是,应假设媒体时间与挂钟时间直接相关(时钟偏移除外),以便可以计算出媒体范围的合理准确估计。

18.31. MTag
18.31. MTag

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使用标题进行设置和描述请求。

18.32. Notify-Reason
18.32. 通知原因

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节)。

18.33. Pipelined-Requests
18.33. 流水线请求

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代理可能需要将管道化请求标识符值从传入请求转换为传出请求,以便将请求聚合到持久连接上。

18.34. Proxy-Authenticate
18.34. 代理认证

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访问身份验证过程。此标头只能用于与客户端到服务器请求相关的响应消息。

18.35. Proxy-Authentication-Info
18.35. 代理身份验证信息

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中。此标头只能用于与客户端到服务器请求相关的响应消息。此标头具有逐跳范围。

18.36. Proxy-Authorization
18.36. 代理授权

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访问身份验证过程。与授权不同,代理授权标头字段仅适用于下一跳代理。此标头只能用于客户端到服务器的请求。

18.37. Proxy-Require
18.37. 代理要求

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

18.38. Proxy-Supported
18.38. 代理支持

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
        
18.39. Public
18.39. 平民的

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.

介入代理可确保请求发送方获得准确响应,指示可通过代理链在目标代理上使用的方法。

18.40. Range
18.40. 范围

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.

刻度表头中没有相应负值的递减范围间隔无效。

18.41. Referrer
18.41. 推荐人

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请求中包含引用者标头字段。

18.42. Request-Status
18.42. 请求状态

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参数的相应重新映射。

18.43. Require
18.43. 要求

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节)中讨论何时考虑功能需要代理支持的讨论。

18.44. Retry-After
18.44. 稍后重试

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分钟。

18.45. RTP-Info
18.45. RTP信息

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
        
18.46. Scale
18.46. 规模

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
        
18.47. Seek-Style
18.47. 寻找风格

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,否则使用预测方法的许多媒体编解码器的媒体质量可能会严重降低,除非额外的数据可用,例如,已经缓冲或通过其他侧信道。

18.48. Server
18.48. 服务器

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节)。如果响应由代理生成,则代理应用程序必须返回服务器先前返回的服务器响应头。

18.49. Session
18.49. 一场

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秒的值还允许在客户端出现故障时合理快速地恢复已提交的服务器资源。

18.50. Speed
18.50. 速度

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以外的方式),因此可能需要重新协商。要执行速度操作,服务器需要确保网络路径能够支持生成的比特率。因此,媒体传输需要支持反馈,以便服务器能够响应并适应可用比特率。

18.51. Supported
18.51. 支持

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
        
18.52. Terminate-Reason
18.52. 终止原因

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文本字符串,包含从服务器发送给用户的消息。应向用户显示此消息。

18.53. Timestamp
18.53. 时间戳

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消息的可靠传输。时间戳通用报头是在协议将来扩展以使用不可靠传输时指定的。

18.54. Transport
18.54. 运输

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请求的客户端可以指定流