[要約] RFC 7826は、Real-Time Streaming Protocol（RTSP）のバージョン2.0に関する仕様です。このRFCの目的は、RTSPの機能と動作を改善し、リアルタイムストリーミングの効率と信頼性を向上させることです。
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
M.ウェスターランドエリクソンM.スティーマーリング、エド。応用科学大学ダルムシュタット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.
この覚書は、RFC 2326で定義されているRTSPバージョン1.0を廃止するReal-Time Streaming Protocol（RTSP）バージョン2.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（RFC 3550）に基づく配信メカニズムを選択する手段を提供します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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（Internet Engineering Task Force）の製品です。これは、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.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
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）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
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
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
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
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
C.1.6. RTCP Usage with RTSP .................................278
C.2. RTP over TCP .............................................279
C.2.1. Interleaved RTP over TCP .............................280
C.2.2. RTP over Independent TCP .............................280
C.3. Handling Media-Clock Time Jumps in the RTP Media Layer ...284
C.4. Handling RTP Timestamps after PAUSE ......................287
C.5. RTSP/RTP Integration ....................................290
C.6. Scaling with RTP .........................................290
C.7. Maintaining NPT Synchronization with RTP Timestamps ......290
C.8. Continuous Audio .........................................290
C.9. Multiple Sources in an RTP Session .......................290
C.10. Usage of SSRCs and the RTCP BYE Message during an RTSP
Session .................................................290
C.11. Future Additions ........................................291
Appendix D. Use of SDP for RTSP Session Descriptions .............292
D.1. Definitions .............................................292
D.1.1. Control URI ..........................................292
D.1.2. Media Streams ........................................294
D.1.3. Payload Type(s) ......................................294
D.1.4. Format-Specific Parameters ...........................294
D.1.5. Directionality of Media Stream .......................295
D.1.6. Range of Presentation ................................295
D.1.7. Time of Availability .................................296
D.1.8. Connection Information ...............................297
D.1.9. Message Body Tag .....................................297
D.2. Aggregate Control Not Available ..........................298
D.3. Aggregate Control Available ..............................298
D.4. Grouping of Media Lines in SDP ...........................299
D.5. RTSP External SDP Delivery ...............................300
Appendix E. RTSP Use Cases .......................................300
E.1. On-Demand Playback of Stored Content .....................300
E.2. Unicast Distribution of Live Content .....................302
E.3. On-Demand Playback Using Multicast .......................303
E.4. Inviting an RTSP Server into a Conference ................303
E.5. Live Content Using Multicast .............................304
Appendix F. Text Format for Parameters ...........................305
Appendix G. Requirements for Unreliable Transport of RTSP ........305
Appendix H. Backwards-Compatibility Considerations ...............306
H.1. Play Request in Play State ...............................307
H.2. Using Persistent Connections .............................307
Appendix I. Changes ..............................................307
I.1. Brief Overview ...........................................308
I.2. Detailed List of Changes .................................309
Acknowledgements .................................................316
Contributors ....................................................317
Authors' Addresses ...............................................318
This memo defines version 2.0 of the Real-Time Streaming Protocol (RTSP 2.0). RTSP 2.0 is an application-layer protocol for the setup and control over the delivery of data with real-time properties, typically streaming media. Streaming media is, for instance, video on demand or audio live streaming. Put simply, RTSP acts as a "network remote control" for multimedia servers.
このメモは、Real-Time Streaming Protocol（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に基づいていますが、基本的なバージョンネゴシエーションメカニズム以外には下位互換性がありません。 2つのドキュメント間の変更点は、付録Iにリストされています。RTSP2.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 Play状態で受信したときのPLAYメソッドの動作の変更。
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 1.0の不整合に対処する必要がないように、RTSP 2.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で定義されており、「text / parameters」ファイル形式の付録Fは3つの標準仕様の付録です。その他の付録には、変更点、使用例、さまざまな考慮事項や動機について説明する情報部分がいくつか含まれています。
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には、セッションの確立、メディア配信制御、および以下で説明する拡張性モデルの3つの基本的な部分があります。このプロトコルは、クライアント制御のリアルタイムメディア配信の完全なソリューションを提供するために、既存の機能に関するいくつかの前提に基づいています。
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ヘッダーがあります。これらの行は、2つの連続する復帰改行（CRLF）文字ペアで終了します。メッセージ本文が存在する場合は、2つのCRLF文字ペアの後に続き、本文の長さはメッセージヘッダーによって記述されます。 RTSP応答も似ていますが、プロトコルとバージョンを含む応答行で始まり、その後にステータスコードと理由句が続きます。 RTSPメッセージは、クライアントとサーバー間で信頼できるトランスポートプロトコルを介して送信されます。 RTSP 2.0では、クライアントとサーバーがRTSPメッセージの必須トランスポートとしてTCPとTLS over TCPを実装する必要があります。
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は、この説明が完全に帯域外で配信されるか、DESCRIBEメソッドを使用したクライアントの要求への応答のデータオブジェクトとして配信されると想定しています（セクション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」および「rtsps」）を使用して、共通の制御下でメディアリソースとアグリゲートを参照します（セクション4.2を参照）。
This specification describes in Appendix D how one uses SDP [RFC4566] for describing the presentation.
この仕様は、付録Dで、プレゼンテーションの説明にSDP [RFC4566]をどのように使用するかを説明しています。
The RTSP client can request the establishment of an RTSP session after having used the presentation description to determine which media streams are available, which media delivery protocol is used, and the resource identifiers of the media streams. The RTSP session is a common context between the client and the server that consists of one or more media resources that are to be under common media delivery control.
RTSPクライアントは、プレゼンテーションの説明を使用して、使用可能なメディアストリーム、使用されているメディア配信プロトコル、およびメディアストリームのリソース識別子を確認した後、RTSPセッションの確立を要求できます。 RTSPセッションは、クライアントとサーバー間の共通のコンテキストであり、共通のメディア配信制御下にある1つ以上のメディアリソースで構成されます。
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
クライアントは、SETUPメソッド（セクション13.3）を使用してサーバーにリクエストを送信することにより、RTSPセッションを作成します。 SETUPリクエストのトランスポートヘッダー（セクション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.
SETUP要求を受信すると、サーバーはメディアリソースが使用可能かどうか、および1つ以上のトランスポートパラメーター指定が受け入れ可能かどうかを判断します。これが成功すると、RTSPセッションコンテキストが作成され、関連するパラメータと状態が保存されます。 IDはRTSPセッション用に作成され、セッションヘッダーの応答に含まれます（セクション18.49）。 SETUP応答には、選択された選択肢と関連するパラメーターを指定するトランスポートヘッダーが含まれています。
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セッションを参照するが、新しいメディアリソースを識別するSETUP要求は、集約されたセッションに既に存在するメディアリソースと共通の制御下にあるそのメディアリソースを追加する要求です。クライアントは、マルチメディアコンテンツコンテナ内の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はパイプライン化されたリクエストをサポートしています。つまり、クライアントは、最初に要求の完了を待たずに、複数の要求を連続して送信できます。クライアントは、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.
SETUP応答は、いくつかの異なるヘッダーで確立されたセッションに関する追加情報も提供します。 Media-Propertiesヘッダー（セクション18.29）には、メディア配信制御を実行してユーザーインターフェイスを構成するときに役立つ集合体に適用される多くのプロパティが含まれています。 Accept-Rangesヘッダー（セクション18.5）は、サーバーがこれらのメディアリソースに対してサポートする範囲形式についてクライアントに通知します。 Media-Rangeヘッダー（セクション18.30）は、現在利用可能なメディアの時間範囲についてクライアントに通知します。
After having established an RTSP session, the client can start controlling the media delivery. The basic operations are "begin playback", using the PLAY method (Section 13.4) and "suspend (pause) playback" by using the PAUSE method (Section 13.6). PLAY also allows for choosing the starting media position from which the server should deliver the media. The positioning is done by using the Range header (Section 18.40) that supports several different time formats: Normal Play Time (NPT) (Section 4.4.2), Society of Motion Picture and Television Engineers (SMPTE) Timestamps (Section 4.4.1), and absolute time (Section 4.4.3). The Range header also allows the client to specify a position where delivery should end, thus allowing a specific interval to be delivered.
RTSPセッションを確立した後、クライアントはメディア配信の制御を開始できます。基本的な操作は、PLAYメソッドを使用した「再生の開始」（セクション13.4）およびPAUSEメソッドを使用した「一時停止（一時停止）再生」（セクション13.6）です。 PLAYでは、サーバーがメディアを配信する開始メディアの位置を選択することもできます。位置決めは、いくつかの異なる時間形式をサポートするRangeヘッダー（セクション18.40）を使用して行われます：通常再生時間（NPT）（セクション4.4.2）、Society of Motion Picture and Television Engineers（SMPTE）タイムスタンプ（セクション4.4.1） 、絶対時間（セクション4.4.3）。 Rangeヘッダーを使用すると、クライアントは配信を終了する位置を指定できるため、特定の間隔で配信できます。
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セッションに適用可能なプロパティは、Media-Propertiesヘッダーを使用したSETUP応答でサーバーによって提供されます（セクション18.29）。これらは、1つまたは複数の独立した属性を使用して表現されます。最初の属性はRandom-Accessです。これは、配置が可能かどうか、およびどのような粒度で可能かを示します。別の側面は、セッションの存続期間中にコンテンツが変更されるかどうかです。オンデマンドコンテンツは最初から完全に提供されますが、記録されているライブストリームにより、セッションが進むにつれてアクセス可能なコンテンツの長さが長くなります。 RTSP以外のプロトコルによって動的に構築されるコンテンツも存在するため、セッション中のステップも変化しますが、継続的ではない可能性があります。さらに、コンテンツが記録されると、完全なコンテンツが保持されず、たとえば最後の1時間だけが保持される場合があります。これらすべての特性により、以下で説明するメカニズムが必要になります。
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.
クライアントがランダムアクセスを許可するオンデマンドコンテンツにアクセスすると、クライアントはコンテンツの最初と最後の間の任意のポイントに対してPLAY要求を発行できます。サーバーは、要求されたポイントの前の最も近いランダムアクセスポイントからメディアを配信し、そのPLAY応答でそのことを示します。クライアントがPAUSEを発行すると、配信は停止され、サーバーが停止した時点が応答で報告されます。クライアントは、後でRangeヘッダーなしでPLAY要求を送信することで再開できます。サーバーがコンテンツの終わりまたは要求された範囲を配信することによってPLAY要求を完了しようとすると、サーバーはこれを示すPLAY_NOTIFY要求（セクション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.
録音などの追加機能なしでライブコンテンツを再生する場合、クライアントはPLAYリクエストを送信した後、サーバーからライブメディアを受信します。サーバーはコンテンツを保存せず、セッションのソースから転送するだけなので、そのようなコンテンツを探すことはできません。したがって、配信は、クライアントがPAUSE要求を送信するか、セッションを破棄するか、コンテンツが終了するまで続きます。
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.
記録されているライブセッションの場合、クライアントは、記録の進行状況を追跡する必要があります。セッションが確立すると、クライアントはMedia-Rangeヘッダーから現在の録音時間を学習します。録音が継続しているため、コンテンツは経過時間に直接関係して増加します。したがって、PLAY要求に対する各サーバーの応答には、現在のMedia-Rangeヘッダーが含まれます。また、サーバーは定期的に（約5分ごとに）現在のメディア範囲をPLAY_NOTIFYリクエストで送信する必要があります（セクション13.5.2）。ライブ送信が終了した場合、サーバーは更新されたMedia-Propertiesを含むPLAY_NOTIFYリクエストを送信して、コンテンツが記録されたライブセッションでなくなり、代わりにオンデマンドコンテンツになったことを示す必要があります。リクエストには、最終的なメディア範囲も含まれます。ライブ配信が継続している間、クライアントはNPTタイムスケールシンボル「今」を使用して現在のライブポイントの再生を要求できます。または、そのポイントの明示的な範囲要求により、利用可能なコンテンツの特定のポイントを要求できます。要求されたポイントが使用可能な間隔の外にある場合、サーバーは位置を最も近い使用可能なポイントに、つまり最初または最後に調整します。
A special case of recording is that where the recording is not retained longer than a specific time period; thus, as the live delivery continues, the client can access any media within a moving window that covers, for example, "now" to "now" minus 1 hour. A client that pauses on a specific point within the content may not be able to retrieve the content anymore. If the client waits too long before resuming the pause point, the content may no longer be available. In this case, the pause point will be adjusted to the closest point in the available media.
記録の特殊なケースは、記録が特定の期間より長く保持されない場合です。したがって、ライブ配信が続くと、クライアントは、たとえば「現在」から「現在」マイナス1時間をカバーする移動ウィンドウ内の任意のメディアにアクセスできます。コンテンツ内の特定のポイントで一時停止したクライアントは、コンテンツを取得できなくなる可能性があります。クライアントが一時停止ポイントを再開するまでの待機時間が長すぎると、コンテンツが利用できなくなる可能性があります。この場合、一時停止ポイントは、使用可能なメディアの最も近いポイントに調整されます。
A session may have additional state or functionality that affects how the server or client treats the session or content, how it functions, or feedback on how well the session works. Such extensions are not defined in this specification, but they may be covered in various extensions. RTSP has two methods for retrieving and setting parameter values on either the client or the server: GET_PARAMETER (Section 13.8) and SET_PARAMETER (Section 13.9). These methods carry the parameters in a message body of the appropriate format. One can also use headers to query state with the GET_PARAMETER method. As an 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).
セッションには、サーバーまたはクライアントがセッションまたはコンテンツを処理する方法、それがどのように機能するか、またはセッションの動作に関するフィードバックに影響する追加の状態または機能がある場合があります。このような拡張はこの仕様では定義されていませんが、さまざまな拡張でカバーされている場合があります。 RTSPには、クライアントまたはサーバーのいずれかでパラメーター値を取得および設定するための2つの方法があります。GET_PARAMETER（セクション13.8）およびSET_PARAMETER（セクション13.9）です。これらのメソッドは、適切な形式のメッセージ本文でパラメーターを伝送します。ヘッダーを使用して、GET_PARAMETERメソッドで状態を照会することもできます。例として、時間進行セッションの現在のメディア範囲を知る必要があるクライアントは、GET_PARAMETERメソッドを使用して、メディア範囲を含めることができます。さらに、RTP-Info（セクション18.45）とRange（セクション18.40）の組み合わせを使用して、同期情報を要求できます。
RTSP 2.0 does not have a strong mechanism for negotiating the headers or parameters and their formats. However, responses will indicate request-headers or parameters that are not supported. A priori determination of what features are available needs to be done through out-of-band mechanisms, like the session description, or through the usage of feature tags (Section 4.5).
RTSP 2.0には、ヘッダーまたはパラメーターとその形式をネゴシエートする強力なメカニズムがありません。ただし、応答には、サポートされていない要求ヘッダーまたはパラメーターが示されます。利用可能な機能の事前の決定は、セッションの説明などのアウトオブバンドメカニズムを通じて、または機能タグの使用を通じて行う必要があります（セクション4.5）。
This document specifies how media is delivered with RTP [RFC3550] over UDP [RFC768], TCP [RFC793], or the RTSP connection. Additional protocols may be specified in the future as needed.
このドキュメントでは、UDP [RFC768]、TCP [RFC793]、またはRTSP接続を介してRTP [RFC3550]でメディアを配信する方法を指定します。追加のプロトコルは、必要に応じて将来指定される可能性があります。
The usage of RTP as a media delivery protocol requires some additional information to function well. The PLAY response contains information to enable reliable and timely delivery of how a client should synchronize different sources in the different RTP sessions. It also provides a mapping between RTP timestamps and the content-time scale. When the server wants to notify the client about the completion of the media delivery, it sends a PLAY_NOTIFY request to the client. The PLAY_NOTIFY request includes information about the stream end, including the last RTP sequence number for each stream, thus enabling the client to empty the buffer smoothly.
メディア配信プロトコルとしてRTPを使用するには、適切に機能するためにいくつかの追加情報が必要です。 PLAY応答には、クライアントがさまざまなRTPセッションでさまざまなソースを同期する方法を確実かつタイムリーに配信できるようにするための情報が含まれています。また、RTPタイムスタンプとコンテンツ時間スケール間のマッピングも提供します。サーバーがメディア配信の完了についてクライアントに通知する場合、サーバーはクライアントにPLAY_NOTIFY要求を送信します。 PLAY_NOTIFYリクエストには、各ストリームの最後のRTPシーケンス番号など、ストリームの終了に関する情報が含まれているため、クライアントはバッファをスムーズに空にすることができます。
The basic playback functionality of RTSP enables delivery of a range of requested content to the client at the pace intended by the content's creator. However, RTSP can also manipulate the delivery to the client in two ways.
RTSPの基本的な再生機能により、要求されたさまざまなコンテンツを、コンテンツの作成者が意図したペースでクライアントに配信できます。ただし、RTSPはクライアントへの配信を2つの方法で操作することもできます。
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.
どちらも、時間単位あたりのメディア配信に影響します。ただし、2つの独立したタイムスケールを操作し、効果を組み合わせることができます。
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の場合、再生の1秒ごとに2秒のコンテンツが再生されます。スケール= 1.0は、スケールが指定されていない場合、つまりコンテンツの元のレートで再生される場合に使用されるデフォルト値です。 0と1.0の間のスケール値はスローモーションを提供します。スケールを負にすると、通常のペース（スケール= -1.0）、逆方向の高速再生（スケール<-1.0）、または逆方向のスローモーション（-1.0 <スケール<0）の逆再生が可能になります。スケール= 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.
ほとんどの場合、スケールの実現とは、サーバー側でメディアを操作して、クライアントが実際にメディアを再生できるようにすることを意味します。これらのメディア操作の性質とそれらが必要な場合は、メディアタイプに大きく依存します。 2つの一般的なメディアタイプ、オーディオとビデオについて考えてみましょう。
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 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.
速度（セクション18.50）は、特定のウォールクロック期間に再生タイムラインが配信される量に影響します。デフォルトはSpeed = 1で、メディアが消費されるのと同じ速度で配信することを意味します。速度> 1は、受信者がコンテンツを定期的に消費するよりも速くコンテンツを取得することを意味します。速度<1は、配信が通常のメディアレートよりも遅いことを意味します。 0以下の速度値は意味がなく、許可されません。このメカニズムにより、2つの一般的な機能が可能になります。 1つはクライアント側のスケール操作です。つまり、クライアントはすべてのフレームを受信し、ローカルで再生を調整します。 2つ目は、メディアのバッファリングの配信制御です。 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.
Speedの素朴な実装は、メディアの送信スケジュールにのみ影響し、必要な帯域幅に明らかな影響を与えます。これにより、データレートは速度係数に比例します。速度= 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セマンティクスに関連して特に問題になります。目標がバッファを一杯にすることである場合、クライアントは品質の低下を犠牲にしてそれを実行したくない場合があります。クライアントがローカルのプレイアウトを変更したい場合、実際には、要求された速度を尊重する必要があります。この問題を解決するために、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から2.5などの公称メディアレート1.0の下限の範囲を使用するのが適切です。クライアントがバッファーを削減したい場合は、1.0未満の上限を指定して、サーバーに通常のメディアレートよりも遅い配信を強制することができます。
The session context that has been established is kept alive by having the client show liveness. This is done in two main ways:
確立されたセッションコンテキストは、クライアントに活性を示すことで維持されます。これは主に2つの方法で行われます。
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.
通常、セッションコンテキストは、集約された制御URIを参照するサーバーにTEARDOWN要求（セクション13.7）を送信するクライアントによって終了されます。個々のメディアリソースは、その特定のメディアリソースを参照するTEARDOWN要求によってセッションコンテキストから削除できます。すべてのメディアリソースがセッションコンテキストから削除されると、セッションコンテキストは終了します。
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.
サーバーで許可されている場合、クライアントはセッションを無期限に維持できます。ただし、クライアントは、メディア配信アクティビティのない長期間が経過したときにセッションコンテキストを解放することをお勧めします。クライアントは、後で必要に応じてセッションコンテキストを再確立できます。長時間を構成するものは、クライアント、サーバー、およびそれらの使用法に依存します。セッションタイムアウト値の10倍が経過する前に、クライアントがセッションを終了することをお勧めします。サーバーは、キープアライブを超えるクライアントアクティビティなしで、1つのセッションタイムアウト期間後にセッションを終了する場合があります。サーバーがセッションコンテキストを終了するときは、理由を示すTEARDOWN要求を送信して終了します。
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.
サーバーは、メンテナンスに必要な場合があるため、クライアントにセッションを破棄し、代替サーバーでセッションを再確立するように要求することもできます。これはREDIRECTメソッド（セクション13.10）を使用して行われます。 Terminate-Reasonヘッダー（セクション18.52）は、いつ、なぜかを示すために使用されます。 Locationヘッダーは、使用可能な代替サーバーがある場合に接続する場所を示します。期限が切れると、サーバーは単にサービスの提供を停止します。クリーンなクロージャを実現するには、クライアントは期限前にセッションの終了を開始する必要があります。サーバーにリダイレクトする他のサーバーがなく、メンテナンスのためにセッションを閉じたい場合は、Terminate-Reasonヘッダーを指定したTEARDOWNメソッドを使用します。
RTSP is quite a versatile protocol that supports extensions in many different directions. Even this core specification contains several blocks of functionality that are optional to implement. The use case and need for the protocol deployment should determine what parts are implemented. Allowing for extensions makes it possible for RTSP to address additional use cases. However, extensions will affect the interoperability of the protocol; therefore, it is important that they can be added in a structured way.
RTSPは、さまざまな方向の拡張をサポートする非常に用途の広いプロトコルです。このコア仕様でさえ、実装のオプションである機能のいくつかのブロックが含まれています。使用例とプロトコルの展開の必要性により、実装するパーツを決定する必要があります。拡張を許可すると、RTSPが追加のユースケースに対処できるようになります。ただし、拡張機能はプロトコルの相互運用性に影響します。したがって、構造化された方法で追加できることが重要です。
The client can learn the capability of a server by using the OPTIONS method (Section 13.1) and the Supported header (Section 18.51). It can also try and possibly fail using new methods or require that particular features be supported using the Require (Section 18.43) or Proxy-Require (Section 18.37) header.
クライアントは、OPTIONSメソッド（セクション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は、それ自体、3つの方法で拡張できます。ここでは、サポートされている変更の規模が大きい順にリストします。
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 プロトコルの新しいバージョンを定義して、ほとんどすべての側面（プロトコルのバージョン番号の位置を除く）を変更できます。プロトコルの新しいバージョンは、Standards Trackドキュメントを通じて登録する必要があります。
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_PARAMETERおよびGET_PARAMETERを使用したパラメーター形式で実行できます。
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].
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「[RFC2119]」で説明されているように解釈されます。
The word, "unspecified" is used to indicate functionality or features that are not defined in this specification. Such functionality cannot be used in a standardized manner without further definition in an extension specification to RTSP.
「未指定」という言葉は、この仕様で定義されていない機能を示すために使用されます。このような機能は、RTSPの拡張仕様でさらに定義しない限り、標準化された方法では使用できません。
Aggregate control: The concept of controlling multiple streams using a single timeline, generally one maintained by the server. A client, for example, uses aggregate control when it issues a single play or pause message to simultaneously control both the audio and video in a movie. A session that is under aggregate control is referred to as an "aggregated session".
集約制御：単一のタイムラインを使用して複数のストリームを制御する概念。通常はサーバーによって維持されます。たとえば、クライアントは、1つの再生メッセージまたは一時停止メッセージを発行して、映画のオーディオとビデオの両方を同時に制御するときに、集約制御を使用します。集約されたセッションは、「集約されたセッション」と呼ばれます。
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.
接続：通信を目的として2つのプログラム間に確立されたトランスポート層仮想回線。
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に似ていますが、US-ASCIIのみではなく、ユニバーサルキャラクタセット全体（Unicode / ISO 10646）の文字を許可します。詳細については、[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.
ライブ：ライブプレゼンテーションまたはセッションは、メディア配信と同時に行われるイベントからメディアを発生させます。ライブセッションは、多くの場合、バインドされていないか、大まかに定義された期間であり、シーク操作ができない場合があります。
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.
メディアサーバー：1つ以上のメディアストリームにメディア配信サービスを提供するサーバー。プレゼンテーション内の異なるメディアストリームは、異なるメディアサーバーから発生する場合があります。メディアサーバーは、プレゼンテーションが呼び出されるのと同じホスト上または異なるホスト上に存在する場合があります。
(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.
プレゼンテーション：完全なメディアフィードとしてクライアントに提示され、以下で定義されるプレゼンテーションの説明によって記述される1つ以上のストリームのセット。複数のメディアストリームを含むプレゼンテーションは、多くの場合、集約された制御下で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.
プレゼンテーションの説明：プレゼンテーションの説明には、一連のエンコーディング、ネットワークアドレス、コンテンツに関する情報など、プレゼンテーション内の1つ以上のメディアストリームに関する情報が含まれます。 SDP（[RFC4566]）などの他のIETFプロトコルでは、プレゼンテーションに「セッション」という用語を使用します。プレゼンテーションの説明には、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メッセージの1つのタイプ。 HTTP応答の場合は、明示的に示されます。
Request: An RTSP request. One type of RTSP message. If an HTTP request is meant, it is indicated explicitly.
リクエスト：RTSPリクエスト。 RTSPメッセージの1つのタイプ。 HTTPリクエストが意図されている場合は、明示的に示されます。
Request-URI: The URI used in a request to indicate the resource on which the request is to be performed.
Request-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プロキシ。この仕様には、要求を送信したり、応答を受信したりする機能など、これら3つのエンティティに共通する多くの機能があります。この用語は、これら3つのエンティティすべてに適用される機能を説明するときに使用されます。
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セッションは一般的なコンテキストです。クライアントの要求に応じて作成および維持され、クライアントまたはサーバーのいずれかによって破棄できます。これは、セットアップ要求が正常に完了すると（200 OK応答が送信されたときに）RTSPサーバーによって確立され、その時点でセッションIDのラベルが付けられます。セッションは、サーバーによってタイムアウトになるか、TEARDOWN要求によって明示的に削除されるまで存在します。 RTSPセッションはステートフルエンティティです。 RTSPサーバーは、明示的なセッションステートマシン（付録Bを参照）を維持します。ここでは、ほとんどの状態遷移がクライアント要求によってトリガーされます。セッションの存在は、セッションのメディアストリームとそれぞれのトランスポートメカニズムに関する状態の存在を意味します。特定のセッションには、1つ以上のメディアストリームを関連付けることができます。 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：Universal Resource Locatorは、リソースを名前やその他の属性で識別するのではなく、プライマリアクセスメカニズムを通じてリソースを識別するURIです。
This specification defines version 2.0 of RTSP.
この仕様は、RTSPのバージョン2.0を定義しています。
RTSP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further RTSP communication rather than the features obtained via that communication. No change is made to the version number for the addition of message components that do not affect communication behavior or that only add to extensible field values.
RTSPは "<major>。<minor>"番号付けスキームを使用して、プロトコルのバージョンを示します。プロトコルのバージョン管理ポリシーは、送信者がメッセージの形式と、その通信を介して取得される機能ではなく、RTSP通信をさらに理解するためのその能力を示すことを目的としています。通信動作に影響を与えない、または拡張可能なフィールド値のみを追加するメッセージコンポーネントを追加しても、バージョン番号は変更されません。
The <minor> number is incremented when the changes made to the protocol add features that do not change the general message parsing algorithm but that may add to the message semantics and imply additional capabilities of the sender. The <major> number is incremented when the format of a message within the protocol is changed. The version of an RTSP message is indicated by an RTSP-Version field in the first line of the message. Note that the major and minor numbers MUST be treated as separate integers and that each MAY be incremented higher than a single digit. Thus, RTSP/2.4 is a lower version than RTSP/2.13, which, in turn, is lower than RTSP/12.3. Leading zeros SHALL NOT be sent and MUST be ignored by recipients.
<マイナー>番号は、プロトコルに加えられた変更により、一般的なメッセージ解析アルゴリズムを変更しない機能が追加されますが、メッセージのセマンティクスが追加され、送信者の追加機能が含まれる場合があります。 <major>番号は、プロトコル内のメッセージのフォーマットが変更されると増加します。 RTSPメッセージのバージョンは、メッセージの最初の行のRTSP-Versionフィールドで示されます。メジャー番号とマイナー番号は別々の整数として扱われる必要があり、それぞれが1桁より大きくなる場合があることに注意してください。したがって、RTSP / 2.4はRTSP / 2.13よりも低いバージョンであり、RTSP / 2.13はRTSP / 12.3よりも低いバージョンです。先頭のゼロは送信しないでください（SHALL NOT）、受信者は無視する必要があります。
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は、3つのURIスキーム「rtsp」、「rtsps」、および「rtspu」を定義および登録または更新します。最後の「rtspu」の使用法はRTSP 2.0では規定されておらず、RTSP 1.0で定義されたURIスキームを登録するためにここで定義されています。 「rtspu」スキームは、信頼できないトランスポート手段（RTSP 1.0のUDP）を介したRTSPメッセージの不特定のトランスポートを示します。 RTSPサーバーは、「rtspu」スキームが実装されていないことを示すエラーコード（501）で、「rtspu」URIスキームを運ぶリクエストに応答する必要があります。
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バージョンの不一致がある場合にのみ、障害は後のステップで発生します。 Request-URIは絶対URIでなければならないため、2番目の変更はRTSPメッセージヘッダー内でのみ発生します。したがって、このような使用法は、エージェントが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.
この仕様は、Webページ、ユーザーインターフェイス、紙などのRTSPリソース識別子およびロケーターとして使用できるRTSP IRI [RFC3987]のフォーマットも定義します。ただし、RTSPリクエストメッセージフォーマットでは、絶対URIフォーマットしか使用できません。 [RFC3987]で定義されているように、RTSP IRIフォーマットはIRIからURIへの変換とルールを使用する必要があります。これにより、RTSP 2.0仕様に一致し、リクエストでの使用に適したURIをRTSP IRIから作成できます。
The RTSP IRI and URI are both syntax restricted compared to the generic syntax defined in [RFC3986] and [RFC3987]:
RTSP IRIとURIはどちらも、[RFC3986]と[RFC3987]で定義されている一般的な構文に比べて構文が制限されています。
o An absolute URI requires the authority part; i.e., a host identity MUST be provided.
o 絶対URIには権限部分が必要です。つまり、ホストIDを提供する必要があります。
o Parameters in the path element are prefixed with the reserved separator ";".
o パス要素のパラメータには、予約済みのセパレータ「;」が前に付きます。
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]とIRI [RFC3987]の「スキーム」と「ホスト」の部分では、大文字と小文字が区別されません。 RTSP URIとIRIの他の部分はすべて大文字と小文字が区別され、大文字と小文字をマッピングしてはなりません。
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から削除され、Request-URIには含まれません。ユーザーエージェントは、リクエストが関連するメディアタイプに基づいてフラグメントの値を解釈する必要があります。つまり、DESCRIBEリクエストへの応答のContent-Typeヘッダーに示されているメディアタイプ。
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を使用してパス要素を変更すると、クエリが削除されます。つまり、相対部分にクエリを含める必要があります。 。
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内）を介して発行される必要がありますが、スキーム「rtsps」では、セキュアなトランスポート（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は、ストリームまたはストリームの集約を参照する場合があります。つまり、プレゼンテーション。したがって、セクション13で説明する要求は、プレゼンテーション全体またはプレゼンテーション内の個々のストリームに適用できます。一部のリクエストメソッドは、プレゼンテーションではなくストリームにのみ適用でき、その逆も可能です。
For example, the RTSP URI:
たとえば、RTSP URI：
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.
は、プレゼンテーション「ツイスター」内のオーディオストリームを識別できます。これは、ホストmedia.example.comのポート554へのTCP接続を介して発行されたRTSPリクエストを介して制御できます。
Also, the RTSP URI:
また、RTSP URI：
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.
プレゼンテーション「ツイスター」を識別します。これは、オーディオストリームとビデオストリームで構成される場合がありますが、ランダムメディアリダイレクターなど、他の何かである場合もあります。
This does not imply a standard way to reference streams in URIs. The presentation description defines the hierarchical relationships in the presentation and the URIs for the individual streams. A presentation description may name a stream "a.mov" and the whole presentation "b.mov".
これは、URIでストリームを参照する標準的な方法を意味するものではありません。プレゼンテーションの説明は、プレゼンテーションの階層関係と個々のストリームのURIを定義します。プレゼンテーションの説明では、ストリームに「a.mov」、プレゼンテーション全体に「b.mov」という名前を付けることができます。
The path components of the RTSP URI are opaque to the client and do not imply any particular file system structure for the server.
RTSP URIのパスコンポーネントはクライアントに対して不透明であり、サーバーの特定のファイルシステム構造を意味するものではありません。
This decoupling also allows presentation descriptions to be used with non-RTSP media control protocols simply by replacing the scheme in the URI.
この分離により、URIのスキームを置き換えるだけで、プレゼンテーションの説明を非RTSPメディアコントロールプロトコルで使用できるようになります。
Session identifiers are strings of a length between 8-128 characters. A session identifier MUST be generated using methods that make it cryptographically random (see [RFC4086]). It is RECOMMENDED that a session identifier contain 128 bits of entropy, i.e., approximately 22 characters from a high-quality generator (see Section 21). However, note that the session identifier does not provide any security against session hijacking unless it is kept confidential by the client, server, and trusted proxies.
セッション識別子は、8〜128文字の長さの文字列です。セッション識別子は、それを暗号的にランダムにするメソッドを使用して生成する必要があります（[RFC4086]を参照）。セッション識別子には、128ビットのエントロピー、つまり、高品質ジェネレーターからの約22文字が含まれていることをお勧めします（セクション21を参照）。ただし、セッション識別子は、クライアント、サーバー、および信頼できるプロキシによって機密が保持されない限り、セッション乗っ取りに対するセキュリティを提供しないことに注意してください。
RTSP currently supports three different media-time formats defined below. Additional time formats may be specified in the future. These time formats can be used with the Range header (Section 18.40) to request playback and specify at which media position protocol requests actually will or have taken place. They are also used in description of the media's properties using the Media-Range header (Section 18.30). The unqualified format identifier is used on its own in Accept-Ranges header (Section 18.5) to declare supported time formats and also in the Range header (Section 18.40) to request the time format used in the response.
RTSPは現在、以下に定義する3つの異なるメディア時間形式をサポートしています。将来、追加の時刻形式が指定される可能性があります。これらの時間形式をRangeヘッダー（セクション18.40）と共に使用して、再生を要求し、どのメディア位置でプロトコル要求が実際に行われるか、または行われたかを指定できます。また、Media-Rangeヘッダーを使用したメディアのプロパティの説明でも使用されます（セクション18.30）。修飾されていない形式識別子は、サポートされる時間形式を宣言するAccept-Rangesヘッダー（セクション18.5）で単独で使用され、また、応答で使用される時間形式を要求するRangeヘッダー（セクション18.40）で使用されます。
A timestamp may use a format derived from a Society of Motion Picture and Television Engineers (SMPTE) specification and expresses time offsets anchored at the start of the media clip. Relative timestamps are expressed as SMPTE time codes [SMPTE-TC] for frame-level access accuracy. The time code has the format:
タイムスタンプは、Society of Motion Picture and Television Engineers（SMPTE）仕様から派生した形式を使用する場合があり、メディアクリップの先頭に固定された時間オフセットを表します。相対タイムスタンプは、フレームレベルのアクセス精度のためにSMPTEタイムコード[SMPTE-TC]として表されます。タイムコードの形式は次のとおりです。
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ドロップ」形式で、フレームレートは29.97フレーム/秒です。 「smpte-type」を使用することで、他のSMPTEコード（「SMPTE 25」など）をサポートできます（MAY）。 SMPTE 30の場合、時間値の「frames」フィールドは0〜29の値をとることができます。毎秒30と29.97フレームの違いは、毎分の最初の2つのフレームインデックス（値00と01）を削除することで処理されます。 10分ごと。フレームとサブフレームの値がゼロの場合、それらを省略できます。サブフレームは、100分の1フレームで測定されます。
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
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）は、プレゼンテーションの開始に対するストリームの絶対位置を示します。タイムスタンプは2つの部分で構成されます。必須の最初の部分は、秒のみまたは時間、分、秒のいずれかで表すことができます。オプションの2番目の部分は、小数点と10進数で構成され、秒の端数を示します。
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はDigital Storage Media Command and Control（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-
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]に基づいており、次の2つの異なる表記法を使用して、プレゼンテーションの開始からの経過時間を表します。
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時間形式の要件に従って、時間、分、秒はすべて存在しなければならず、2桁が分と秒に使用され、少なくとも2桁が時間に使用されます。 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表記は、1〜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で指定されている秒の小数部を許可し、最大9桁を使用し、「。」のみを許可します。 （フルストップ）小数点区切りとして。
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表記は、人間の読者が使用できるように最適化されています。 「今」の定数により、クライアントは、保存されたバージョンや時間遅延されたバージョンではなく、ライブフィードの受信を要求できます。この場合、絶対時間もゼロ時間も適切ではないため、これが必要です。
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 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.
絶対時間は、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）を使用する必要があります。つまり、タイムゾーンのオフセットは許可されません。完全な日付と時刻の指定は、8桁の日付の後に "T"とそれに続く6桁の時刻の値が続き、オプションで完全なストップとそれに続く1〜9秒の小数部が続き、 "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:
以下は、メディア時刻形式の3つの例です。最初に、1996年11月8日の開始時刻14時間37分、20 1/4秒UTCが10分5秒再生するクロック形式範囲要求の要求、その後Media-Propertiesヘッダーの2014年12月24日の15時間00分における「Time-Limited」UTCプロパティ、最後に2013年6月18日の16時間12分におけるTerminate-Reasonヘッダーの「time」プロパティ56秒：
clock=19961108T143720.25Z-19961108T144725.25Z Time-Limited=20141224T1500Z time=20130618T161256Z
clock = 19961108T143720.25Z-19961108T144725.25Z Time-Limited = 20141224T1500Z time = 20130618T161256Z
Feature tags are unique identifiers used to designate features in RTSP. These tags are used in Require (Section 18.43), Proxy-Require (Section 18.37), Proxy-Supported (Section 18.38), Supported (Section 18.51), and Unsupported (Section 18.55) header fields.
機能タグは、RTSPで機能を指定するために使用される一意の識別子です。これらのタグは、Require（セクション18.43）、Proxy-Require（セクション18.37）、Proxy-Supported（セクション18.38）、Supported（セクション18.51）、およびUnsupported（セクション18.55）ヘッダーフィールドで使用されます。
A feature tag definition MUST indicate which combination of clients, servers, or proxies to which it applies.
機能タグ定義は、それが適用されるクライアント、サーバー、またはプロキシのどの組み合わせを示す必要があります。
The creator of a new RTSP feature tag should either prefix the feature tag with a reverse domain name (e.g., "com.example.mynewfeature" is an apt name for a feature whose inventor can be reached at "example.com") or register the new feature tag with the Internet Assigned Numbers Authority (IANA). (See Section 22, "IANA Considerations".)
新しいRTSP機能タグの作成者は、機能タグの前に逆ドメイン名を付ける必要があります（たとえば、「com.example.mynewfeature」は、発明者が「example.com」にアクセスできる機能の適切な名前です）または登録する必要があります。 Internet Assigned Numbers Authority（IANA）の新しい機能タグ。 （セクション22「IANAの考慮事項」を参照してください。）
The usage of feature tags is further described in Section 11, which deals with capability handling.
機能タグの使用法については、機能の処理を扱うセクション11で詳しく説明します。
Message body tags are opaque strings that are used to compare two message bodies from the same resource, for example, in caches or to optimize setup after a redirect. Message body tags can be carried in the MTag header (see Section 18.31) or in SDP (see Appendix D.1.9). MTag is similar to ETag in HTTP/1.1 (see Section 3.11 of [RFC2068]).
メッセージ本文タグは、たとえばキャッシュ内の同じリソースからの2つのメッセージ本文を比較するため、またはリダイレクト後の設定を最適化するために使用される不透明な文字列です。メッセージ本文タグは、MTagヘッダー（セクション18.31を参照）またはSDP（付録D.1.9を参照）で伝送できます。 MTagはHTTP / 1.1のETagに似ています（[RFC2068]のセクション3.11を参照）。
A message body tag MUST be unique across all versions of all message bodies associated with a particular resource. A given message body tag value MAY be used for message bodies obtained by requests on different URIs. The use of the same message body tag value in conjunction with message bodies obtained by requests on different URIs does not imply the equivalence of those message bodies.
メッセージ本文タグは、特定のリソースに関連付けられたすべてのメッセージ本文のすべてのバージョンにわたって一意である必要があります。与えられたメッセージ本文タグ値は、異なるURIのリクエストによって取得されたメッセージ本文に使用される場合があります。異なるURIでのリクエストによって取得されたメッセージ本文と一緒に同じメッセージ本文タグ値を使用しても、それらのメッセージ本文が同等であるとは限りません。
Message body tags are used in RTSP to make some methods conditional. The methods are made conditional through the inclusion of headers; see Section 18.24 and Section 18.26 for information on the If-Match and If-None-Match headers, respectively. Note that RTSP message body tags apply to the complete presentation, i.e., both the presentation description and the individual media streams. Thus, message body tags can be used to verify at setup time after a redirect that the same session description applies to the media at the new location using the If-Match header.
メッセージ本文タグは、一部のメソッドを条件付きにするためにRTSPで使用されます。メソッドは、ヘッダーを含めることで条件付きになります。 If-MatchおよびIf-None-Matchヘッダーの詳細については、それぞれセクション18.24およびセクション18.26を参照してください。 RTSPメッセージ本文タグは、完全なプレゼンテーション、つまりプレゼンテーションの説明と個々のメディアストリームの両方に適用されることに注意してください。したがって、メッセージ本文タグは、リダイレクト後のセットアップ時に、同じセッションの説明がIf-Matchヘッダーを使用して新しい場所のメディアに適用されることを確認するために使用できます。
When an RTSP server handles media, it is important to consider the different properties a media instance for delivery and playback can have. This specification considers the media properties listed below in its protocol operations. They are derived from the differences between a number of supported usages.
RTSPサーバーがメディアを処理する場合、配信および再生用のメディアインスタンスが持つことができるさまざまなプロパティを考慮することが重要です。この仕様では、プロトコル操作で以下にリストされているメディアプロパティが考慮されます。それらは、サポートされている多くの使用法の違いから導き出されています。
On-demand: Media that has a fixed (given) duration that doesn't change during the lifetime of the RTSP session and is known at the time of the creation of the session. It is expected that the content of the media will not change, even if the representation, such as encoding, or quality, may change. Generally, one can seek, i.e., request any range, within the media.
オンデマンド：RTSPセッションの存続期間中に変更されず、セッションの作成時に認識される、固定（所定の）期間を持つメディア。エンコードや品質などの表現が変更されても、メディアのコンテンツは変更されないことが期待されます。一般に、メディア内で任意の範囲をシーク、つまり要求できます。
Dynamic On-demand: This is a variation of the on-demand case where external methods are used to manipulate the actual content of the media setup for the RTSP session. The main example is content defined by a playlist.
動的オンデマンド：これは、RTSPセッションのメディアセットアップの実際のコンテンツを操作するために外部メソッドが使用されるオンデマンドケースのバリエーションです。主な例は、プレイリストによって定義されたコンテンツです。
Live: Live media represents a progressing content stream (such as broadcast TV) where the duration may or may not be known. It is not seekable, only the content presently being delivered can be accessed.
ライブ：ライブメディアは、進行時間がわかっている場合とわからない場合がある進行中のコンテンツストリーム（放送TVなど）を表します。シークできず、現在配信中のコンテンツにのみアクセスできます。
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.
記録付きライブ：ライブセッションのコンテンツを保存および保持し、既に記録されたコンテンツの一部内でランダムアクセス配信を可能にするサーバー側の機能と組み合わされたライブストリーム。メディアストリームの実際の動作は、メディアストリームの保持ポリシーに大きく依存します。サーバーは完全なメディアストリームをキャプチャできるか、保持される量に制限があります。メディアの範囲は、セッションの進行に応じて動的に変化します。記録に使用できるストレージの量が限られているサーバーの場合、通常、新しいデータが使用可能になり、古いデータが破棄される間、前方に移動するスライドウィンドウが表示されます。
To cover the above usages, the following media properties with appropriate values are specified.
上記の使用法をカバーするために、適切な値を持つ次のメディアプロパティが指定されています。
Random access is the ability to specify and get media delivered starting from any time (instant) within the content, an operation called "seeking". The Media-Properties header will indicate the general capability for a media resource to perform random access.
ランダムアクセスとは、コンテンツ内でいつでも（瞬時に）メディアを指定して配信する機能で、「シーク」と呼ばれる操作です。 Media-Propertiesヘッダーは、メディアリソースがランダムアクセスを実行するための一般的な機能を示します。
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).
Media-Propertiesヘッダーで示されるようにランダムアクセスが可能な場合、シークスタイルヘッダーを使用してシーク時の実際の動作ポリシーを制御できます（セクション18.47）。
The following retention policies are used by media to limit possible protocol operations:
次の保存ポリシーは、可能なプロトコル操作を制限するためにメディアによって使用されます。
Unlimited: The media will not be removed as long as the RTSP session is in existence.
無制限：RTSPセッションが存在している限り、メディアは削除されません。
Time-Limited: The media will not be removed before the given wallclock time. After that time, it may or may not be available anymore.
時間制限：メディアは、指定された実時間の前に削除されません。それ以降は、利用できない場合があります。
Time-Duration: The media (on fragment or unit basis) will be retained for the specified duration.
Time-Duration：メディア（フラグメントまたはユニットベース）は、指定された期間保持されます。
The media content and its timeline can be of different types, e.g. pre-produced content on demand, a live source that is being generated as time progresses, or something that is dynamically altered or recomposed during playback. Therefore, a media property for content modifications is needed and the following initial values are defined:
メディアコンテンツとそのタイムラインは、異なるタイプにすることができます。オンデマンドで事前に作成されたコンテンツ、時間の経過とともに生成されるライブソース、または再生中に動的に変更または再構成されるもの。したがって、コンテンツを変更するためのメディアプロパティが必要であり、次の初期値が定義されています。
Immutable: The content of the media will not change, even if the representation, such as encoding or quality changes.
不変：エンコードや品質などの表現が変更されても、メディアのコンテンツは変更されません。
Dynamic: The content can change due to external methods or triggers, such as playlists, but this will be announced by explicit updates.
動的：コンテンツは、再生リストなどの外部メソッドまたはトリガーによって変更される可能性がありますが、これは明示的な更新によって通知されます。
Time-Progressing: As time progresses, new content will become available. If the content is also retained, it will become longer as everything between the start point and the point currently being made available can be accessed. If the media server uses a sliding-window policy for retention, the start point will also change as time progresses.
時間の経過：時間の経過とともに、新しいコンテンツが利用可能になります。コンテンツも保持されている場合は、開始点から現在利用できるようになるまでのすべてにアクセスできるため、コンテンツが長くなります。メディアサーバーが保持にスライディングウィンドウポリシーを使用する場合、開始点も時間の経過とともに変化します。
A particular media content item often supports only a limited set or range of scales when delivering the media. To enable the client to know what values or ranges of scale operations that the whole content or the current position supports, a media properties attribute for this is defined that contains a list with the values or ranges that are supported. The attribute is named "Scales". The "Scales" attribute may be updated at any point in the content due to content consisting of spliced pieces or content being dynamically updated by out-of-band mechanisms.
多くの場合、特定のメディアコンテンツアイテムは、メディアを配信するときに限られたセットまたは範囲のスケールのみをサポートします。コンテンツ全体または現在の位置がサポートするスケール操作の値または範囲をクライアントが認識できるようにするために、サポートされる値または範囲のリストを含む、このメディアプロパティ属性が定義されています。属性の名前は「スケール」です。 「スケール」属性は、スプライスされた断片から構成されるコンテンツまたは帯域外メカニズムによって動的に更新されるコンテンツが原因で、コンテンツの任意の時点で更新される可能性があります。
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.
オンデマンドの例：ランダムアクセス：Random-Access = 5.0、コンテンツの変更：不変、保持：無制限または時間制限。
Example of Dynamic On-Demand: Random Access: Random-Access=3.0, Content Modifications: Dynamic, Retention: Unlimited or Time-Limited.
動的オンデマンドの例：ランダムアクセス：Random-Access = 3.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
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].
ISO 10646文字セットは文字セットの切り替えを回避しますが、US-ASCIIが使用されている限り、アプリケーションからは見えません。これは、RTCP [RFC3550]のテキストフィールドに使用されるエンコーディングでもあります。
A request contains a method, the object the method is operating upon, and parameters to further describe the method. Methods are idempotent unless otherwise noted. Methods are also designed to require little or no state maintenance at the media server.
リクエストには、メソッド、メソッドが操作するオブジェクト、およびメソッドをさらに説明するためのパラメーターが含まれます。特に明記しない限り、メソッドはべき等です。また、メソッドは、メディアサーバーでの状態のメンテナンスをほとんどまたはまったく必要としないように設計されています。
RTSP messages are either requests from client to server or from server to client, and responses in the reverse direction. Request (Section 7) and response (Section 8) messages use a format based on the generic message format of RFC 5322 [RFC5322] for transferring bodies (the payload of the message). Both types of messages consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the headers, and possibly the data of the message body. The ABNF [RFC5234] below is for illustration only; the formal message specification is presented in Section 20.2.2.
RTSPメッセージは、クライアントからサーバーまたはサーバーからクライアントへの要求であり、逆方向の応答です。要求（セクション7）および応答（セクション8）メッセージは、本文（メッセージのペイロード）の転送にRFC 5322 [RFC5322]の一般的なメッセージ形式に基づく形式を使用します。どちらのタイプのメッセージも、開始行、0個以上のヘッダーフィールド（「ヘッダー」とも呼ばれる）、ヘッダーの終わりを示す空の行（CRLFの前に何もない行）、および場合によってはデータで構成されます。メッセージ本文の。以下のABNF [RFC5234]は、説明のみを目的としています。正式なメッセージ仕様は、セクション20.2.2に示されています。
generic-message = start-line *(rtsp-header CRLF) CRLF [ message-body-data ] start-line = Request-Line / Status-Line
generic-message = start-line *（rtsp-header CRLF）CRLF [message-body-data] start-line = Request-Line / Status-Line
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.
堅牢性のために、エージェントは、Request-LineまたはStatus-Lineが予期される場所で受信された空の行を無視する必要があります。言い換えると、エージェントがメッセージの最初でプロトコルストリームを読み取り、最初に任意の数のCRLFを受信する場合、すべてのCRLFを無視する必要があります。
RTSP header fields (see Section 18) include general-header, request-header, response-header, and message body header fields.
RTSPヘッダーフィールド（セクション18を参照）には、general-header、request-header、response-header、およびmessage bodyヘッダーフィールドが含まれます。
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.
同じフィールド名を持つ複数のヘッダーフィールドは、そのヘッダーフィールドのフィールド値全体がコンマ区切りのリストとして定義されている場合にのみ、メッセージに存在する可能性があります。メッセージのセマンティクスを変更せずに、複数のヘッダーフィールドを1つの「フィールド名：フィールド値」ペアに結合することが可能でなければなりません。後続の各フィールド値を最初のフィールド値にカンマで区切って追加します。したがって、同じフィールド名を持つヘッダーフィールドが受信される順序は、結合されたフィールド値の解釈にとって重要です。したがって、プロキシは、メッセージが転送されるときにこれらのフィールド値の順序を変更してはなりません（MUST NOT）。
Unknown message headers MUST be ignored (skipping over the header to the next protocol element, and not causing an error) by an RTSP server or client. An RTSP proxy MUST forward unknown message headers. Message headers defined outside of this specification that are required to be interpreted by the RTSP agent will need to use feature tags (Section 4.5) and include them in the appropriate Require (Section 18.43) or Proxy-Require (Section 18.37) header.
RTSPサーバーまたはクライアントは、不明なメッセージヘッダーを無視する必要があります（ヘッダーを次のプロトコル要素にスキップし、エラーの原因にはなりません）。 RTSPプロキシは、不明なメッセージヘッダーを転送する必要があります。この仕様外で定義され、RTSPエージェントによる解釈が必要なメッセージヘッダーは、機能タグ（セクション4.5）を使用して、適切なRequire（セクション18.43）またはProxy-Require（セクション18.37）ヘッダーに含める必要があります。
The message body (if any) of an RTSP message is used to carry further information for a particular resource associated with the request or response. An example of a message body is an SDP message.
RTSPメッセージのメッセージ本文（存在する場合）は、要求または応答に関連付けられた特定のリソースの詳細情報を伝えるために使用されます。メッセージ本文の例は、SDPメッセージです。
The presence of a message body in either a request or a response MUST be signaled by the inclusion of a Content-Length header (see Section 18.17) and Content-Type header (see Section 18.19). A message body MUST NOT be included in a request or response if the specification of the particular method (see Method Definitions (Section 13)) does not allow sending a message body. In case a message body is received in a message when not expected, the message body data SHOULD be discarded. This is to allow future extensions to define optional use of a message body.
要求または応答のいずれかにメッセージ本文が存在することは、Content-Lengthヘッダー（セクション18.17を参照）およびContent-Typeヘッダー（セクション18.19を参照）を含めることによって通知する必要があります。特定のメソッドの仕様（メソッド定義（セクション13）を参照）がメッセージ本文の送信を許可しない場合、メッセージ本文を要求または応答に含めることはできません（MUST NOT）。予期しないときにメッセージ本文がメッセージで受信された場合、メッセージ本文データを破棄する必要があります（SHOULD）。これは、将来の拡張でメッセージ本文のオプションの使用を定義できるようにするためです。
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メッセージでは、空行の後にメッセージ本文が続きます。その本文の長さは、Content-Lengthヘッダーの値によって決定されます（セクション18.17）。ヘッダーの値は、メッセージ本文の長さをオクテットで表します。このヘッダーフィールドが存在しない場合、値はゼロと見なされます。つまり、メッセージにメッセージ本文はありません。 HTTPメッセージとは異なり、RTSPメッセージには、メッセージ本文が含まれている場合は常にContent-Lengthヘッダーが含まれている必要があります。 RTSPはHTTP / 1.1の「チャンク」転送コーディングをサポートしていないことに注意してください（[RFC7230]のセクション4.1を参照）。
Given the moderate length of presentation descriptions returned, the server should always be able to determine its length, even if it is generated dynamically, making the chunked transfer encoding unnecessary.
適度な長さのプレゼンテーションの説明が返される場合、動的に生成される場合でも、サーバーは常にその長さを判断できるため、チャンク転送エンコーディングが不要になります。
General headers are headers that may be used in both requests and responses. The general-headers are listed in Table 1:
一般ヘッダーは、リクエストとレスポンスの両方で使用できるヘッダーです。一般的なヘッダーを表1に示します。
+--------------------+----------------+
| Header Name | Defined in |
+--------------------+----------------+
| Accept-Ranges | Section 18.5 |
| | |
| Cache-Control | Section 18.11 |
| | |
| Connection | Section 18.12 |
| | |
| CSeq | Section 18.20 |
| | |
| Date | Section 18.21 |
| | |
| Media-Properties | Section 18.29 |
| | |
| Media-Range | Section 18.30 |
| | |
| Pipelined-Requests | Section 18.33 |
| | |
| Proxy-Supported | Section 18.38 |
| | |
| Range | Section 18.40 |
| | |
| RTP-Info | Section 18.45 |
| | |
| Scale | Section 18.46 |
| | |
| Seek-Style | Section 18.47 |
| | |
| Server | Section 18.48 |
| | |
| Session | Section 18.49 |
| | |
| Speed | Section 18.50 |
| | |
| Supported | Section 18.51 |
| | |
| Timestamp | Section 18.53 |
| | |
| Transport | Section 18.54 |
| | |
| User-Agent | Section 18.56 |
| | |
| Via | Section 18.57 |
+--------------------+----------------+
Table 1: The General Headers Used in RTSP
表1：RTSPで使用される一般的なヘッダー
A request message uses the format outlined below regardless of the direction of a request, whether client to server or server to client:
要求メッセージは、クライアントからサーバー、サーバーからクライアントのいずれであっても、要求の方向に関係なく、以下に概説する形式を使用します。
o Request line, containing the method to be applied to the resource, the identifier of the resource, and the protocol version in use;
o リソースに適用されるメソッド、リソースの識別子、および使用中のプロトコルバージョンを含むリクエストライン。
o Zero or more Header lines, which can be of the following types: general-headers (Section 6), request-headers (Section 7.2), or message body headers (Section 9.1);
o ゼロ以上のヘッダー行。次のタイプがあります。一般ヘッダー（セクション6）、要求ヘッダー（セクション7.2）、またはメッセージ本文ヘッダー（セクション9.1）。
o One empty line (CRLF) to indicate the end of the header section;
o ヘッダーセクションの終わりを示す1行の空行（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 オプションで、1つ以上の行で構成されるメッセージ本文。オクテット単位のメッセージ本文の長さは、Content-Lengthメッセージヘッダーで示されます。
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 |
+---------------+----------------+
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
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を理解するためにサーバーが必要ですが、クライアントはHostリクエストヘッダーを使用することになっています。これは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.
Request-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.
この形式のOPTIONSは、最初にリクエストを受信するサーバーまたはプロキシの機能を決定します。特定のサーバーの機能を決定する必要がある場合は、介在するプロキシの機能に関係なく、サーバーのアドレスを含む絶対URIを使用してサーバーを明示的にアドレス指定する必要があります。
For example:
例えば：
OPTIONS rtsp://example.com RTSP/2.0
The RTSP headers in Table 3 can be included in a request, as request-headers, to modify the specifics of the request.
表3のRTSPヘッダーは、要求の詳細を変更するために、要求ヘッダーとして要求に含めることができます。
+---------------------+----------------+
| Header | Defined in |
+---------------------+----------------+
| Accept | Section 18.1 |
| | |
| Accept-Credentials | Section 18.2 |
| | |
| Accept-Encoding | Section 18.3 |
| | |
| Accept-Language | Section 18.4 |
| | |
| Authorization | Section 18.8 |
| | |
| Bandwidth | Section 18.9 |
| | |
| Blocksize | Section 18.10 |
| | |
| From | Section 18.23 |
| | |
| If-Match | Section 18.24 |
| | |
| If-Modified-Since | Section 18.25 |
| | |
| If-None-Match | Section 18.26 |
| | |
| Notify-Reason | Section 18.32 |
| | |
| Proxy-Authorization | Section 18.36 |
| | |
| Proxy-Require | Section 18.37 |
| | |
| Referrer | Section 18.41 |
| | |
| Request-Status | Section 18.42 |
| | |
| Require | Section 18.43 |
| | |
| Terminate-Reason | Section 18.52 |
+---------------------+----------------+
Table 3: The RTSP Request-Headers
表3：RTSP要求ヘッダー
Detailed header definitions are provided in Section 18.
詳細なヘッダーの定義については、セクション18を参照してください。
New request-headers may be defined. If the receiver of the request is required to understand the request-header, the request MUST include a corresponding feature tag in a Require or Proxy-Require header to ensure the processing of the header.
新しいリクエストヘッダーを定義できます。リクエストの受信者がリクエストヘッダーを理解する必要がある場合、リクエストはヘッダーの処理を確実にするために、対応する機能タグをRequireまたはProxy-Requireヘッダーに含める必要があります。
After receiving and interpreting a request message, the recipient responds with an RTSP response message. Normally, there is only one, final, response. Responses using the response code class 1xx is the only class for which there MAY be sent one or more responses prior to the final response message.
要求メッセージを受信して解釈した後、受信者はRTSP応答メッセージで応答します。通常、最終的な応答は1つだけです。応答コードクラス1xxを使用する応答は、最終応答メッセージの前に1つ以上の応答を送信できる唯一のクラスです。
The valid response codes and the methods they can be used with are listed in Table 4.
有効な応答コードとそれらを使用できるメソッドを表4に示します。
The first line of a response message is the Status-Line, consisting of the protocol version followed by a numeric status code and the textual phrase associated with the status code, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
応答メッセージの最初の行はStatus-Lineで、プロトコルバージョンと、それに続く数値のステータスコード、およびステータスコードに関連付けられたテキストフレーズで構成され、各要素はSP文字で区切られています。最後のCRLFシーケンスを除き、CRまたはLFは許可されません。
<RTSP-Version> SP <Status-Code> SP <Reason Phrase> CRLF
The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes are fully defined in Section 17. The reason phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the reason phrase is intended for the human user. The client is not required to examine or display the reason phrase.
Status-Code要素は、要求を理解して満足する試みの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:
ステータスコードの最初の桁は、応答のクラスを定義します。下2桁には、分類の役割はありません。最初の桁には5つの値があります。
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：リダイレクション-リクエストを完了するには、さらにアクションを実行する必要があります（304は除外されるため、3xxではなく3rrが使用されます。セクション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.
RTSP 2.0に定義された数値ステータスコードの個々の値、および対応する理由フレーズのサンプルセットを表4に示します。ここにリストされている理由フレーズは推奨されるだけです。プロトコルに影響を与えることなく、ローカルの同等のものに置き換えることができます。 RTSPはほとんどのHTTP / 1.1 [RFC2068]ステータスコードを採用し、RTSPにインポートすることが望ましい将来のHTTPステータスコードとの競合を避けるために、x50から始まるRTSP固有のステータスコードを追加したことに注意してください。これらのコードはすべて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（見つかりました）。その例外の理由は、ステータスコード300（HTTPの複数の選択肢）がRTSPに対して定義されていないためです。認識されないステータスコードを含む応答はキャッシュしてはなりません（MUST NOT）。たとえば、クライアントが認識できないステータスコード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 |
| | | |
| 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 |
+------+---------------------------------+--------------------------+
Table 4: Status Codes and Their Usage with RTSP Methods
表4：ステータスコードとRTSPメソッドでのそれらの使用法
The response-headers allow the request recipient to pass additional information about the response that cannot be placed in the Status-Line. This header gives information about the server and about further access to the resource identified by the Request-URI. All headers currently classified as response-headers are listed in Table 5.
応答ヘッダーを使用すると、要求の受信者は、Status-Lineに配置できない応答に関する追加情報を渡すことができます。このヘッダーは、サーバーに関する情報と、Request-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 |
+------------------------+----------------+
Table 5: The RTSP Response Headers
表5：RTSP応答ヘッダー
Response-header names can be extended reliably only in combination with a change in the protocol version. However, the usage of feature tags in the request allows the responding party to learn the capability of the receiver of the response. A new or experimental header can be given the semantics of response-header if all parties in the communication recognize them to be a response-header. Unrecognized headers in responses MUST be ignored.
応答ヘッダー名は、プロトコルバージョンの変更と組み合わせた場合にのみ、確実に拡張できます。ただし、要求での機能タグの使用により、応答側は応答の受信者の機能を知ることができます。通信のすべての関係者が応答ヘッダーであると認識した場合、新しいヘッダーまたは実験的なヘッダーに応答ヘッダーのセマンティクスを与えることができます。応答内の認識されないヘッダーは無視する必要があります。
Some request and response messages include a message body, if not otherwise restricted by the request method or response status code. The message body consists of the content data itself (see also Section 5.3).
一部の要求および応答メッセージには、要求メソッドまたは応答ステータスコードによる制限がない限り、メッセージ本文が含まれます。メッセージ本文はコンテンツデータ自体で構成されます（セクション5.3も参照）。
The SET_PARAMETER and GET_PARAMETER requests and responses, and the DESCRIBE response as defined by this specification, can have a message body; the purpose of the message body is defined in each case. All 4xx and 5xx responses MAY also have a message body to carry additional response information. Generally, a message body MAY be attached to any RTSP 2.0 request or response, but the content of the message body MAY be ignored by the receiver. Extensions to this specification can specify the purpose and content of message bodies, including requiring their inclusion.
SET_PARAMETERおよびGET_PARAMETER要求と応答、およびこの仕様で定義されているDESCRIBE応答には、メッセージ本文を含めることができます。メッセージ本文の目的は、それぞれの場合で定義されています。すべての4xxおよび5xx応答には、追加の応答情報を伝えるメッセージ本文も含まれる場合があります。一般に、メッセージ本文はRTSP 2.0要求または応答に添付される場合がありますが、メッセージ本文の内容は受信者によって無視される場合があります。この仕様の拡張により、メッセージ本文の目的と内容を指定できます。
In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives the message body.
このセクションでは、メッセージの送信者と受信者に応じて、送信者と受信者の両方がクライアントまたはサーバーを指します。
Message body header fields define meta-information about the content data in the message body. The message body header fields are listed in Table 6.
メッセージ本文のヘッダーフィールドは、メッセージ本文のコンテンツデータに関するメタ情報を定義します。メッセージ本文のヘッダーフィールドを表6に示します。
+------------------+----------------+
| Header | Defined in |
+------------------+----------------+
| Allow | Section 18.6 |
| | |
| Content-Base | Section 18.14 |
| | |
| Content-Encoding | Section 18.15 |
| | |
| Content-Language | Section 18.16 |
| | |
| Content-Length | Section 18.17 |
| | |
| Content-Location | Section 18.18 |
| | |
| Content-Type | Section 18.19 |
| | |
| Expires | Section 18.22 |
| | |
| Last-Modified | Section 18.27 |
+------------------+----------------+
Table 6: The RTSP Message Body Headers
表6：RTSPメッセージ本文のヘッダー
The extension-header mechanism allows additional message body header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields MUST be ignored by the recipient and forwarded by proxies.
拡張ヘッダーメカニズムでは、プロトコルを変更せずに追加のメッセージ本文ヘッダーフィールドを定義できますが、これらのフィールドを受信者が認識できると想定することはできません。認識されないヘッダーフィールドは、受信者によって無視され、プロキシによって転送される必要があります。
An RTSP message with a message body MUST include the Content-Type and Content-Length headers. When a message body is included with a message, the data type of that content data is determined via the Content-Type and Content-Encoding header fields.
メッセージ本文を含むRTSPメッセージには、Content-TypeおよびContent-Lengthヘッダーを含める必要があります。メッセージ本文がメッセージに含まれている場合、そのコンテンツデータのデータ型は、Content-TypeおよびContent-Encodingヘッダーフィールドを介して決定されます。
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.
Content-Typeは、基になるデータのメディアタイプを指定します。デフォルトのメディア形式はなく、本文で使用される実際の形式は、Content-Typeヘッダーで明示的に指定する必要があります。明示的であり、常に正確な情報を含むContent-Typeヘッダーを含めることを要求することにより、本文コンテンツのヒューリスティックベースの解釈における多くの落とし穴を回避します。 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.
Content-Encodingは、通常はデータ圧縮を目的として、要求されたリソースのプロパティである、データに適用される追加のコンテンツコーディングを示すために使用できます。デフォルトのエンコーディングは「アイデンティティ」です。つまり、メッセージ本文は変換されません。
The Content-Length of a message is the length of the content, measured in octets.
メッセージのContent-Lengthは、オクテットで測定されたコンテンツの長さです。
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.
メッセージ本文のコンテンツ形式は、Content-Typeヘッダーを使用して提供されます（セクション18.19）。要求の応答側が使用するメディアタイプを決定できるようにするには、要求にAcceptヘッダー（セクション18.1）を含めて、応答に適したサポートされているメディアタイプまたはメディアタイプの範囲を識別します。レスポンダが指定されたフォーマットのいずれもサポートしていない場合、リクエストのレスポンスは406（Not Acceptable）エラーコードになります。
The media types that may be used on requests with message bodies need to be determined through the use of feature tags, specification requirement, or trial and error. Trial and error works because when the responder does not support the media type of the message body, it will respond with a 415 (Unsupported Media Type).
メッセージ本文のリクエストで使用できるメディアタイプは、機能タグ、仕様要件、または試行錯誤を使用して決定する必要があります。レスポンダがメッセージ本文のメディアタイプをサポートしていない場合は、415（サポートされていないメディアタイプ）で応答するため、試行錯誤が機能します。
The formats supported and their negotiation is done individually on a per method and direction (request or response body) direction. Requirements on supporting particular media types for use as message bodies in requests and response SHALL also be specified on a per-method and per-direction basis.
サポートされている形式とそのネゴシエーションは、メソッドと方向（要求または応答本文）の方向ごとに個別に行われます。リクエストとレスポンスのメッセージ本文として使用する特定のメディアタイプをサポートする要件も、メソッドごとと方向ごとに指定する必要があります。
RTSP messages are transferred between RTSP agents and proxies using a transport connection. This transport connection uses TCP or TCP/TLS. This transport connection is referred to as the "connection" or "RTSP connection" within this document.
RTSPメッセージは、トランスポート接続を使用してRTSPエージェントとプロキシの間で転送されます。このトランスポート接続は、TCPまたはTCP / TLSを使用します。このトランスポート接続は、このドキュメントでは「接続」または「RTSP接続」と呼ばれます。
RTSP requests can be transmitted using the two different connection scenarios listed below:
RTSP要求は、以下に示す2つの異なる接続シナリオを使用して送信できます。
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.
コネクションレス型トランスポートシナリオにのみ関連すると思われるCSeqヘッダー（セクション18.20）などの特定のRTSPヘッダーは保持され、この仕様に従って実装する必要があります。 CSeqの場合、リクエストがパイプライン化されている場合、リクエストへの応答を照合するのに非常に役立ちます（セクション12を参照）。また、単一のTCP接続で複数のクライアント要求を集約するときに、さまざまな要求を追跡するプロキシでも役立ちます。
Since RTSP messages are transmitted using reliable transport protocols, they MUST NOT be retransmitted at the RTSP level. Instead, the implementation must rely on the underlying transport to 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レベルで再送信してはなりません（MUST NOT）。代わりに、実装は信頼性を提供するために、基になるトランスポートに依存する必要があります。 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アプリケーションの両方が要求を再送信する場合、各パケット損失またはメッセージ損失により、2回の再送信が発生する可能性があります。最初の試行がレシーバーに到達する前にトランスポートスタックがアプリケーション層の再送信を配信しないため、レシーバーは通常、アプリケーション層の再送信を利用できません。パケット損失の原因が輻輳である場合、異なるレイヤーで複数の再送信を行うと、輻輳が悪化します。
Lack of acknowledgment of an RTSP request should be handled within the constraints of the connection timeout considerations described below (Section 10.4).
RTSP要求の確認応答の欠如は、以下で説明する接続タイムアウトの考慮事項（セクション10.4）の制約内で処理する必要があります。
A TCP transport can be used for both persistent connections (for several message exchanges) and transient connections (for a single message exchange). Implementations of this specification MUST support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) allows the client to specify the port it will contact the server on, and defines the default port to use if one is not explicitly given.
TCPトランスポートは、永続的な接続（複数のメッセージ交換の場合）と一時的な接続（単一のメッセージ交換の場合）の両方に使用できます。この仕様の実装は、RTSP over TCPをサポートする必要があります。 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（rtsps）に加えて、代替ポート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.
URIで識別される特定のリソースにアクセスするためにTCP接続を開くRTSPクライアントは、URIのホスト部分とポート部分から派生したIPアドレスとポートを使用します。 IPアドレスは、URIで提供される明示的なアドレスか、URIでホスト名のAおよびAAAAレコードDNSルックアップを実行するときに提供されるアドレスのいずれかです。
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接続の損失に耐えることができます。たとえば、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セッションのメッセージを含む、サーバーとクライアント間のすべてのトランザクションに使用することをお勧めします。ただし、永続的な接続は、数回のメッセージ交換の後に閉じられる場合があります。たとえば、クライアントは、セッションでの初期のSETUPおよびPLAYメッセージ交換に永続的な接続を使用し、接続を閉じることができます。その後、クライアントがセッションのPAUSEなどの新しいリクエストを送信したい場合、新しい接続が開かれます。この接続は一時的または永続的のいずれかです。
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エージェントは、1つの接続を使用して、同じサーバー上の複数のRTSPセッションを処理できます（MAY）。 RTSPエージェントは、任意の時点で、RTSPセッションごとに複数の接続を使用してはなりません（SHALL NOT）。
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.
常に1つの接続のみを使用することで、サーバーからクライアントへの要求を送信する接続に関する混乱を回避できます。複数の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セッションのREDIRECTリクエストをクライアントに送信したいが、クライアントに到達できないために送信できない場合です。現在サーバーに接続していないクライアントにリクエストを送信しようとするサーバーは、リクエストを破棄する必要があります（SHALL）。
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エージェントには、RTSPセッションに関連していない、またはRTSPセッションの作成を要求している未解決の要求が10を超えてはなりません。
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エージェントは、プロキシへの同じ接続を介して、サーバーコンテキストまたはクライアントコンテキストのいずれかで、複数の異なる宛先に要求を送信できます。次に、プロキシは、プロキシからエージェントへの接続を介して、さまざまな宛先にメッセージをフォークします。これらの場合、複数の要求が未解決の場合、要求エージェントは、接続で送信された順序とは異なる順序で応答を受信する準備ができていなければなりません（MUST）。各宛先の複数のメッセージ間の順序は維持されます。ただし、異なる宛先からの応答間の順序は異なる場合があります。
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.
これは、行頭ブロッキングの状況を回避するためです。一連の要求では、早期の未解決の要求が1つの宛先で処理されるまでに時間がかかる場合があります。同時に、要求のシーケンスの後半にあった他の宛先からの応答がプロキシに到着した可能性があります。したがって、順不同の応答を許可することで、プロキシがこの応答をバッファリングして、代わりにできるだけ早く配信するように強制することを回避できます。これは、各個別の宛先に送信されたメッセージが要求の宛先で処理された順序には影響しないことに注意してください。
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.
このシナリオは、プロキシを含む2つのケースで発生する可能性があります。 1つ目は、クライアントからプロキシへの共通接続を使用して、さまざまなサーバー上のセッションに対する要求を発行するクライアントです。 2つ目は、サーバーからクライアントへのリクエスト用です。たとえば、リダイレクトは、さまざまな接続クライアント用にプロキシが作成した一般的なトランスポート接続を介してサーバーから送信されます。
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 response and then initiate the connection closing. The server SHOULD wait at least 10 seconds after sending the TEARDOWN response before closing the connection.
接続を通じて管理されているRTSPセッションに対して未処理の要求/応答トランザクションが存在しない場合、クライアントはいつでも接続を閉じることができます（MAY）。ただし、サーバーは、接続を介して管理されているすべてのRTSPセッションがタイムアウトになるまで接続を閉じないでください（セクション18.49）。サーバーは、接続を介して制御されている最後のRTSPセッションのセッションレベルのTEARDOWN要求に応答した直後に接続を閉じないでください。代わりに、サーバーは、クライアントがTEARDOWN応答を受信して処理し、接続のクローズを開始するのに適切な時間待機する必要があります。サーバーは、接続を閉じる前に、TEARDOWN応答を送信してから少なくとも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.
これは、クライアントが最後のセッションを切断した後、既存の接続で新しいセッションのSETUPを発行する時間を確保するためです。 10秒は、クライアントにサーバーへのメッセージを取得する十分な機会を与えるはずです。
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.
サーバーは、不完全なメッセージを受信した場合、およびメッセージが妥当な時間内に完了しない場合、接続を閉じることができます（MAY）。サーバーは、メッセージの完了またはメッセージの次の部分が到着するまで少なくとも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メッセージは、接続を閉じることによって終了してはなりません（SHOULD NOT）。そのようなメッセージは受信者によって不完全であると考えられて、捨てられるかもしれません。 RTSPメッセージは、セクション5で定義されているように適切に終了します。
Receivers of a request (responders) SHOULD respond to requests in a timely manner even when a reliable transport such as TCP is used. Similarly, the sender of a request (requester) SHOULD wait for a sufficient time for a response before concluding that the responder will not be acting upon its request.
要求の受信者（応答者）は、TCPなどの信頼性の高いトランスポートが使用されている場合でも、要求にタイムリーに応答する必要があります（SHOULD）。同様に、リクエストの送信者（リクエスター）は、レスポンダーがそのリクエストに基づいて行動しないと結論を下す前に、十分な時間応答を待つ必要があります（SHOULD）。
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秒以内にすべてのリクエストに応答する必要があります（SHOULD）。レスポンダは、リクエストの処理に5秒以上かかることを認識した場合、できるだけ早く100（Continue）レスポンスを送信する必要があります（SHOULD）。リクエスタに最終応答を送信する準備ができるまで、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接続を閉じることによって接続を中止することができます（MAY）。
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クライアントまたはサーバーは新しい接続を確立し、キューに入れられている、またはこの新しい接続で応答を受信していない要求を送信する必要があります（SHOULD）。 3番目に、RTSPサーバーが特定のRTSPセッションに有効な接続を確実に認識するために、RTSPエージェントは、古いRTSPセッションごとにそのRTSPセッションに他の要求がすぐに送信されない場合、キープアライブ要求を送信する必要があります（SHOULD）。接続。キープアライブ要求は通常、このエージェントがこのRTSPセッションを処理することをサーバーに通知するためのセッションヘッダーを持つSET_PARAMETERです。
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に2、3回の再送信を実行する時間を与えます。ユーザーが自分でプロセスを放棄しないように十分短い。ただし、特定のタイプのネットワークでは、10秒が積極的である場合があることに注意してください。 1xxメッセージの5秒の値はタイムアウトの半分であり、リクエスタ側でタイムアウトが発生する前に配信が成功する合理的な可能性があります。
RTSP requires the client to periodically show its liveness to the server or the server may terminate any session state. Several different protocol mechanism include in their usage a liveness proof from the client. These mechanisms are RTSP requests with a Session header to the server; if RTP & RTCP is used for media data transport and the transport is established, the RTCP message proves liveness; or through any other used media-transport protocol capable of indicating liveness of the RTSP client. It is RECOMMENDED that a client not wait to the last second of the timeout before trying to send a liveness message. The RTSP message may take some time to arrive safely at the receiver, due to packet loss and TCP retransmissions. To show liveness between RTSP requests being issued to accomplish other things, the following mechanisms can be used, in descending order of preference:
RTSPでは、クライアントがサーバーにその活性を定期的に示す必要があります。そうしないと、サーバーがセッション状態を終了する場合があります。いくつかの異なるプロトコルメカニズムには、その使用法にクライアントからの生存証明が含まれています。これらのメカニズムは、サーバーへのセッションヘッダーを持つRTSP要求です。 RTPおよびRTCPがメディアデータトランスポートに使用され、トランスポートが確立されている場合、RTCPメッセージは活性を証明します。または、RTSPクライアントの活性を示すことができる他の使用されているメディア転送プロトコルを介して。クライアントが活性メッセージを送信する前に、タイムアウトの最後の1秒まで待たないことをお勧めします。パケット損失と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を使用する必要があります（SHOULD）。 RTCPを使用してトランスポート統計を報告する場合、RTCPは必ずキープアライブとしても機能します。サーバーは、クライアントがサーバーのRTP送信元ソース（同期ソース（SSRC））について報告しているという事実とともに、ネットワークアドレスとポートによってクライアントを特定できます。 RTCPを使用することの欠点は、サーバーに到達するという統計的な保証しか提供しないことです。ただし、クライアントが誤ってタイムアウトする可能性は非常に低いため、ほとんどの場合無視できます。たとえば、タイムアウトが60秒で、RTCPメッセージに十分なビットレートが割り当てられているセッションで、平均5秒ごとにクライアントからサーバーにメッセージを送信するとします。そのクライアントは、5％のパケット損失があるネットワークの場合、そのセッションのタイムアウト間隔2.4 * E-16内で活性を確認できない可能性があります。タイムアウトが短い、パケット損失が大きい、またはRTCP帯域幅が小さいセッションも、以下のメカニズムの1つ以上を実装する必要があります（SHOULD）。
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_PARAMETER：キープアライブにSET_PARAMETERを使用する場合、ボディを含めないでください。このメソッドは、キープアライブの実行のみを目的としたリクエストに使用するための推奨されるRTSPメソッドです。 RTSPサーバーは、クライアントが常にこのメカニズムを使用できるように、SET_PARAMETERメソッドをサポートする必要があります。
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_PARAMETER：キープアライブにGET_PARAMETERを使用する場合、サーバーでの実装サポートに応じて、本体を含めないでください。 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.
オプション：この方法も使用できますが、サーバーが不要な処理を実行し、タスクに必要な応答よりも大きな応答が発生します。その理由は、サーバーがメディアリソースに関連付けられた機能を判断して、PublicおよびAllowヘッダーを正しく設定する必要があるためです。
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）は、セットアップ応答に含めることができますが、リクエストに含めることはできません（MUST NOT）。サーバーはこれを使用して、RTSPコマンドまたはその他の生命兆候の間でサーバーがアクティビティの不足によりセッションを閉じるまで待機する準備ができている時間をクライアントに示します（付録Bを参照）。タイムアウトは秒単位で測定され、デフォルトは60秒です。確立されたセッションでは、セッションタイムアウトの長さを変更してはなりません。
Explicit IPv6 [RFC2460] support was not present in RTSP 1.0. RTSP 2.0 has been updated for explicit IPv6 support. Implementations of RTSP 2.0 MUST understand literal IPv6 addresses in URIs and RTSP headers. Although the general URI format envisages potential future new versions of the literal IP address, usage of any such new version would require other modifications to the RTSP specification (e.g., address fields in the Transport header (Section 18.54)).
明示的なIPv6 [RFC2460]サポートはRTSP 1.0には存在しませんでした。 RTSP 2.0は、明示的なIPv6サポートのために更新されました。 RTSP 2.0の実装は、URIおよびRTSPヘッダー内のリテラルIPv6アドレスを理解する必要があります。一般的なURI形式では、リテラルIPアドレスの将来の新しいバージョンが想定されていますが、そのような新しいバージョンを使用するには、RTSP仕様（トランスポートヘッダーのアドレスフィールド（セクション18.54）など）を変更する必要があります。
Overload in RTSP can occur when servers and proxies have insufficient resources to complete the processing of a request. An improper handling of such an overload situation at proxies and servers can impact the operation of the RTSP deployment, and probably worsen the situation. RTSP defines the 503 (Service Unavailable) response (Section 17.5.4) to let servers and proxies notify requesting proxies and RTSP clients about an overload situation. In conjunction with 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.
RTSPの過負荷は、サーバーとプロキシのリソースが不十分で、リクエストの処理を完了できない場合に発生します。プロキシとサーバーでのこのような過負荷状態の不適切な処理は、RTSP展開の動作に影響を与え、状況を悪化させる可能性があります。 RTSPは、503（Service Unavailable）応答（17.5.4節）を定義して、サーバーとプロキシーが要求しているプロキシーとRTSPクライアントに過負荷状態について通知できるようにします。 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の回答には2つのスコープがあります。最初のスコープは確立されたRTSPセッション用であり、503応答をもたらす要求と応答自体が、過負荷になっているセッションを識別するセッションヘッダーを伝達します。この応答は、この特定のセッションにのみ適用されます。もう1つのスコープは、Request-URIでホストによって識別される一般的なRTSPサーバーです。このような503応答とRetry-Afterヘッダーは、新しいRTSPセッションを作成するためのSETUP要求を含め、そのサーバーに固有のセッションではないすべての要求に適用されます。
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.
過負荷状態のもう1つのスコープは、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（Service Unavailable）および553（Proxy Unavailable）応答コードを単に実装して使用するだけでは、過負荷状況を適切に処理するには不十分です。たとえば、単純なアプローチは、Retry-Afterヘッダーを固定値に設定して503応答を送信することです。ただし、これにより、複数の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 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.
ロードバランシングRTSPプロキシが使用されている場合、より複雑なケースが発生する可能性があります。これは、RTSPプロキシを使用して、リクエストを処理するRTSPサーバーのセットから選択する場合、または特定のサーバー名に複数のサーバーアドレスが使用可能な場合です。プロキシまたはクライアントは、RTSPサーバーまたはプロキシのいずれかから503（Service Unavailable）または553（Proxy Unavailable）応答コード、またはTCPタイムアウト（サーバーが要求メッセージを処理できない場合）を受信する場合があります。プロキシまたはクライアントは、他のアドレスまたは構成されたプロキシを再試行するだけですが、これらのアドレスから503（Service Unavailable）または553（Proxy Unavailable）応答またはTCPタイムアウトを受信することもあります。このような状況では、どのRTSPサーバー/プロキシ/アドレスも要求を処理できないため、RTSPエージェントは、新しい要求をRTSPサーバーに送信する前に待機する必要があります。特定のアドレスへの追加の要求は、受信したRetry-Afterヘッダーに従って遅延する必要があります。応答が受信されなかったか、TCPタイムアウトが発生したアドレスの場合、初期待機タイマーは5秒に設定する必要があります（SHOULD）。タイマーの平均値が30分に設定されている場合、値が30分を超えるまで、接続または応答の受信に失敗するたびに、そのタイマーを2倍にする必要があります。各スケジューリングのタイマーに同じ値を設定するのではなく、平均値に変動を追加して、平均値の0.5〜1.5倍の範囲内のランダムな値を選択する必要があります。
This section describes the available capability-handling mechanism that allows RTSP to be extended. Extensions to this version of the protocol are basically done in two ways. Firstly, new headers can be added. Secondly, new methods can be added. The capability-handling mechanism is designed to handle both cases.
このセクションでは、RTSPの拡張を可能にする使用可能な機能処理メカニズムについて説明します。このバージョンのプロトコルへの拡張は、基本的に2つの方法で行われます。まず、新しいヘッダーを追加できます。次に、新しいメソッドを追加できます。機能処理メカニズムは、両方のケースを処理するように設計されています。
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メソッドを使用して、それがサポートされているかどうかを検出できます。これは、相手にOPTIONSリクエストを発行することで行われます。 URIに応じて、特定のメディアリソース、サーバー全体、または単にネクストホップに適用されます。 OPTIONS応答には、示されたリソースでサポートされるすべてのメソッドを宣言するパブリックヘッダーが含まれている必要があります。
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.
クライアントがメソッドを試すだけなので、OPTIONSを使用してメソッドのサポートを検出する必要はありません。リクエストの受信者がメソッドをサポートしていない場合、メソッドが実装されていない（501）か、リソースに適用されない（405）かを示すエラーコードで応答します。 2つの検出方法のどちらを選択するかは、サービスの要件によって異なります。
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.
サポート：このヘッダーは、一般にクライアントとサーバーの両方が持つ機能の完全なセットを判別するために使用され、特定のリソースに依存していません。使用目的は、サポートされている機能を使用する前に判断することです。どのメソッドでも使用できますが、OPTIONSは、実装されているすべてのメソッドを同時に決定するため、最も適しています。リクエストを送信するとき、リクエスタはサポートされているすべての機能タグを含めることにより、すべての機能を宣言します。この結果、受信者は要求者の機能サポートを学習します。次に、レシーバーは一連の機能を応答に含めます。
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.
Proxy-Supported：このヘッダーは、Supportedヘッダーと同じように使用されますが、クライアントまたはサーバーのサポートされている機能を提供する代わりに、すべてのメンバーによって一般的にサポートされている共通機能のビューをリクエスターとレスポンダーの両方に提供しますクライアントとサーバー間のプロキシチェーン。リソースには依存しません。プロキシは、Supportedヘッダーが存在する場合は常にこのヘッダーを追加する必要がありますが、リクエスターとは無関係に追加することもできます。
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.
必須：このヘッダーは、要求を正しく実行するために機能を理解するためにエンドポイント（クライアントまたはサーバー）が必要なすべての要求に含めることができます。これは、たとえば、メディア配信を正しく設定するためにサーバーが特定のパラメータを理解する必要があるSETUP要求である場合があります。このパラメーターを無視すると、望ましい効果が得られないため、受け入れられません。したがって、要求を含む要求を受信するエンドポイントは、要求を理解せず、実行しない機能を否定的に確認する必要があります。機能がサポートされていない場合の応答は551（オプションはサポートされていません）です。また、サポートされていない機能は、応答のUnsupportedヘッダーに示されています。
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（オプションはサポートされていません）エラー応答で使用され、サポートされていない機能を示します。このような応答は、1つ以上の機能がサポートされていないRequireまたはProxy-Requireヘッダーの使用の結果のみです。この情報により、リクエスターはサポートされていない機能を認識しているため、状況を最大限に活用できます。
An implementation supporting all normative parts of this specification for the setup and control of playback of media uses the feature tag "play.basic" to indicate this support. The appendices (starting with letters) are not part of the functionality included in the feature tag unless the appendix is explicitly specified in a main section as being a required appendix.
メディアの再生のセットアップと制御に関するこの仕様のすべての規範的な部分をサポートする実装は、機能タグ「play.basic」を使用してこのサポートを示します。付録（文字で始まる）は、必須の付録としてメインセクションで明示的に指定されていない限り、featureタグに含まれる機能の一部ではありません。
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.
RTSP 1.0では、最小限の実装セクションがありました。しかし、それは残りの仕様と一致していませんでした。したがって、play.basicの機能を明示的に列挙しようとするのではなく、この仕様は全体として解釈する必要があり、規範的に必要と定義されている必要な機能が含まれています。
Pipelining is a general method to improve performance of request/ response protocols by allowing the requesting agent to have more than one request outstanding and to send them over the same persistent connection. For RTSP, where the relative order of requests will matter, it is important to maintain the order of the requests. Because of this, the responding agent MUST process the incoming requests in their sending order. The sending order can be determined by the CSeq header and its sequence number. For TCP, the delivery order will be the same, between two agents, as the sending order. The processing of the request MUST also have been finished before processing the next request from the same agent. The responses MUST be sent in the order the requests were processed.
パイプライン処理は、要求側エージェントが複数の要求を未処理にして、同じ永続的な接続を介して送信できるようにすることで、要求/応答プロトコルのパフォーマンスを向上させる一般的な方法です。リクエストの相対的な順序が重要となるRTSPの場合、リクエストの順序を維持することが重要です。このため、応答するエージェントは受信リクエストを送信順に処理する必要があります。送信順序は、CSeqヘッダーとそのシーケンス番号によって決定できます。 TCPの場合、配信順序は2つのエージェント間で送信順序と同じになります。同じエージェントからの次の要求を処理する前に、要求の処理も終了している必要があります。応答は、要求が処理された順序で送信する必要があります。
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 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 2.0では、RTSP 1.0の機能を超えてパイプラインのサポートが拡張されています。主な改善点として、メディア配信の設定と開始に関連するすべてのリクエストをパイプライン化できるようになりました。これは、Pipelined-Requestヘッダーで示されます（セクション18.33を参照）。このヘッダーを使用すると、クライアントは、最初の要求が作成したのと同じRTSPセッションコンテキストで2つ以上の要求を処理するように要求できます。つまり、クライアントは、2つ以上のメディアストリームを設定して、単一の応答を待つ必要なく再生するように要求できます。これにより、少なくとも1つのRTTによって、RTSPセッションの初期起動時間が短縮されます。
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.
パイプライン化された要求が1つ以上の以前の要求の正常な完了に基づいて構築される場合、要求者はすべての要求が期待どおりに実行されたことを確認する必要があります。一般的な例は、2つのSETUPリクエストとPLAYリクエストです。 SETUP要求の1つが予期せず失敗した場合でも、PLAY要求は引き続き正常に実行できます。ただし、再生されるメディアは2つではなく1つだけであるため、結果のプレゼンテーションは要求元のクライアントが期待するものとは異なります。この場合、クライアントはPAUSE要求を送信し、失敗したSETUP要求を修正してから、再生を要求できます。
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.
このメソッドは、Request-URIで識別されたリソースで実行される内容を示します。メソッド名では大文字と小文字が区別されます。将来、新しいメソッドが定義される可能性があります。メソッド名は$文字（10進数の36）で始めてはならず（MUST）、セクション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 |
+---------------+-----------+--------+-------------+-------------+
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：プレゼンテーション、S：ストリーム）について説明します。さらに、サーバーまたはクライアントの実装が必須（必須）、推奨、またはオプションのいずれであるかを示します。
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_PARAMETERはオプションです。たとえば、完全に機能するサーバーを構築して、パラメーターなしでメディアを配信できます。ただし、SET_PARAMETERは必須です。つまり、サーバーに実装する必要があります。これは、キープアライブの使用によるものです。 PAUSEが必要なのは、セッション全体を終了せずにPlay状態を終了する唯一の方法だからです。
If an RTSP agent does not support a particular method, it MUST return a 501 (Not Implemented) response code and the requesting RTSP agent, in turn, SHOULD NOT try this method again for the given agent/ resource combination. An RTSP proxy whose main function is to log or audit and not modify transport or media handling in any way MAY forward RTSP messages with unknown methods. Note that the proxy still needs to perform the minimal required processing, like adding the Via header.
RTSPエージェントが特定のメソッドをサポートしていない場合は、501（実装されていません）応答コードと要求側のRTSPエージェントを返す必要があります。そのため、指定されたエージェントとリソースの組み合わせに対してこのメソッドを再試行しないでください。ログまたは監査を主な機能とするRTSPプロキシであり、トランスポートまたはメディア処理を変更しないことで、未知のメソッドでRTSPメッセージを転送できます。プロキシは、Viaヘッダーの追加など、必要な最小限の処理を実行する必要があることに注意してください。
The semantics of the RTSP OPTIONS method is similar to that of the HTTP OPTIONS method described in Section 4.3.7 of [RFC7231]. However, in RTSP, OPTIONS is bidirectional in that a client can send the request to a server and vice versa. A client MUST implement the capability to send an OPTIONS request and a server or a proxy MUST implement the capability to respond to an OPTIONS request. In addition to this "MUST-implement" functionality, clients, servers and proxies MAY provide support both for sending OPTIONS requests and for generating responses to the requests.
RTSP OPTIONSメソッドのセマンティクスは、[RFC7231]のセクション4.3.7で説明されているHTTP OPTIONSメソッドのセマンティクスに似ています。ただし、RTSPでは、OPTIONSは双方向であり、クライアントはサーバーに要求を送信でき、その逆も可能です。クライアントはOPTIONS要求を送信する機能を実装する必要があり、サーバーまたはプロキシはOPTIONS要求に応答する機能を実装する必要があります。この「MUST-implement」機能に加えて、クライアント、サーバー、およびプロキシは、OPTIONSリクエストの送信と、リクエストへの応答の生成の両方をサポートする場合があります。
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).
OPTIONSリクエストはいつでも発行できます。そのような要求はセッション状態を変更しません。ただし、セッションの寿命が延びる可能性があります（以下を参照）。 OPTIONSリクエストのURIは、リクエストと対応するレスポンスのスコープを決定します。 Request-URIが特定のホスト上の特定のメディアリソースを参照している場合、スコープは、示されたRTSPエージェントによってそのメディアリソースに対してサポートされているメソッドのセットに制限されます。ホストアドレスのみを含むRequest-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.
リクエストのスコープに関係なく、パブリックヘッダーは常にOPTIONSレスポンスに含まれている必要があり、応答するRTSPエージェントによってサポートされているメソッドがリストされています。さらに、リクエストのスコープがメディアリソースに限定されている場合、メソッドのセットがパブリックヘッダーのセットと完全に一致しない限り、そのリソースに許可されるメソッドのセットを列挙するために、応答にAllowヘッダーを含める必要があります。 。指定されたリソースが利用できない場合、RTSPエージェントは3rrや4xxなどの適切な応答コードを返す必要があります（SHOULD）。応答するRTSPエージェントによってサポートされる機能のセットを照会するために、Supportedヘッダーをリクエストに含めることができます。
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セッションを維持することを目的としたOPTIONS要求には、関連付けられたセッション識別子とともにセッションヘッダーを含める必要があります。そのようなリクエストは、リクエストURIとしてメディアまたは集約されたコントロールURIも使用する必要があります（SHOULD）。
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
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の「gzipped-messages」機能タグは架空の機能であることに注意してください。
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.
DESCRIBEメソッドは、プレゼンテーションまたはメディアオブジェクトの説明をサーバーから取得するために使用されます。 DESCRIBE要求のRequest-URIは、対象のメディアリソースを識別します。クライアントは、リクエストにAcceptヘッダーを含めて、クライアントが理解できる記述形式をリストすることができます。 DESCRIBEメソッド要求が正常に満たされる場合、サーバーは要求されたリソースの説明で応答し、応答のメッセージ本文で説明を返す必要があります。 DESCRIBE応答/応答ペアは、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.
DESCRIBE応答には、それが記述するリソースのすべてのメディア初期化情報が含まれている必要があります（SHOULD）。サーバーは、DESCRIBE応答を別のサーバーに記述ポイントを持つことにより、メディアの間接化の手段として使用してはなりません（SHOULD NOT）。代わりに、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.
DESCRIBE応答に、それが記述する一連のストリームのすべてのメディア初期化情報を含めるように強制し、メディアの間接参照にDESCRIBEを使用しないようにすることで、他のアプローチに起因する可能性のあるループの問題を回避できます。
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
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仕様では、DESCRIBEメソッドを使用してこれを行う必要があるとは規定されていません。 RTSPクライアントが初期化情報を受け取る方法は3つあります。
o via an RTSP DESCRIBE request
o RTSP DESCRIBEリクエスト経由
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.
クライアントが代替ソースから有効な説明を取得する場合、クライアントは、同じメディアに対してDESCRIBE要求を発行せずに、初期化の目的でこの説明を使用できます（MAY）。クライアントは、任意の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.
最小限のサーバーがDESCRIBEメソッドをサポートすることをお勧めします。最小限のクライアントが、ユーザーインターフェースからのメディア初期化ファイルを受け入れる「ヘルパーアプリケーション」として機能する機能をサポートすることを強くお勧めします。クライアント。
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のSETUP要求は、ストリーミングメディアに使用されるトランスポートメカニズムを指定します。 SETUPメソッドは、RTSPセッションの作成と、すでにセットアップされているメディアストリームのトランスポートパラメータの変更という2つの異なるケースで使用できます。 SETUPは、Init、Ready、Playの3つの状態すべてで使用でき、トランスポートパラメータを変更できます。さらに、RTSPセッションの作成にはInitおよびReadyも使用できます。メディアリソースをセッションに追加するためのPlay状態でのSETUPメソッドの使用は規定されていません。
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.
ファイアウォールが介在するために、サーバーが固定マルチキャストアドレスを宛先としてアドバタイズする場合など、これらのパラメーターに影響がない場合でも、クライアントは既知のトランスポートパラメーターを示さなければなりません（MUST）。
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.
SETUPにはすべてのトランスポート初期化情報が含まれているため、ファイアウォールおよびその他の中間ネットワークデバイス（この情報を必要とする）は、メディア初期化用に予約されているDESCRIBE応答を解析するというより困難なタスクを免れます。
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ヘッダーに含める必要があります。これにより、サーバーは、リクエストに範囲のないPLAY応答など、将来のセッション関連の応答で使用できる形式を知ることができます。クライアントがプレゼンテーションに必要な時間形式をサポートしていない場合、サーバーは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.
SETUP応答では、サーバーは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応答には、Media-Propertiesヘッダーを含める必要があります（セクション18.29を参照）。 Media-Propertiesヘッダーのパラメーターの組み合わせは、セッションに存在するコンテンツの性質を示します（セクション4.7も参照）。たとえば、タイムシフトのあるライブストリームは、
o Random access set to Random-Access,
o Random-Accessに設定されたランダムアクセス、
o Content Modifications set to Time-Progressing, and
o Time-Progressingに設定されたコンテンツ変更、および
o Retention set to Time-Duration (with specific recording window time value).
o 保持はTime-Durationに設定されます（特定の記録ウィンドウの時間値を使用）。
The SETUP 200 OK response MUST include the Media-Range header (see Section 18.30) if the media is Time-Progressing.
メディアがTime-Progressingの場合、SETUP 200 OK応答にはMedia-Rangeヘッダー（セクション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
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：//example.com/foo/bar/baz.rm」を含むRTSPセッションを作成しようとしています。クライアントに受け入れられるトランスポートパラメータは、RTSPセットアップ接続の送信元のアドレスでクライアントポート4588および4589で受信されるRTP / AVP / UDP（デフォルトではUDP）または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.
既存のセッションコンテキストを参照するセッション識別子またはPipelined-RequestsヘッダーがサーバーへのSETUP要求に含まれていない限り、サーバーは、成功したSETUP要求に応答してセッション識別子を生成する必要があります。後者の場合、サーバーはこのSETUP要求を既存のセッション（集約セッション）にバンドルするか、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.
ただし、集約されたコントロールが提供されている場合でも、クライアントは、集約されたコントロールでセッションをセットアップしないことを選択できます（MAY）。集約コントロールURIがセッションの説明で指定されていない場合は、通常、非集約コントロールを使用する必要があることを示しています。
The SETUP of media streams in an aggregate that has not been given an aggregated control URI is unspecified.
集約された制御URIが与えられていない集約内のメディアストリームのSETUPは指定されていません。
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にはセッションの集約制御に十分な情報が含まれる場合がありますが、SET_PARAMETERなどの一部のメソッドでは、制御URIによって問題のリソースを簡単に識別できるため、集約制御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.
セッションは、TEARDOWN要求によって削除されるか、サーバーによってタイムアウトになるまで存在します。サーバーは、一定のタイムアウト期間内にクライアントから活性兆候を示さなかったセッションを削除してもよい（MAY）。デフォルトのタイムアウト値は60秒です。サーバーはこれを別の値に設定し、SETUP応答のセッションヘッダーのタイムアウトフィールドにその値を示すことができます（MAY）。詳細については、セクション18.49を参照してください。 RTSPセッションの活性の兆候には、そのセッションのIDを持つセッションヘッダーを含むクライアントからのすべてのRTSPリクエスト、およびRTPが基になるメディアストリームの転送に使用されている場合のRTCP送信者または受信者のレポートが含まれます。 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.
何らかの理由でセッションのSETUP要求が失敗した場合、セッション状態、および関連するストリームのトランスポートとその他のパラメーターは、サーバーがSETUP要求を受信したことがないかのように、それらの値から変更しないでください。
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, 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.
クライアントは、サーバーで許可されているトランスポートパラメータを変更するために、セッションですでにセットアップまたは再生されているストリームに対してSETUPリクエストを発行する場合があります。パラメータの変更を許可しない場合は、エラー455（この状態ではメソッドが無効）で応答する必要があります。トランスポートパラメータの変更をサポートする理由には、アプリケーション層のモビリティと柔軟性が、利用可能になったときに利用可能な最良のトランスポートを利用できるようにすることが含まれます。サーバーがPlay状態のときにトランスポートパラメータを変更しようとすると、クライアントが455エラーを受信した場合、SETUP要求を再度発行する前に、PAUSEを使用してサーバーをReady状態にしようとする場合があります。これも失敗した場合、トランスポートパラメータを変更するには、クライアントが影響を受けるメディアのTEARDOWNを実行してから、再度セットアップする必要があります。集約セッションの場合、すべてのメディアを同時に破棄しないことで、新しいセッションの作成を回避できます。
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.
Play状態のときにトランスポートパラメータを変更する要求に対するSETUP応答では、サーバーは、新しいトランスポートパラメータが使用されるポイントを示すRangeヘッダーを含める必要があります。さらに、RTPが配信に使用される場合、サーバーは、変更が行われるタイムスタンプとRTPシーケンス番号を示すRTP-Infoヘッダーも含める必要があります。 RTP-InfoとRangeの両方が応答に含まれている場合、「rtp_time」パラメータとRangeヘッダーの開始点は、対応する時間に対応している必要があります。つまり、PLAYと同じ方法で使用して、正しい同期情報が利用可能です。
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の変更など、Play状態の間に発生したトランスポートパラメーターの変更により同期関連情報が変更される場合、サーバーは必要な同期情報をSETUP応答に含める必要があります。ただし、サーバーは、可能であれば同期情報の変更を避ける必要があります。
This section describes the usage of the PLAY method in general, for aggregated sessions, and in different usage scenarios.
このセクションでは、集約されたセッションのPLAYメソッドの一般的な使用方法と、さまざまな使用シナリオについて説明します。
The PLAY method tells the server to start sending data via the mechanism specified in SETUP and which part of the media should be played out. PLAY requests are valid when the session is in Ready or Play state. A PLAY request MUST include a Session header to indicate to which session the request applies.
PLAYメソッドは、SETUPで指定されたメカニズムを介してデータの送信を開始するようサーバーに指示し、メディアのどの部分を再生する必要があるかを示します。 PLAYリクエストは、セッションがReadyまたはPlay状態のときに有効です。 PLAYリクエストには、リクエストがどのセッションに適用されるかを示すために、セッションヘッダーを含める必要があります。
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 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.
PLAYリクエストを受信すると、サーバーは、通常の再生時間を、メディアリソースの制限内で、Seek-Styleヘッダー（セクション18.47）に従って、受信したRangeヘッダーで指定された範囲の先頭に配置する必要があります。指定されている場合は範囲の最後まで、新しいPLAY要求が受信されるまで、PAUSE要求が受信されるまで（セクション13.5）、またはメディアの最後に到達するまで、ストリームデータを配信する必要があります。 PLAYリクエストにRangeヘッダーが存在しない場合、サーバーは現在の一時停止ポイントからメディアの終わりまで再生する必要があります。一時停止ポイントは、デフォルトでセッションの開始時からメディアの先頭までです。時間が経過し、保持されていないメディアの場合、一時停止ポイントは常にNPT「現在」、つまり現在の配信ポイントに等しく設定されます。一時停止ポイントは、PAUSEメソッドによってメディアの特定のポイントに設定することもできます。セクション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（範囲が無効）のエラーコードであり、メディアの範囲が有効なMedia-Rangeヘッダー（セクション18.30）を含める必要があります。保持される内容よりも前にクライアントが開始点を要求する、時間の経過するコンテンツを除き、開始点は保持されている最も古いコンテンツに調整されます。メディアのフロントエッジを超えた、つまり現在の「現在」の値を超えた開始ポイントの場合、サーバーは開始値を現在のフロントエッジに調整する必要があります（SHALL）。 Rangeヘッダーのストップポイント値は、現在のメディアエッジを超えている場合があります。その場合、サーバーは、要求された（場合によっては調整された）開始ポイントから、提供された停止ポイントまたはメディアの最初のいずれかまでメディアを配信する必要があります（SHALL）。特定の開始点からメディアの終わりまで再生するだけの場合は、暗黙的な停止点を持つRangeヘッダーを使用することをお勧めします。
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).
クライアントがメディアの終わりから再生を開始するように要求した場合、明示的にRangeヘッダーを使用するか、暗黙的にメディアの最後にある一時停止ポイントを使用して、457（無効な範囲）エラーを送信し、Media-Rangeヘッダーを含める必要があります。 （セクション18.30）。以下では、セッションが準備完了状態の場合にRangeヘッダーも応答に含める必要があり、メディアに一時停止ポイントが含まれることを指定しています。これは、一時停止ポイントまたは要求された開始ポイントがメディアの先頭にあり、Scaleヘッダー（セクション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
ランダムアクセスプロパティを持つメディアの場合、クライアントは、サーバーが使用する開始点選択のポリシーを示すことができます。これは、PLAYにSeek-Styleヘッダー（セクション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.
リクエスト。適用されるSeek-Styleは、メディアが実際に配信されるポイントを示すように調整されるため、Rangeヘッダーのコンテンツに影響します。
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.
最初からメディアを再生したいクライアントは、最初を指すRangeヘッダーを使用してPLAYリクエストを送信する必要があります（例： "npt = 0-"）。範囲ヘッダーなしでPLAY要求が受信され、メディア配信が最後に停止した場合、サーバーは457（無効な範囲）エラー応答で応答する必要があります（SHOULD）。その応答では、現在の一時停止ポイントをRangeヘッダーに含める必要があります。
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」）を持つ範囲を許可します。 PLAYリクエストで使用すると、サーバーはこれを現在の一時停止ポイントから配信を開始または再開するリクエストとして扱い、Rangeヘッダーで指定された終了時間で終了します。一時停止ポイントが指定された終了値よりも後にある場合、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
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.
サーバーは、リクエストにRangeヘッダーが存在しない場合でも、PLAY応答にRangeヘッダーを含める必要があります。応答は、含まれている要求のRangeヘッダーと同じ形式を使用する必要があります。リクエストにRangeヘッダーがなかった場合、セッション内の以前のPLAYリクエストで使用されたフォーマットを使用する必要があります（SHOULD）。以前のリクエストでフォーマットが示されていない場合、サーバーは、メディアでサポートされ、SETUPリクエストの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.
PLAY要求に対するエラー応答の場合、サーバーの応答は現在のセッション状態によって異なります。セッションが準備完了状態の場合、現在の一時停止ポイントは、一時停止ポイントを明示的な開始ポイントおよび暗黙的な停止ポイントとしてRangeヘッダーを使用して返されます。保持が制限されているために一時停止ポイントがリアルタイムで移動する、時間の経過するコンテンツの場合、現在の一時停止ポイントが返されます。再生状態のセッションの場合、現在の再生ポイントと範囲リクエストの残りの部分が返されます。保存期間が0秒を超えるメディアの場合、現在有効なMedia-Rangeヘッダーも応答に含まれる必要があります（SHALL）。
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.
PLAY応答には、同期情報を運ぶヘッダーが含まれる場合があります。必要な情報はメディア転送フォーマットに依存するため、ヘッダーとその使用法を指定する追加のルールが必要です。 RTPの場合、RTP-Infoヘッダーが指定されます。セクション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秒から最後までメディアをリクエストする単一のオーディオストリームの簡単な例です。サーバーは、実際の再生時間（10ミリ秒前（3.51））と、RTPスタックに必要なパラメーターを含むRTP-Infoヘッダーを含む200 OK応答を送信します。
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: 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.
サーバーは、配信される実際の開始ポイントで応答します。メディアソースに対して有効なフレーム境界への要求された範囲の整列が必要な場合、これは要求された範囲とは異なる場合があります。集約された一部のメディアストリームは、それより前のポイントから配信する必要がある場合があることに注意してください。また、一部のメディア形式では、個々のデータ単位ごとに非常に長い期間があります。したがって、クライアントがデータユニットを解析し、どこから開始するかを選択する必要がある場合があります。サーバーは、シークスタイルヘッダーを含めることにより、実際の開始点を選択するために使用するポリシーも示す必要があります（SHALL）。
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
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
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.
目的の範囲を再生した後、プレゼンテーションが準備完了状態に変化せず、メディア配信が停止するだけです。ストリームを準備完了状態にする必要がある場合は、PAUSE要求を発行する必要があります。ストリームがまだPlay状態にある間のPLAYリクエストは合法であり、一時停止リクエストの介入なしに発行できます。このようなリクエストは、現在のPLAYアクションをリクエストされた新しいアクションに置き換える必要があります。つまり、リクエストがレディ状態で受信された場合と同じ方法で処理されます。 Rangeヘッダーの範囲に暗黙の開始時刻（ "-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-Infoヘッダーは複数の行に分割されており、構文で許可されているように、後続の行は空白で始まります。
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
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
S->C: RTSP/2.0 200 OK
CSeq: 835
Date: Thu, 23 Jan 1997 15:35:06 GMT
Session: N465Wvsv0cjUy6tLqINkcf
Server: PhonyServer/1.0
Range: clock=19961108T142300Z-19961108T143520Z
Seek-Style: Next
RTP-Info:url="rtsp://example.com/meeting.en"
ssrc=0D12F123:seq=53745;rtptime=484589019
PLAY requests can operate on sessions controlling a single media stream and on aggregated sessions controlling multiple media streams.
PLAY要求は、単一のメディアストリームを制御するセッションと、複数のメディアストリームを制御する集約セッションで動作できます。
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.
集約セッションでは、PLAYリクエストに集約されたコントロールURIが含まれている必要があります。クライアントのPLAY Request-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.
最初のSETUP要求（セッションの作成）の後に1つ以上の追加のSETUP要求が続く集約セッションの場合、それらの追加のSETUP要求の後に、応答を待たずにPLAY要求をパイプライン化できます（セクション12）。この手順により、セッション確立の開始から、1つのRTTでメディアの再生が開始されるまでの遅延を減らすことができます。ただし、クライアントは、この手順を使用すると、PLAYの処理時に、つまりパイプラインでのPLAY要求の前のすべての要求の処理後に確立されたサーバー状態の再生が行われることに注意する必要があります。以前の要求のいずれかが失敗したため、この状態は意図されたものではない可能性があります。クライアントは、これらの要求からの応答に基づいてこれを簡単に判断できます。失敗した場合、クライアントはPAUSEを使用してメディアの再生を停止し、別のPLAY要求を発行する前に、意図した状態を再度確立することを試みることができます。
Clients can issue PLAY requests while the stream is in Play state and thus updating their request.
クライアントは、ストリームがPlay状態にある間にPLAYリクエストを発行して、リクエストを更新できます。
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.
準備完了状態のPLAYリクエストと比較した重要な違いは、現在の再生ポイントの処理と、リクエストのRangeヘッダーの作成方法です。セッションはメディアをアクティブに再生しており、再生ポイントは移動するため、リクエストが有効になる正確な時間を予測することは困難です。 PLAYヘッダーの表示方法に応じて、2つの異なるケースが存在します：完全置換または継続。最初の範囲指定に明示的な開始値（「npt = 45-」や「npt = 45-60」など）を指定することで、完全な置換が通知されます。この場合、サーバーは現在の再生ポイントで再生を停止し、配信を開始します。 Rangeヘッダーに応じたメディア。これは、クライアントが最初にPAUSEを送信してから、一時停止ポイントに基づいていない新しいPLAYリクエストを送信することと同じです。継続の場合、最初の範囲指定子には暗黙の開始点と明示的な停止値（Z）があり、たとえば "npt = -60"です。これは、このPLAYリクエストの前に再生される範囲指定子を変換する必要があることを示します（ XからY）を（XからZ）に変換し、これが最初に実行されたリクエストであるかのように続行します。現在の配信ポイントが停止ポイントを超えている場合、サーバーはすぐに配信を一時停止する必要があります（SHALL）。要求が正常に完了したので、200 OK応答で応答する必要があります。ストリームの終わりを伴うPLAY_NOTIFYも送信され、実際の停止ポイントを示します。一時停止ポイントは、要求された停止ポイントに設定されます。
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 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を再生する要求を受け取りました。新しいPLAY要求が前の要求の4秒後にサーバーに到着した場合、サーバーが最初の範囲を再生している間に有効になります（ 10-15）。サーバーは現在の再生を25秒に継続するように変更します。つまり、同等の単一のリクエストは、「範囲：npt = 10-25」を指定したPLAYになります。
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
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
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 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-).
PLAY状態でのPLAYリクエストの一般的な用途は、メディアのスケールの変更、つまり、早送りまたは巻き戻しの開始または終了です。このセクションで前述したように、クライアントは、継続または完全な置換である更新PLAY要求を発行できます。以下は、ストップポイントを指定せずに早送り（スケール= 2）を要求してから、早送りから通常のプレイアウト（スケール= 1）に変更するクライアントの例です。 2番目のPLAYリクエストでは、時間はサーバーが現在再生している場所に明示的に設定され（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
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
S->C: RTSP/2.0 200 OK
CSeq: 2035
Date: Thu, 23 Jan 1997 15:35:09 GMT
Session: apzA8LnjQ5KWTdw0kUkiRh
Server: PhonyServer/1.0
Range: npt=02:17:27.144-
Seek-Style: Next
Scale: 1.0
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=5712;rtptime=934239921,
url="rtsp://example.com/fizzle/videotrack"
ssrc=789DAF12:seq=57654;rtptime=2792842193
On-demand media is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29):
オンデマンドメディアは、次の場合にSETUP応答のMedia-Propertiesヘッダーの内容によって示されます（セクション18.29も参照）。
o the Random Access property is set to Random-Access;
o Random AccessプロパティはRandom-Accessに設定されています。
o the Content Modifications property is set to Immutable;
o コンテンツ変更プロパティは不変に設定されます。
o the Retention property is set to Unlimited or Time-Limited.
o RetentionプロパティがUnlimitedまたはTime-Limitedに設定されています。
Playing on-demand media follows the general usage as described in Section 13.4.1.
オンデマンドメディアの再生は、セクション13.4.1で説明されている一般的な使用法に従います。
Dynamic on-demand media is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29):
動的なオンデマンドメディアは、次の場合にSETUP応答のMedia-Propertiesヘッダーの内容によって示されます（セクション18.29も参照）。
o the Random Access property is set to Random-Access;
o Random AccessプロパティはRandom-Accessに設定されています。
o the Content Modifications property is set to Dynamic;
o コンテンツの変更プロパティは動的に設定されます。
o the Retention property is set to Unlimited or Time-Limited.
o RetentionプロパティがUnlimitedまたはTime-Limitedに設定されています。
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状態のメディアリソースの変更についてクライアントに通知するには、2つの方法があります。 1つ目は、クライアントがNotify-Reasonヘッダーがmedia-properties-updateに設定されたPLAY_NOTIFYリクエストを受信することです（セクション13.5.2を参照）。 Media-RangeヘッダーがPLAY_NOTIFYリクエストに存在する場合、クライアントはMedia-Rangeヘッダーの値を使用して追加のアクションを決定できます。 2番目の方法は、クライアントが本文なしでMedia-Rangeヘッダーを含むGET_PARAMETERリクエストを発行することです。 200 OK応答には、現在のMedia-Rangeヘッダーが含まれている必要があります（セクション18.30を参照）。
Live media is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29):
ライブメディアは、次の場合にSETUP応答のMedia-Propertiesヘッダーのコンテンツによって示されます（セクション18.29も参照）。
o the Random Access property is set to No-Seeking;
o Random AccessプロパティはNo-Seekingに設定されています。
o the Content Modifications property is set to Time-Progressing;
o [コンテンツの変更]プロパティはTime-Progressingに設定されています。
o the Retention property's Time-Duration is set to 0.0.
o RetentionプロパティのTime-Durationは0.0に設定されています。
For live media, the SETUP 200 OK response MUST include the Media-Range header (see Section 18.30).
ライブメディアの場合、SETUP 200 OK応答にはMedia-Rangeヘッダーを含める必要があります（セクション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.
クライアントは、範囲ヘッダーなしでPLAY要求を送信できます（MAY）。リクエストにRangeヘッダーが含まれている場合、「今」を表すシンボリック値を使用する必要があります。 NPTの場合、その範囲指定は「npt = now-」です。サーバーはRangeヘッダーを応答に含めなければならず（MUST）、それはシンボリック値ではなく明示的な時間値を示さなければなりません（MUST）。つまり、「npt = now-」は応答に使用できません。代わりに、「npt = 96.23-」のように、オープンインターバルとして表現された、セッション開始からの時間が推奨されます。対応する時間の絶対時間値（クロック）を指定できます（つまり、「クロック= 20030213T143205Z-」）。絶対時間形式は、クライアントがAccept-Rangesヘッダーを使用してサポートしている場合にのみ使用できます。
Certain media servers may offer recording services of live sessions to their clients. This recording would normally be from the beginning of the media session. Clients can randomly access the media between now and the beginning of the media session. This live media with recording is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29):
一部のメディアサーバーは、クライアントにライブセッションの録音サービスを提供する場合があります。この録音は通常、メディアセッションの最初から行われます。クライアントは、現在からメディアセッションの開始までの間にランダムにメディアにアクセスできます。この録音のあるライブメディアは、SETUP応答のMedia-Propertiesヘッダーのコンテンツによって示されます（セクション18.29も参照）。
o the Random Access property is set to Random-Access;
o Random AccessプロパティはRandom-Accessに設定されています。
o the Content Modifications property is set to Time-Progressing;
o [コンテンツの変更]プロパティはTime-Progressingに設定されています。
o the Retention property is set to Time-Limited or Unlimited
o RetentionプロパティがTime-LimitedまたはUnlimitedに設定されている
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応答には、このタイプのメディアのMedia-Rangeヘッダー（セクション18.30を参照）を含める必要があります。録音のあるライブメディアの場合、Rangeヘッダーはメディアの現在の配信ポイントを示し、Media-Rangeヘッダーは現在の時刻の前後で現在利用可能なメディアウィンドウを示します。このウィンドウは、過去に記録されたコンテンツ（メディアの現在時刻から見た）または将来の録画コンテンツ（メディアの現在時刻から見た）をカバーできます。サーバーは、要求されたウィンドウの境界に合わせて配信ポイントを調整します。クライアントが記録ウィンドウの外側にある配信ポイントを要求した場合、たとえば、要求されたポイントが過去に遠すぎる場合、サーバーは記録内の最も古いポイントを選択します。記録付きのライブメディアの配信中にクライアントが1.0（通常の再生レート）以外のスケール（セクション18.46）値で配信をリクエストした場合、セクション13.5.3の考慮事項が適用されます。
Certain media servers may offer time-shift services to their clients. This time shift records a fixed interval in the past, i.e., a sliding window recording mechanism, but not past this interval. Clients can randomly access the media between now and the interval. This live media with recording is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29):
一部のメディアサーバーは、クライアントにタイムシフトサービスを提供する場合があります。この時間シフトは、過去の固定間隔、つまりスライディングウィンドウ記録メカニズムを記録しますが、この間隔を過ぎていません。クライアントは、現在から間隔までの間、メディアにランダムにアクセスできます。この録音のあるライブメディアは、SETUP応答のMedia-Propertiesヘッダーのコンテンツによって示されます（セクション18.29も参照）。
o the Random Access property is set to Random-Access;
o Random AccessプロパティはRandom-Accessに設定されています。
o the Content Modifications property is set to Time-Progressing;
o [コンテンツの変更]プロパティはTime-Progressingに設定されています。
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応答には、このタイプのメディアのMedia-Rangeヘッダー（セクション18.30を参照）を含める必要があります。録音のあるライブメディアの場合、Rangeヘッダーはメディアの現在の時刻を示し、Media-Rangeヘッダーは現在の時刻の前後のウィンドウを示します。このウィンドウは、過去に記録されたコンテンツ（メディアの現在時刻から見た）または将来の録画コンテンツ（メディアの現在時刻から見た）をカバーできます。サーバーは、要求されたウィンドウの境界に合わせて再生ポイントを調整します。たとえば、クライアントが記録ウィンドウの外側にある再生ポイントを要求した場合、たとえば、要求が遠すぎる場合、サーバーは記録内の最も古い範囲を選択します。 13.5.3項の考慮事項は、クライアントが1.0（通常の再生レート）以外のスケール（セクション18.46）値を使用した配信を要求し、タイムシフト付きのライブメディアを配信する場合に適用されます。
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状態のセッションの非同期イベントについてクライアントに通知します。セッションヘッダーは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ヘッダーの値に応じて、メッセージ本文で使用できます。メッセージ本文が使用されている場合は、各Notify-Reasonの特定のセクションで説明されています。ただし、現在、メッセージ本文の使用を許可するNotify-Reasonはありません。この場合、メッセージ本文を使用する新しいNotify-Reasonsを追加する場合、いくつかの制限に従う必要があります。サーバーは任意のタイプのメッセージ本文を送信できますが、クライアントが受信したメッセージ本文を理解できるとは限りません。 。これはDESCRIBEに関連しています（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 media-properties-update（セクション13.5.2を参照）
o scale-change (see Section 13.5.3).
o スケール変更（セクション13.5.3を参照）。
A PLAY_NOTIFY request with the Notify-Reason header set to end-of-stream indicates the completion or near completion of the PLAY request and the ending delivery of the media stream(s). The request MUST NOT be issued unless the server is in the Play state. The end of the media stream delivery notification may be used either to indicate a successful completion of the PLAY request currently being served or to indicate some error resulting in failure to complete the request. The Request-Status header (Section 18.42) MUST be included to indicate which request the notification is for and its completion status. The message response status codes (Section 8.1.1) are used to indicate how the PLAY request concluded. The sender of a PLAY_NOTIFY MAY issue an updated PLAY_NOTIFY, in the case of a 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.
Notify-Reasonヘッダーがストリームの終わりに設定されたPLAY_NOTIFY要求は、PLAY要求の完了またはほぼ完了、およびメディアストリームの配信の終了を示します。サーバーがPlay状態でない限り、リクエストを発行してはなりません（MUST NOT）。メディアストリーム配信終了の通知は、現在提供されているPLAYリクエストが正常に完了したことを示すため、またはリクエストの完了に失敗したエラーを示すために使用できます。 Request-Statusヘッダー（セクション18.42）を含めて、通知の対象となるリクエストとその完了ステータスを示す必要があります。メッセージ応答ステータスコード（セクション8.1.1）は、PLAYリクエストがどのように終了したかを示すために使用されます。 PLAY_NOTIFYの送信者は、誤った情報で送信されたPLAY_NOTIFYの場合、更新されたPLAY_NOTIFYを発行する場合があります。たとえば、ストリームの終わりに達する前にPLAY_NOTIFYが発行されましたが、エラーが発生したため、以前に送信されたPLAY_NOTIFYにストリームが終了する誤った時間が含まれていました。この場合、完了の正しいステータスとすべての追加情報を含む新しいPLAY_NOTIFYを送信する必要があります。
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.
Notify-Reasonヘッダーがend-of-streamに設定されたPLAY_NOTIFYリクエストには、scale値が1でない場合、RangeヘッダーとScaleヘッダーを含める必要があります。Rangeヘッダーは、配信がタイムスケールで終了するストリーム内のポイントを示しますこれは、サーバーがPLAY応答で要求を実行するために使用したものです。サーバーはRangeヘッダーで「now」定数を使用してはなりません（MUST NOT）。適切なタイムスケールで実際の数値の終了位置を使用する必要があります。最後のメディアパケットを送信する前にストリーム終了通知が発行された場合、Rangeヘッダーの終了時間がクライアントが受信しているメディアの現在の時間を超えているため、これが明らかになります（例： "npt =- 15インチ、現在nptが14.2秒の場合。メディアのタイムスケールが逆方向に移動しているか、デフォルト以外のペースであるかが明確になるように、Scaleヘッダーを含めます。ストリーム終了通知は、クライアントが新しいPLAY要求を送信することを妨げません。
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ヘッダーはシーケンスパラメーターの最後のシーケンス番号を示す必要があります。
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要求のみを送信する必要があります（SHOULD）。 PLAY_NOTIFYリクエストで集約コントロールURIを使用することにより、RTSPサーバーは、これがセッション内のすべてのメディアリソースに適用されることを示します。メディア配信にRTPを使用する場合、対応するRTP-Infoをすべてのメディアリソースに含める必要があります。 1つ以上のメディアリソースの継続時間が、集約されたセッション内の他のリソースよりも大幅に短い場合、サーバーは、個々のメディアリソースURIを使用してストリームの終わり通知を送信して、これ以上のメディアがないことをエージェントに示すことができます（MAY）。現在アクティブなPLAYリクエストに関連する特定のメディアリソース。このような場合、残りのメディアリソースがストリームの最後に到達すると、集約コントロール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
C->S: RTSP/2.0 200 OK
CSeq: 854
User-Agent: PhonyClient/1.2
Session: CDtUJfDQXJWtJ7Iqua2xOi
A PLAY_NOTIFY request with a Notify-Reason header set to media-properties-update indicates an update of the media properties for the given session (see Section 18.29) or the available media range that can be played as indicated by the Media-Range header (Section 18.30). PLAY_NOTIFY requests with Notify-Reason header set to media-properties-update MUST include a Media-Properties and Date header and SHOULD include a Media-Range header. The Media-Properties header has session scope; thus, for aggregated sessions, the PLAY_NOTIFY request MUST use the aggregated control URI.
Notify-Reasonヘッダーがmedia-properties-updateに設定されたPLAY_NOTIFYリクエストは、特定のセッションのメディアプロパティの更新（セクション18.29を参照）、またはMedia-Rangeヘッダーで示される再生可能なメディア範囲（セクション18.30）。 Notify-Reasonヘッダーがmedia-properties-updateに設定されたPLAY_NOTIFYリクエストには、Media-PropertiesとDateヘッダーを含める必要があり、Media-Rangeヘッダーを含める必要があります（SHOULD）。 Media-Propertiesヘッダーにはセッションスコープがあります。したがって、集約されたセッションの場合、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時間未満である必要があります。説明したばかりの理由により、リクエストには、現在のメディア期間を提供するMedia-Rangeヘッダーと、現在の再生ポイントとリクエストされた範囲の残りの部分を示すRangeヘッダーを含める必要があります。
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.
Notify-Reasonヘッダーがmedia-properties-updateに設定されたPLAY_NOTIFYリクエストは、メッセージ本文を運ぶことはできません。
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
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でのみサーバーによって利用可能になるためです。この場合、配信ポイントは利用可能な最も古いメディアユニットに到達する可能性があり、利用可能なメディアがないため、このスケールでのそれ以上の再生は不可能になります。クライアントがメディアを失うのを防ぐには、メディアがストレージバッファーから削除されるのと同じレートにスケールを調整する必要があります。通常は、scale = 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 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.
もう1つのケースは、コンテンツ自体が接合部分で構成されているか、動的に更新される場合です。これらの場合、サーバーは、サポートされている1つのスケール値（スケール= 1.0とは異なる）から別のスケール値に変更する必要がある場合があります。この場合、サーバーは最も近い値を選択し、何を選択したかをクライアントに通知します。これらの場合、メディアプロパティも送信され、サポートされているスケール値が更新されます。これにより、クライアントは使用するスケール値を調整できます。
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.
上記のいずれかの場合の再生への影響を最小限に抑えるには、サーバーは再生プロパティを変更し、スケールをサポート可能な値に設定して、メディアの配信を継続する必要があります。この変更を行う場合、Notify-Reasonヘッダーを「scale-change」に設定したPLAY_NOTIFYメッセージを送信する必要があります。リクエストには、変更が有効になったメディア時間を含むRangeヘッダー、使用中の新しい値を含むScaleヘッダー、それが適用されるセッションの識別子を含むSessionヘッダー、サーバーのウォールクロック時間を含むDateヘッダーが含まれている必要があります変更の。時間経過するコンテンツの場合、この時点でのMedia-RangeヘッダーとMedia-Propertiesヘッダーも含める必要があります。サポートされているスケール値（「スケール」）を変更するコンテンツによるスケール変更の場合は、Media-Propertiesヘッダーを含める必要があります。
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-Infoヘッダーも含める必要があります。そのメディアの変更点に対応する値とオプションでシーケンス番号を含む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.
Notify-Reasonヘッダーが「Scale-Change」に設定されたPLAY_NOTIFYリクエストは、メッセージ本文を運ぶことはできません。
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
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.
PAUSE要求は、ストリーム配信を即座に中断（停止）させます。 PAUSEリクエストは、集約されたセッションの集約された制御URIを使用して行われ、すべてのメディアが停止されるか、集約されていないセッションのメディアURIを使用する必要があります。集約セッションでPAUSE要求を使用して単一のメディアをミュートしようとする試みは、460（集約操作のみ許可）エラーで応答する必要があります。再生を再開した後、トラックの同期を維持する必要があります。サーバーリソースは保持されますが、サーバーはSETUPメッセージのセッションヘッダーのタイムアウトパラメータで指定された期間一時停止した後、セッションを閉じてリソースを解放する場合があります。
Example:
例：
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
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.
PAUSE要求により、メッセージの受信時にストリーム配信が即座に中断され、一時停止ポイントはプレゼンテーションの現在のポイントに設定されます。メディアストリームのその一時停止ポイントを維持する必要があります。 Rangeヘッダーのない後続のPLAYリクエストは、一時停止ポイントから再開され、メディアが終了するまで再生されます。
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.
PLAYリクエストの範囲の再生されないままのものを含むRangeヘッダーを追加することにより、PAUSEリクエストの後の一時停止ポイントをクライアントに返す必要があります。ランダムアクセスプロパティを持つメディアの場合、範囲付き要求の再生を再開したい場合は、一時停止応答の範囲ヘッダーを含め、再生要求に次のポリシーのシークスタイルヘッダーを含めます。経過時間が長く、保存期間が0のメディアの場合、メディア配信を再開するためのフォローアップPLAY要求は、PAUSEへの応答で与えられた応答ではなく、「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
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
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のままです。 200 OK応答には、現在の一時停止ポイントを含むRangeヘッダーを含める必要があります。以下の例を参照してください。
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
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
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.
クライアントからサーバーへのTEARDOWNリクエストは、指定されたURIのストリーム配信を停止し、それに関連付けられたリソースを解放します。 TEARDOWN要求は、集約URIまたはメディアコントロールURIで実行できます。ただし、現在の状態によっては、いくつかの制限が適用されます。 TEARDOWNリクエストには、リクエストが適用されるセッションを示すセッションヘッダーが含まれている必要があります。 TEARDOWNリクエストには、Terminate-Reasonヘッダーを含めてはなりません。
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を使用するTEARDOWNは、任意の状態（準備完了および再生）で実行できます（MAY）。リクエストが成功すると、そのメディア配信が即座に停止され、セッション状態が破棄される必要があります。これは、応答にセッションヘッダーがないことによって示される必要があります。
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を使用したTEARDOWNは、準備完了状態でのみ実行できます。そのような要求は、示されたメディアストリームと関連するリソースをセッションから削除するだけです。これにより、セッションは要求の完了後に単一のメディアしか含まないため、非集約制御に戻る可能性があります。 TEARDOWN要求の処理後に存在するセッションには、そのTEARDOWN要求への応答として、Sessionヘッダーを含める必要があります。
Thus, the presence of the Session header indicates to the receiver of the response if the session is still extant or has been removed.
したがって、Sessionヘッダーの存在は、セッションがまだ存在しているか、削除されているかどうかを応答の受信者に示します。
Example:
例：
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
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).
サーバーは、サーバーからクライアントの方向にTEARDOWN要求を送信して、サーバーが進行中のセッションを強制的に終了したことを示すことができます。これは、利用可能なバックアップがないサーバーのメンテナンス、またはセッションが長期間非アクティブであったなど、いくつかの理由で発生する可能性があります。理由は、Terminate-Reasonヘッダー（セクション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セッションを維持している場合、サーバーはリソースを再利用できます。それには、Terminate-Reasonを "Session-Timeout"に設定してTEARDOWN要求を発行します。これは、クライアントがRTSPセッションで複数のセッションタイムアウト期間（セクション18.49）の間非アクティブであった場合に実行される場合があります。ただし、サーバーは、Session-Timeout期間の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.
サーバーが確立されたセッションへのサービスの提供を停止する必要があり、REDIRECTリクエストで指すサーバーがない場合は、TEARDOWN SHALLを使用してセッションを終了する必要があります。この方法は、回復不可能な内部エラーが発生し、サーバーにセッションを終了する以外の選択肢がない場合にも使用できます。
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.
TEARDOWNリクエストは、セッション集約コントロールURIでのみ行われる必要があり（つまり、セッション集約の場合、個々のメディアストリームを終了することはできません）、次のヘッダーを含める必要があります：SessionおよびTerminate-Reason。リクエストは、Sessionヘッダーで識別されたセッションにのみ適用されます。サーバーには、「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:
TEARDOWN要求は、ワイルドカードURI "*"で、セッションヘッダーなしで実行することもできます。そのようなリクエストの範囲はネクストホップ（つまり、サーバーと直接通信するRTSPエージェント）に限定され、ネクストホップRTSPエージェントとサーバー間のRTSP接続にも適用されます。この要求は、接続を介して管理されているすべてのセッションと保留中の要求が終了することを示しています。介在するプロキシは、以下のすべてをリストされた順序で実行する必要があります。
1. respond to the TEARDOWN request
1. TEARDOWNリクエストに応答する
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. TEARDOWN要求を該当する各クライアント（通常、アクティブセッションまたは未応答の要求を持つクライアント）に渡します。
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.
注：プロキシは、クライアントからのTEARDOWN応答を受け入れる責任があります。これらの応答は、リダイレクトで元のサーバーまたはターゲットサーバーに渡してはなりません（MUST NOT）。
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_PARAMETERリクエストは、URIで指定されたプレゼンテーションまたはストリームの指定されたパラメーターの値を取得します。リクエストにセッションヘッダーが存在する場合、パラメーターの値は指定されたセッションコンテキストで取得する必要があります。取得するパラメーターを指定する方法は2つあります。
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_PARAMETERを使用して現在の値を取得するために使用できるこの仕様のヘッダーを以下に示します。追加のヘッダーは将来指定されるかもしれません：
o Accept-Ranges
o Accept-Ranges
o Media-Range
o メディア範囲
o Media-Properties
o メディアプロパティ
o Range
o 範囲
o RTP-Info 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.
o RTP情報もう1つの方法は、取得する必要のあるパラメーターをリストするメッセージ本文を指定することです。 Content-Typeヘッダー（セクション18.19）は、メッセージ本文の形式を指定するために使用されます。リクエストの受信者がメッセージ本文に使用されるメディアタイプをサポートしていない場合、エラーコード415（サポートされていないメディアタイプ）を使用して応答する必要があります。 GET_PARAMETERリクエストへのレスポンダは、レスポンスのリクエストのメディアタイプを使用する必要があります。メッセージ本文のネゴシエーションに関するその他の考慮事項については、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_PARAMETERリクエストへの応答のサポートを実装するRTSPエージェントは、「テキスト/パラメータ」形式を実装する必要があります（付録F）。これにより、少なくとも1つの既知のパラメーター形式が実装され、パラメーター形式のネゴシエーションの失敗を防ぐことができます。
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.
メッセージの本文内で指定されたパラメーターはすべて、要求を受信するエージェントによって理解される必要があります。 1つ以上のパラメーターが理解されない場合、理解されなかったパラメーターをリストする本文を含めて、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
packets_received jitter
packets_receivedジッタ
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
packets_received：10ジッター：0.3838
This method requests the setting of the value of a parameter or a set of parameters for a presentation or stream specified by the URI. If the Session header is present in a request, the value of a parameter MUST be retrieved in the specified session context. The method MAY also be used without a message body. It is the RECOMMENDED method to be used in a request sent for the sole purpose of updating the keep-alive timer. If this request is successful, i.e., a 200 OK response is received, then the keep-alive timer has been updated. Any non-required header present in such a request may or may not have been processed. To allow a client to determine if any such header has been processed, it is necessary to use a feature tag and the Require header. Due to this reason it is RECOMMENDED that any parameters are sent in the body rather than using any header.
このメソッドは、URIで指定されたプレゼンテーションまたはストリームのパラメーターの値またはパラメーターのセットの設定を要求します。リクエストにセッションヘッダーが存在する場合、パラメーターの値は指定されたセッションコンテキストで取得する必要があります。このメソッドは、メッセージ本文なしでも使用できます。キープアライブタイマーの更新のみを目的として送信されるリクエストで使用されるのは、RECOMMENDEDメソッドです。この要求が成功した場合、つまり200 OK応答が受信された場合、キープアライブタイマーが更新されています。このような要求に存在する必須ではないヘッダーは、処理されている場合と処理されていない場合があります。このようなヘッダーが処理されたかどうかをクライアントが判断できるようにするには、機能タグと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.
メッセージ本文を使用して設定する必要のあるパラメーターをリストする場合、Content-Typeヘッダー（セクション18.19）を使用して、メッセージ本文の形式を指定します。リクエストの受信者がメッセージ本文に使用されるメディアタイプをサポートしていない場合、エラーコード415（サポートされていないメディアタイプ）を使用して応答する必要があります。メッセージ本文のネゴシエーションに関するその他の考慮事項については、9.3項を参照してください。 SET_PARAMETERリクエストへのレスポンダは、レスポンスのリクエストのメディアタイプを使用する必要があります。メッセージ本文のネゴシエーションに関するその他の考慮事項については、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_PARAMETERリクエストへの応答のサポートを実装するRTSPエージェントは、テキスト/パラメータ形式を実装する必要があります（付録F）。これは、パラメーターの少なくとも1つの既知の形式が実装されていることを確認し、パラメーター形式のネゴシエーションの失敗を防ぐためです。
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.
特定のリクエストが失敗した理由をクライアントが判断できるように、リクエストには単一のパラメーターのみを含めることをお勧めします。リクエストに複数のパラメーターが含まれている場合、サーバーは、すべてのパラメーターを正常に設定できる場合にのみ、リクエストを処理する必要があります。サーバーはパラメーターに同じ値を繰り返し設定することを許可しなければなりません（MUST）が、パラメーター値の変更を許可しない場合があります。リクエストの受信者がパラメータを理解できない、または見つけられない場合、エラー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
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
barparam: barstuff
barparam：barstuff
The REDIRECT method is issued by a server to inform a client that the service provided will be terminated and where a corresponding service can be provided instead. This may happen for different reasons. One is that the server is being administered such that it must stop providing service. Thus, the client is required to connect to another server location to access the resource indicated by the Request-URI.
REDIRECTメソッドはサーバーによって発行され、提供されたサービスが終了すること、および対応するサービスを代わりに提供できる場所をクライアントに通知します。これは、さまざまな理由で発生する可能性があります。 1つは、サーバーがサービスの提供を停止するように管理されていることです。したがって、クライアントは、Request-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.
REDIRECTリクエストには、リクエストの理由をクライアントに通知するTerminate-Reasonヘッダー（セクション18.52）が含まれている必要があります（SHALL）。理由に関連する追加のパラメーターも含まれる場合があります。ここでの目的は、サーバー管理者が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 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.
セッションヘッダーを含むREDIRECTリクエストには、エンドツーエンド（つまり、サーバーからクライアント）のスコープがあり、指定されたセッションにのみ適用されます。他のエンドツーエンドセッションが残っている間は、介在するプロキシは制御チャネルを切断しないでください。必須のLocationヘッダーには、クライアントが再接続する必要があるリソースを指す完全な絶対URIが含まれている必要があります（SHOULD）。具体的には、ロケーションにホストとポートのみを含めることはできません。クライアントは、エンドツーエンドセッションが確立されている場合に限り、Sessionヘッダーを含むREDIRECT要求を受信できます。
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:
クライアントは、サーバーとの通信または接続が確立されているときはいつでも、SessionヘッダーのないREDIRECT要求を受信できます。このようなリクエストの範囲はネクストホップ（つまり、サーバーと直接通信するRTSPエージェント）に限定され、制御されるすべてのセッション、およびネクストホップRTSPエージェントとサーバー間の接続に適用されます。セッションヘッダーのないREDIRECT要求は、接続を介して管理されているすべてのセッションと保留中の要求をリダイレクトする必要があることを示します。 Locationヘッダーは、そのようなリクエストに含まれている場合、RTSPエージェントが再接続するサーバーのホストアドレスとオプションのポート番号のみを含む絶対URIを含む必要があります（SHOULD）。介在するプロキシは、以下のすべてをリストされた順序で実行する必要があります。
1. respond to the REDIRECT request
1. REDIRECTリクエストに応答する
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. REDIRECT要求を該当する各クライアント（通常、アクティブなセッションまたは未応答の要求を持つクライアント）に渡します。
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.
注：プロキシーは、そのクライアントからのREDIRECT応答を受け入れる責任があります。これらの応答は、元のサーバーまたはリダイレクトされたサーバーに渡してはなりません（MUST NOT）。
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.
セッションまたはそのすべてのセッションを終了する必要があり、リダイレクトする代替サーバーがないサーバーは、代わりにTEARDOWN要求を使用する必要があります。
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.
Terminate-Reason "time"パラメータがREDIRECTリクエストに含まれていない場合、クライアントはリダイレクトをすぐに実行してサーバーに応答を返す必要があります（SHALL）。サーバーはセッションが終了したと見なし、成功した（2xx）応答を受信した後、関連する状態を解放できます。サーバーは応答を受信すると信号接続を閉じてもよい（MAY）。クライアントは2xx応答を送信した後に信号接続を閉じるべきである（SHOULD）。これの例外は、クライアントが、指定されたシグナリング接続によって管理されているサーバー上に複数のセッションを持っている場合です。この場合、クライアントは、シグナリング接続によって管理されているすべてのセッションに対するREDIRECT要求を受信してそれに応答したときに、接続を閉じる必要があります（SHOULD）。
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ヘッダーの「time」パラメーターを使用して、リダイレクトが発生する必要があるウォールクロック時間を示すことができます（MAY）。クライアントがサーバーと時刻を同期せずにリダイレクト時間を決定できるようにするには、サーバーはリクエストにDateヘッダーを含める必要があります。リダイレクトタイムラインが終了する前に、クライアントはセッションを終了し、接続を閉じている必要があります。サーバーは、締切時刻に達したときに単にサービスの提供を停止するか、または残りのセッションにTEARDOWN要求を発行できます。
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のルールに従ってREDIRECTリクエストがタイムアウトした場合、サーバーは、リクエストによってリダイレクトされるセッションまたはトランスポート接続を終了することができます（MAY）。これは、リダイレクト要求への応答を拒否するクライアントの誤動作に対する保護手段です。このアクションにより、リダイレクト要求の受信を確認しないというインセンティブがなくなります。
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.
REDIRECT要求が処理された後、Request-URIで識別されるリソースのメディアを引き続き受信したいクライアントは、指定されたホストとの新しいセッションを確立する必要があります。 Locationヘッダーで指定されたURIが有効なリソースURIである場合、クライアントはURIに対してDESCRIBE要求を発行する必要があります（SHOULD）。
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.
注：Locationヘッダーで示されるメディアリソースは、同一でも、わずかに異なっていても、まったく異なっていてもかまいません。これが、新しいDESCRIBE要求が発行される必要がある理由です。
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.
Locationヘッダーにホストアドレスのみが含まれている場合、クライアントは、新しいサーバーのメディアが古いサーバーのメディアと同一であると想定する場合があります。つまり、ホストアドレスを除いて、古いセッションのすべてのメディア構成情報は引き続き有効です。ただし、MTag識別子を使用した条件付きSETUPの使用は、仮定を確認する手段として推奨されます。
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
C->S: RTSP/2.0 200 OK
CSeq: 732
User-Agent: PhonyClient/1.2
Session: uZ3ci0K+Ld-M
In order to fulfill certain requirements on the network side, e.g., in conjunction with network address translators that block RTP traffic over UDP, it may be necessary to interleave RTSP messages and media-stream data. This interleaving should generally be avoided unless necessary since it complicates client and server operation and imposes additional overhead. Also, head-of-line blocking may cause problems. Interleaved binary data SHOULD only be used if RTSP is carried over TCP. Interleaved data is not allowed inside RTSP messages.
たとえばUDP経由のRTPトラフィックをブロックするネットワークアドレストランスレーターと組み合わせて、ネットワーク側の特定の要件を満たすために、RTSPメッセージとメディアストリームデータをインターリーブする必要がある場合があります。このインターリーブは、クライアントとサーバーの操作が複雑になり、追加のオーバーヘッドが発生するため、必要でない限り、通常は避けてください。また、行頭ブロッキングは問題を引き起こす可能性があります。インターリーブされたバイナリデータは、RTSPがTCPで伝送される場合にのみ使用してください。インターリーブされたデータは、RTSPメッセージ内では許可されません。
Stream data, such as RTP packets, is encapsulated by an ASCII dollar sign (36 decimal) followed by a one-octet channel identifier and the length of the encapsulated binary data as a binary, two-octet unsigned integer in network octet order (Appendix B of [RFC791]). The stream data follows immediately afterwards, without a CRLF, but including the upper-layer protocol headers. Each dollar sign block MUST contain exactly one upper-layer protocol data unit, e.g., one RTP packet.
RTPパケットなどのストリームデータは、ASCIIドル記号（10進数の36）にカプセル化され、その後に1オクテットのチャネル識別子と、カプセル化されたバイナリデータの長さが、ネットワークオクテット順のバイナリの2オクテットの符号なし整数として続きます（付録[RFC791]のB）。ストリームデータはCRLFなしで直後に続きますが、上位層のプロトコルヘッダーが含まれます。各ドル記号ブロックには、1つのRTPパケットなど、正確に1つの上位層プロトコルデータユニットが含まれている必要があります。
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) :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Embedded Interleaved Binary Data Format
図1：埋め込まれたインターリーブされたバイナリデータ形式
The channel identifier is defined in the Transport header with the interleaved parameter (Section 18.54).
チャネル識別子は、interleavedパラメータ（セクション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 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の場合、RTCPメッセージもTCP接続を介してサーバーによってインターリーブされます。 RTCPメッセージの使用は、トランスポートヘッダーのインターリーブパラメーターに2番目のチャネルを含む間隔を含めることで示されます（セクション18.54を参照）。 RTCPを使用する場合、パケットはRTPチャネルよりも高い最初の使用可能なチャネルで送信する必要があります。チャネルは双方向であり、両方向で同じチャネルIDを使用します。したがって、RTCPトラフィックは2番目のチャネルで両方向に送信されます。
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は、2つ以上のストリームがそのような方法でインターリーブされる場合、同期に必要になることがあります。また、これは、ネットワーク構成で必要な場合に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
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
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}
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プロキシは2つのトランスポート層接続を使用します。1つはRTSPクライアントからRTSPプロキシへ、もう1つは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.
Caching Proxy：このタイプのプロキシは、サーバーと接続のワークロードを削減するために使用されます。説明とメディアストリーム、つまりプレゼンテーションをキャッシュすることにより、プロキシはクライアントにコンテンツを提供できますが、キャッシュされて古くならない場合は、サーバーからコンテンツを要求する必要はありません。セクション16を参照してください。このタイプのプロキシは、RTSPエンドポイントの機能、つまり、Proxy-Requireが要求するものに加えて、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エンドポイントの機能、つまり、Proxy-Requireが要求するものに加えて、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クライアントが外部ネットワーク上のサーバーにアクセスできるようにするために使用されます。したがって、このプロキシは、プライベートアドレススペースとパブリックインターネットなど、2つのドメイン間の境界に配置されます。プロキシは必要な変換を実行します。通常はアドレスです。このタイプのプロキシは、メディアがクライアントに到達する前にメディア自体または変換を実行する制御されたゲートウェイにメディアをリダイレクトするために必要です。
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.
RTSP 2.0ではクライアントがプロキシからの接続の確立に使用される証明書チェーンを承認できるため、TLSで安全な通信を使用する場合は、すべてのタイプのプロキシを使用することもできます。セクション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 [RFC7825]で定義されているNATトラバーサル手順を使用することをお勧めします。これらの推奨事項の理由は、RTSPの拡張により、新しいメディア転送プロトコルまたはプロファイル、新しいパラメーターなどが発生し、維持されていないプロキシで失敗する可能性があるためです。これは、RTSPの将来の開発と使用を妨げます。
The existence of proxies must always be considered when developing new RTSP extensions. Most types of proxies will need to implement any new method to operate correctly in the presence of that extension. New headers can be introduced and will not be blocked by older proxies. However, it is important to consider if this header and its function are required to be understood by the proxy or if it can be simply forwarded. If the header needs to be understood, a feature tag representing the functionality MUST be included in the Proxy-Require header. Below are guidelines for analysis whether the header needs to be understood. The Transport header and its parameters are extensible, which requires handling rules for a proxy in order to ensure a correct interpretation.
新しいRTSP拡張を開発するときは、プロキシの存在を常に考慮する必要があります。ほとんどのタイプのプロキシは、その拡張が存在する場合に正しく動作するために、新しいメソッドを実装する必要があります。新しいヘッダーを導入することができ、古いプロキシによってブロックされません。ただし、このヘッダーとその機能をプロキシが理解する必要があるかどうか、または単純に転送できるかどうかを検討することが重要です。ヘッダーを理解する必要がある場合は、機能を表す機能タグをProxy-Requireヘッダーに含める必要があります。以下は、ヘッダーを理解する必要があるかどうかを分析するためのガイドラインです。トランスポートヘッダーとそのパラメーターは拡張可能です。正しい解釈を保証するには、プロキシーの処理ルールが必要です。
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:
プロキシがヘッダーを理解する必要があるかどうかは、ヘッダーがさまざまな機能を提供するため、簡単に判断できません。ヘッダーを理解する必要があるかどうかを評価する場合、機能を3つの主なカテゴリに分類できます。
Media modifying: The caching and translator proxies modify the actual media and therefore need also to understand the request directed to the server that affects how the media is rendered. Thus, this type of proxy also needs to understand the server-side functionality.
メディアの変更：キャッシングプロキシとトランスレータプロキシは実際のメディアを変更するため、メディアのレンダリング方法に影響を与えるサーバーへの要求も理解する必要があります。したがって、このタイプのプロキシもサーバー側の機能を理解する必要があります。
Transport modifying: The access and the security proxy both need to understand how the media transport is performed, either for opening pinholes or translating the outer headers, e.g., IP and UDP or TCP.
トランスポートの変更：アクセスとセキュリティプロキシはどちらも、ピンホールを開いたり、外部ヘッダー（IPやUDP、TCPなど）を変換したりするために、メディアトランスポートがどのように実行されるかを理解する必要があります。
Non-modifying: The audit proxy is special in that it does not modify the messages in other ways than to insert the Via header. That makes it possible for this type to forward RTSP messages that contain different types of unknown methods, headers, or header parameters.
非変更：監査プロキシは、Viaヘッダーを挿入する以外の方法でメッセージを変更しないという点で特別です。これにより、このタイプは、さまざまなタイプの不明なメソッド、ヘッダー、またはヘッダーパラメーターを含むRTSPメッセージを転送できます。
An extension has to be classified as mandatory to be implemented for a proxy, if an extension has to be understood by a "Transport modifying" type of proxy.
「トランスポート変更」タイプのプロキシで拡張機能を理解する必要がある場合、拡張機能をプロキシに実装するために必須として分類する必要があります。
RTSP proxies may have to multiplex several RTSP sessions from their clients towards RTSP servers. This requires that RTSP requests from multiple clients be multiplexed onto a common connection for requests outgoing to an RTSP server, and, on the way back, the responses be demultiplexed from the server to per-client responses. On the protocol level, this requires that request and response messages be handled in both directions, requiring that there be a mechanism to correlate which request/response pair exchanged between proxy and server is mapped to which client (or client request).
RTSPプロキシは、クライアントからRTSPサーバーに向けて複数のRTSPセッションを多重化する必要がある場合があります。これには、複数のクライアントからのRTSP要求が、RTSPサーバーに送信される要求の共通接続に多重化され、その途中で、サーバーからクライアントごとの応答への応答が逆多重化される必要があります。プロトコルレベルでは、これにより要求メッセージと応答メッセージを双方向で処理する必要があり、プロキシとサーバー間で交換される要求/応答ペアがどのクライアント（またはクライアント要求）にマッピングされるかを関連付けるメカニズムが必要です。
This multiplexing of requests and demultiplexing of responses is done by using the CSeq header field. The proxy has to rewrite the CSeq in requests to the server and responses from the server and remember which CSeq is mapped to which client. The proxy also needs to ensure that the order of the message related to each client is maintained. Section 18.20 defines the handling of how requests and responses are rewritten.
この要求の多重化と応答の逆多重化は、CSeqヘッダーフィールドを使用して行われます。プロキシは、サーバーへの要求とサーバーからの応答でCSeqを書き換え、どのCSeqがどのクライアントにマップされているかを覚えておく必要があります。プロキシは、各クライアントに関連するメッセージの順序が維持されていることを確認する必要もあります。セクション18.20は、要求と応答がどのように書き直されるかの処理を定義しています。
In HTTP, request/response pairs are cached. RTSP differs significantly in that respect. Responses are not cacheable, with the exception of the presentation description returned by DESCRIBE. (Since the responses for anything but DESCRIBE and GET_PARAMETER do not return any data, caching is not really an issue for these requests.) However, it is desirable for the continuous media data, typically delivered out-of-band with respect to RTSP, to be cached, as well as the session description.
HTTPでは、要求/応答のペアがキャッシュされます。 RTSPはその点で大きく異なります。 DESCRIBEによって返されるプレゼンテーションの説明を除いて、応答はキャッシュできません。 （DESCRIBEとGET_PARAMETER以外の応答はデータを返さないため、これらの要求ではキャッシュは実際には問題になりません。）ただし、通常は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またはPLAY要求を受信すると、プロキシは、継続的なメディアコンテンツとその説明の最新のコピーがあるかどうかを確認します。 SETUPまたはDESCRIBE要求をそれぞれ発行し、Last-Modifiedヘッダーをキャッシュされたコピーのヘッダーと比較することで、コピーが最新かどうかを判別できます。コピーが最新でない場合は、必要に応じてSETUPトランスポートパラメーターを変更し、要求をオリジンサーバーに転送します。 PLAYやPAUSEなどの後続の制御コマンドは、プロキシを変更せずに渡します。プロキシは継続的なメディアデータをクライアントに配信しますが、後で再利用するためにローカルコピーを作成することもあります。キャッシュの正確な許可された動作は、セクション18.11で説明されているcache-responseディレクティブによって与えられます。ストリームのリクエスターの低レベルの詳細がオリジンサーバーで変更されている可能性があるため、リクエスターに現在ストリームを提供している場合、キャッシュはDESCRIBEリクエストに応答する必要があります。
Note that an RTSP cache is of the "cut-through" variety. Rather than retrieving the whole resource from the origin server, the cache simply copies the streaming data as it passes by on its way to the client. Thus, it does not introduce additional latency.
RTSPキャッシュには「カットスルー」の種類があることに注意してください。キャッシュは、オリジンサーバーからリソース全体を取得するのではなく、ストリーミングデータをコピーして、クライアントに向かう途中でストリーミングデータを単純にコピーします。したがって、追加の遅延は発生しません。
To the client, an RTSP proxy cache appears like a regular media server. To the media origin server, an RTSP proxy cache appears like a client. Just as an HTTP cache has to store the content type, content language, and so on for the objects it caches, a media cache has to store the presentation description. Typically, a cache eliminates all transport references (e.g., multicast information) from the presentation description, since these are independent of the data delivery from the cache to the client. Information on the encodings remains the same. If the cache is able to translate the cached media data, it would create a new presentation description with all the encoding possibilities it can offer.
クライアントにとって、RTSPプロキシキャッシュは通常のメディアサーバーのように見えます。メディアオリジンサーバーにとって、RTSPプロキシキャッシュはクライアントのように見えます。 HTTPキャッシュがキャッシュするオブジェクトのコンテンツタイプ、コンテンツ言語などを格納する必要があるのと同様に、メディアキャッシュはプレゼンテーションの説明を格納する必要があります。通常、キャッシュは、トランスポート参照（マルチキャスト情報など）をすべてキャッシュからクライアントへのデータ配信とは独立しているため、プレゼンテーションの説明から削除します。エンコーディングに関する情報は変わりません。キャッシュがキャッシュされたメディアデータを変換できる場合、提供できるすべてのエンコーディングの可能性を備えた新しいプレゼンテーションの説明が作成されます。
When a cache has a stale entry that it would like to use as a response to a client's request, it first has to check with the origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. This is called "validating" the cache entry. To avoid having to pay the overhead of retransmitting the full response if the cached entry is good, and at the same time avoiding having to pay the overhead of an extra round trip if the cached entry is invalid, RTSP supports the use of conditional methods.
キャッシュにクライアントの要求への応答として使用したい古いエントリがある場合、最初にオリジンサーバー（またはおそらく新しい応答を持つ中間キャッシュ）をチェックして、キャッシュされたエントリがまだ使用可能かどうかを確認する必要があります。これは、キャッシュエントリの「検証」と呼ばれます。キャッシュされたエントリが適切な場合に完全な応答を再送信するオーバーヘッドを支払う必要を回避し、同時にキャッシュされたエントリが無効な場合に余分なラウンドトリップのオーバーヘッドを支払う必要を回避するために、RTSPは条件付きメソッドの使用をサポートしています。
The key protocol features for supporting conditional methods are those concerned with "cache validators." When an origin server generates a full response, it attaches some sort of validator to it, which is kept with the cache entry. When a client (user agent or proxy cache) makes a conditional request for a resource for which it has a cache entry, it includes the associated validator in the request.
条件付きメソッドをサポートするための主要なプロトコル機能は、「キャッシュバリデーター」に関係するものです。オリジンサーバーが完全な応答を生成するとき、それはある種のバリデーターをそれに接続します。それはキャッシュエントリーと共に保持されます。クライアント（ユーザーエージェントまたはプロキシキャッシュ）がキャッシュエントリを持つリソースに対して条件付き要求を行うと、関連するバリデーターが要求に含まれます。
The server then checks that validator against the current validator for the requested resource, and, if they match (see Section 16.1.3), it responds with a special status code (usually, 304 (Not Modified)) and no message body. Otherwise, it returns a full response (including message body). Thus, avoiding transmitting the full response if the validator matches and avoiding an extra round trip if it does not match.
次に、サーバーはリクエストされたリソースの現在のバリデーターに対してそのバリデーターをチェックし、それらが一致する場合（セクション16.1.3を参照）、特別なステータスコード（通常は304（未変更））で応答し、メッセージ本文はありません。それ以外の場合は、完全な応答（メッセージ本文を含む）を返します。したがって、バリデーターが一致する場合は完全な応答の送信を回避し、一致しない場合は余分な往復を回避します。
In RTSP, a conditional request looks exactly the same as a normal request for the same resource, except that it carries a special header (which includes the validator) that implicitly turns the method (usually DESCRIBE or SETUP) into a conditional.
RTSPでは、条件付きリクエストは、メソッド（通常はDESCRIBEまたはSETUP）を条件付きに暗黙的に変換する特別なヘッダー（バリデーターを含む）を運ぶことを除いて、同じリソースに対する通常のリクエストとまったく同じに見えます。
The protocol includes both positive and negative senses of cache-validating conditions. That is, it is possible to request that a method be performed either if and only if a validator matches or if and only if no validators match.
このプロトコルには、キャッシュ検証条件の肯定的な意味と否定的な意味の両方が含まれています。つまり、バリデーターが一致する場合にのみ、またはバリデーターが一致しない場合にのみ、メソッドの実行を要求することができます。
Note: a response that lacks a validator may still be cached, and served from cache until it expires, unless this is explicitly prohibited by a cache directive (see Section 18.11). However, a cache cannot perform a conditional retrieval if it does not have a validator for the resource, which means it will not be refreshable after it expires.
注：バリデーターがない応答は、キャッシュディレクティブによって明示的に禁止されていない限り、キャッシュされ、期限が切れるまでキャッシュから提供されます（セクション18.11を参照）。ただし、リソースのバリデーターがない場合、キャッシュは条件付き取得を実行できません。つまり、有効期限が切れた後はキャッシュを更新できません。
Media streams that are being adapted based on the transport capacity between the server and the cache make caching more difficult. A server needs to consider how it views the caching of media streams that it adapts and potentially instruct any caches not to cache such streams.
サーバーとキャッシュ間の転送容量に基づいて調整されているメディアストリームは、キャッシュをより困難にします。サーバーは、適応するメディアストリームのキャッシュをどのように表示するかを検討する必要があり、そのようなストリームをキャッシュしないようにキャッシュに指示する可能性があります。
The Last-Modified header (Section 18.27) value is often used as a cache validator. In simple terms, a cache entry is considered to be valid if the cache entry was created after the Last-Modified time.
Last-Modifiedヘッダー（セクション18.27）の値は、キャッシュバリデーターとしてよく使用されます。簡単に言うと、キャッシュエントリがLast-Modified時間後に作成された場合、キャッシュエントリは有効であると見なされます。
The MTag response-header field-value, a message body tag, provides for an "opaque" cache validator. This might allow more reliable validation in situations where it is inconvenient to store modification dates, where the one-second resolution of RTSP-date values is not sufficient, or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification dates.
MTag応答ヘッダーフィールド値、メッセージ本文タグは、「不透明な」キャッシュバリデーターを提供します。これにより、変更日付を保存するのが不便な場合、RTSP日付値の1秒の解決では不十分な場合、または元のサーバーが変更の使用から生じる可能性がある特定のパラドックスを回避したい場合に、より信頼できる検証が可能になる場合があります。日付。
Message body tags are described in Section 4.6
メッセージ本文タグについては、セクション4.6で説明します。
Since both origin servers and caches will compare two validators to decide if they represent the same or different entities, one normally would expect that if the message body (i.e., the presentation description) or any associated message body headers changes in any way, then the associated validator would change as well. If this is true, then this validator is a "strong validator". The Message body (i.e., the presentation description) or any associated message body headers is named an entity for a better understanding.
起点サーバーとキャッシュの両方が2つのバリデーターを比較して、それらが同じエンティティか異なるエンティティを表すかを決定するため、通常、メッセージ本文（つまり、プレゼンテーションの説明）または関連するメッセージ本文ヘッダーが何らかの方法で変更されると、関連するバリデーターも変更されます。これがtrueの場合、このバリデーターは「強力なバリデーター」です。メッセージ本文（つまり、プレゼンテーションの説明）または関連するメッセージ本文のヘッダーは、わかりやすくするためにエンティティと呼ばれます。
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秒の解像度で表されている場合、リソースが1秒間に2回変更される可能性があるため、弱いバリデータである可能性があります。
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.
バリデーターの「使用」は、クライアントがリクエストを生成し、検証ヘッダーフィールドにバリデーターを含める場合、またはサーバーが2つのバリデーターを比較する場合のいずれかです。
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.
強力なバリデーターはどのような状況でも使用できます。弱いバリデーターは、エンティティの正確な等価性に依存しないコンテキストでのみ使用できます。たとえば、完全なエンティティの条件付きDESCRIBEにはどちらの種類も使用できます。ただし、サブレンジの取得には強力なバリデーターしか使用できません。そうしないと、クライアントが内部的に一貫性のないエンティティになる可能性があるためです。
Clients MAY issue DESCRIBE requests with either weak or strong validators. Clients MUST NOT use weak validators in other forms of requests.
クライアントは、弱いまたは強いバリデーターを使用してDESCRIBEリクエストを発行できます（MAY）。クライアントは、他の形式のリクエストで弱いバリデーターを使用してはなりません。
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がバリデーターで定義する唯一の関数は比較です。比較コンテキストが弱いバリデーターの使用を許可するかどうかに応じて、2つのバリデーター比較関数があります。
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:
Last-Modified時間は、リクエストでバリデータとして使用された場合、次のルールを使用して、それが強いと推定できない限り、暗黙的に弱いです。
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 その起点サーバーは、関連するエンティティーが、提示されたバリデーターでカバーされる2番目の間に2回以上変更されなかったことを確実に認識しています。
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 提示されるLast-Modified時間は、Date値の少なくとも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 提示されるLast-Modified時間は、Date値の少なくとも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.
この方法は、同じ秒の間に2つの異なる応答が起点サーバーによって送信されたが、両方のLast-Modified時間が同じであった場合、それらの応答の少なくとも1つは、Last-Modifiedと等しい日付値を持っているという事実に依存します。時間。任意の60秒の制限により、DateとLast-Modifiedの値が異なるクロックから、または応答の準備中に多少異なる時刻に生成される可能性を防ぎます。 60秒が短すぎると考えられる場合、実装は60秒より大きい値を使用してもよい（MAY）。
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.
クライアントがLast-Modified時刻のみを持ち、不透明なバリデーターがない値に対して部分範囲検索を実行する場合、Last-Modified時刻がここで説明する意味で強い場合にのみ、これを実行できます（MAY）。
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 送信可能な場合は、Last-Modified値を送信する必要があります。ただし、この日付をIf-Modified-Sinceヘッダーで使用することにより生じるセマンティックトランスペアレンシーの内訳のリスクが深刻な問題につながる場合を除きます。つまり、RTSPオリジンサーバーの推奨動作は、強力なメッセージ本文タグとLast-Modified値の両方を送信することです。
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.
合法であるためには、関連するエンティティ値が何らかの方法で変更されるたびに、強力なメッセージ本文タグを変更する必要があります。弱いメッセージ本文タグは、関連するエンティティが意味的に重要な方法で変更されるたびに変更する必要があります（SHOULD）。
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.
注：意味的に透過的なキャッシングを提供するために、オリジンサーバーは、2つの異なるエンティティに特定の強いメッセージ本文タグ値を再利用したり、2つの意味的に異なるエンティティに特定の弱いメッセージ本文タグ値を再利用したりしないでください。キャッシュエントリは、有効期限に関係なく、任意の長い期間存続する可能性があるため、キャッシュが過去のある時点で取得したバリデーターを使用してエントリの検証を二度と試みないことを期待するのは不適切な場合があります。
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 オリジンサーバーからLast-Modified値のみが提供されている場合、サブレンジ以外のキャッシュ条件付きリクエストでその値を使用する必要があります（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 オリジンサーバーからメッセージ本文タグとLast-Modified値の両方が提供されている場合、キャッシュ条件付きリクエストで両方のバリデーターを使用する必要があります（SHOULD）。
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, 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.
RTSPオリジンサーバーは、Last-Modified日付（たとえば、If-Modified-Sinceヘッダー内）と1つ以上のメッセージ本文タグ（たとえば、If-Match、If-None-一致、またはキャッシュバリデーターとしてのIf-Rangeヘッダーフィールド）は、リクエストのすべての条件付きヘッダーフィールドと一致しない限り、304（Not Modified）の応答ステータスを返してはなりません（MUST NOT）。
Note: The general principle behind these rules is that RTSP servers and clients should transmit as much non-redundant information as is available in their responses and requests. RTSP systems receiving this information will make the most conservative assumptions about the validators they receive.
注：これらのルールの背後にある一般的な原則は、RTSPサーバーとクライアントは、それらの応答と要求で利用可能な限り多くの非冗長情報を送信する必要があるということです。この情報を受け取るRTSPシステムは、受け取るバリデータについて最も保守的な仮定を行います。
The principle behind message body tags is that only the service author knows the semantics of a resource well enough to select an appropriate cache validation mechanism, and the specification of any validator comparison function more complex than octet equality would open up a can of worms. Thus, comparisons of any other headers are never used for purposes of validating a cache entry.
メッセージ本文タグの背後にある原則は、適切なキャッシュ検証メカニズムを選択するのに十分なリソースのセマンティクスを知っているのはサービス作成者だけであり、オクテットの同等性よりも複雑なバリデーター比較関数の仕様はワームの缶を開くことです。したがって、他のヘッダーの比較は、キャッシュエントリを検証する目的で使用されることはありません。
The effect of certain methods performed on a resource at the origin server might cause one or more existing cache entries to become non-transparently invalid. That is, although they might continue to be "fresh," they do not accurately reflect what the origin server would return for a new request on that resource.
起点サーバーのリソースで実行される特定のメソッドの影響により、1つ以上の既存のキャッシュエントリが透過的に無効になる場合があります。つまり、それらは引き続き「新鮮」である可能性がありますが、そのリソースに対する新しい要求に対してオリジンサーバーが返すものを正確に反映していません。
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メソッドは、キャッシュによってエンティティを無効にする必要があります。これは、Request-URI、またはLocationまたはContent-Locationヘッダー（存在する場合）によって参照されるエンティティです。これらのメソッドは次のとおりです。
o DESCRIBE
o 説明
o SETUP 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.
o セットアップDoS攻撃を防ぐために、LocationまたはContent-LocationヘッダーのURIに基づく無効化は、ホスト部分がRequest-URIと同じである場合にのみ実行する必要があります。
A cache that passes through requests for methods it does not understand SHOULD invalidate any entities referred to by the Request-URI.
理解できないメソッドのリクエストを通過するキャッシュは、Request-URIによって参照されるエンティティを無効にする必要があります（SHOULD）。
Where applicable, HTTP status codes (see Section 6 of [RFC7231]) are reused. See Table 4 in Section 8.1 for a listing of which status codes may be returned by which requests. All error messages, 4xx and 5xx, MAY return a body containing further information about the error.
該当する場合、HTTPステータスコード（[RFC7231]のセクション6を参照）が再利用されます。どの要求によってどのステータスコードが返されるかについては、セクション8.1の表4を参照してください。すべてのエラーメッセージ4xxおよび5xxは、エラーに関する詳細情報を含む本文を返す場合があります。
The requesting agent SHOULD continue with its request. This interim response is used to inform the requesting agent that the initial part of the request has been received and has not yet been rejected by the responding agent. The requesting agent SHOULD continue by sending the remainder of the request or, if the request has already been completed, continue to wait for a final response (see Section 10.4). The responding agent MUST send a final response after the request has been completed.
リクエストしているエージェントは、そのリクエストを続行する必要があります。この暫定応答は、要求の最初の部分が受信され、まだ応答エージェントによって拒否されていないことを要求エージェントに通知するために使用されます。要求側エージェントは、残りの要求を送信して続行する必要があります（SHOULD）。要求がすでに完了している場合は、最終応答を待ち続けます（セクション10.4を参照）。応答エージェントは、要求が完了した後に最終応答を送信する必要があります。
This class of status code indicates that the agent's request was successfully received, understood, and accepted.
このクラスのステータスコードは、エージェントのリクエストが正常に受信され、理解され、受け入れられたことを示します。
The request has succeeded. The information returned with the response is dependent on the method used in the request.
リクエストは成功しました。応答で返される情報は、要求で使用されるメソッドによって異なります。
The notation "3xx" indicates response codes from 300 to 399 inclusive that are meant for redirection. We use the notation "3rr" to indicate all 3xx codes used for redirection, i.e., excluding 304. The 304 response code appears here, rather than a 2xx response code, which would have been appropriate; 304 has also been used in RTSP 1.0 [RFC2326].
「3xx」という表記は、リダイレクト用の300〜399の応答コードを示します。 「3rr」という表記を使用して、リダイレクトに使用されるすべての3xxコードを示します（つまり、304を除く）。ここでは、2xx応答コードではなく、304応答コードが表示されています。 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コードは、あらゆる要求に応答するために使用される場合があります。 Locationヘッダーは、すべての3rr応答に含める必要があります。セッションが確立される前に、つまりDESCRIBEまたはSETUPに応答して、必要に応じて使用することをお勧めします。ただし、サーバーがエージェントにREDIRECTリクエストを送信できない場合、サーバーは3rr応答を使用して、確立されたセッションを持つエージェントに、セッションのリダイレクトの必要性を通知する必要があります（MAY）。確立されたセッションに関連する要求に対して3rr応答が受信された場合、エージェントはセッションのTEARDOWN要求を送信して、ロケーションによって示されるリソースを使用してセッションを再確立する必要があります（SHOULD）。
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.
Locationヘッダーが応答で使用される場合、エージェントがリダイレクトされるメディアリソースを指す絶対URIが含まれている必要があります。 URIにホスト名のみを含めることはできません。
In the event that an unknown 3rr status code is received, the agent SHOULD behave as if a 302 response code had been received (Section 17.3.3).
不明な3rrステータスコードが受信された場合、エージェントは、302応答コードが受信されたかのように動作する必要があります（セクション17.3.3）。
The 300 response code is not used in RTSP 2.0.
300応答コードはRTSP 2.0では使用されません。
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に自動的にリダイレクトする必要があります（SHOULD）。この応答にメッセージ本文を含めることはできません。 Locationヘッダーを応答に含める必要があります。
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に一時的に存在します。この応答は、ロードバランシングなど、多くのタイプの一時的なリダイレクトに使用することを目的としています。これらのケースでは、サーバーが理由フレーズを「検出」よりも意味のあるものに設定することをお勧めします。 Locationヘッダーを応答に含める必要があります。ユーザーエージェントは、指定されたURIに自動的にリダイレクトする必要があります（SHOULD）。この応答にメッセージ本文を含めることはできません。
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
S->C: RTSP/2.0 302 Try Other Server
CSeq: 2
Location: rtsp://s2.example.com:8001/fizzle/foo
This status code MUST NOT be used in RTSP 2.0. However, it was allowed in RTSP 1.0 [RFC2326].
このステータスコードは、RTSP 2.0では使用してはなりません（MUST NOT）。ただし、RTSP 1.0 [RFC2326]では許可されていました。
If the agent has performed a conditional DESCRIBE or SETUP (see Sections 18.25 and 18.26) and the requested resource has not been modified, the server SHOULD send a 304 response. This response MUST NOT contain a message body.
エージェントが条件付きDESCRIBEまたはSETUP（セクション18.25および18.26を参照）を実行し、リクエストされたリソースが変更されていない場合、サーバーは304応答を送信する必要があります（SHOULD）。この応答にメッセージ本文を含めることはできません。
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またはContent-Location（ヘッダーが同じ要求に対する200応答で送信された場合）。
o Expires and Cache-Control if the field-value might differ from that sent in any previous response for the same variant.
o フィールド値が同じバリアントの以前の応答で送信されたものと異なる場合は、ExpiresとCache-Control。
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.
この応答は、DESCRIBE要求とSETUP要求に依存しません。つまり、DESCRIBEへの304応答は、リソースコンテンツが変更されていないことを意味せず（セッション記述のみ）、SETUPへの304応答は、リソース記述が変更されていないことを意味しません。 MTagおよびIf-Matchヘッダー（セクション18.24）を使用して、DESCRIBEとSETUPをこの方法でリンクできます。
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ヘッダーのフィールド値は、プロキシのURIを示します。受信者は、プロキシ経由でこの単一の要求を繰り返すことが期待されています。 305応答は、オリジンサーバーによってのみ生成される必要があります。
The request could not be understood by the agent due to malformed syntax. The agent SHOULD NOT repeat the request without modifications. If the request does not have a CSeq header, the agent MUST NOT include a CSeq in the response.
不正な構文のため、リクエストはエージェントによって理解されませんでした。エージェントは変更なしでリクエストを繰り返すべきではありません。要求にCSeqヘッダーがない場合、エージェントはCSeqを応答に含めてはなりません（MUST NOT）。
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]およびダイジェスト[RFC7616]などの該当するHTTP認証スキームで定義されています。応答には、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダー（セクション18.58）フィールドが含まれます。エージェントは、適切なAuthorizationヘッダーフィールドを使用して要求を繰り返すことができます。リクエストにすでに認証情報が含まれている場合、401レスポンスは、それらの認証情報に対する認証が拒否されたことを示します。 401応答に前の応答と同じチャレンジが含まれていて、ユーザーエージェントが少なくとも1回は認証をすでに試みている場合は、応答で指定されたメッセージ本文をユーザーに提示する必要があります（そのメッセージ本文には関連する診断情報が含まれる可能性があるため） 。
This code is reserved for future use.
このコードは将来の使用のために予約されています。
The agent understood the request, but is refusing to fulfill it. Authorization will not help, and the request SHOULD NOT be repeated. If the agent wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the message body. If the agent does not wish to make this information available to the agent, the status code 404 (Not Found) can be used instead.
エージェントは要求を理解しましたが、それを満たすことを拒否しています。承認は役に立たず、リクエストは繰り返されるべきではありません。エージェントがリクエストが履行されなかった理由を公表したい場合は、拒否の理由をメッセージ本文に記述してください。エージェントがこの情報をエージェントに提供したくない場合は、代わりにステータスコード404（見つかりません）を使用できます。
The agent has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the agent knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.
エージェントは、Request-URIに一致するものを見つけられませんでした。状態が一時的であるか永続的であるかは示されません。 410（Gone）ステータスコードは、古いリソースが永続的に利用できず、転送アドレスがないことをエージェントが内部で設定可能なメカニズムを介して知っている場合に使用する必要があります（SHOULD）。
This status code is commonly used when the agent does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
このステータスコードは、エージェントがリクエストが拒否された理由を正確に明らかにしたくない場合、または他の応答が該当しない場合に一般的に使用されます。
The method specified in the request is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource. This status code is also to be used if a request attempts to use a method not indicated during SETUP.
リクエストで指定されたメソッドは、Request-URIで識別されるリソースでは許可されていません。応答には、要求されたリソースの有効なメソッドのリストを含むAllowヘッダーを含める必要があります。このステータスコードは、セットアップ中に示されていないメソッドを要求が使用しようとした場合にも使用されます。
The resource identified by the request is only capable of generating response message bodies that have content characteristics not acceptable according to the Accept headers sent in the request.
要求によって識別されたリソースは、要求で送信されたAcceptヘッダーに従って受け入れられないコンテンツ特性を持つ応答メッセージ本文を生成することのみ可能です。
The response SHOULD include a message body containing a list of available message body characteristics and location(s) from which the user or user agent can choose the one most appropriate. The message body format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.
応答には、ユーザーまたはユーザーエージェントが最も適切なものを選択できる、利用可能なメッセージ本文の特性と場所のリストを含むメッセージ本文が含まれる必要があります（SHOULD）。メッセージ本文の形式は、Content-Typeヘッダーフィールドで指定されたメディアタイプによって指定されます。ユーザーエージェントの形式と機能に応じて、最も適切な選択肢の選択が自動的に実行される場合があります。ただし、この仕様では、このような自動選択の標準を定義していません。
If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.
応答が受け入れられない可能性がある場合、ユーザーエージェントは、追加のデータの受信を一時的に停止し、ユーザーにクエリを実行して、その後のアクションの決定を求めます。
This code is similar to 401 (Unauthorized) (Section 17.4.2), but it indicates that the client must first authenticate itself with the proxy. The usage of this error code is defined in [RFC7235] and any applicable HTTP authentication scheme, such as Digest [RFC7616]. The proxy MUST return a Proxy-Authenticate header field (Section 18.34) containing a challenge applicable to the proxy for the requested resource.
このコードは401（無許可）（17.4.2項）に似ていますが、クライアントが最初にプロキシで自身を認証する必要があることを示しています。このエラーコードの使用法は、[RFC7235]およびダイジェスト[RFC7616]などの該当するHTTP認証スキームで定義されています。プロキシは、要求されたリソースのプロキシに適用可能なチャレンジを含むProxy-Authenticateヘッダーフィールド（セクション18.34）を返す必要があります。
The agent did not produce a request within the time that the agent was prepared to wait. The agent MAY repeat the request without modifications at any later time.
エージェントは、エージェントが待機する準備ができている時間内に要求を生成しませんでした。エージェントは、いつでも変更なしでリクエストを繰り返すことができます。
The requested resource is no longer available at the server and the forwarding address is not known. This condition is expected to be considered permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.
要求されたリソースはサーバーで使用できなくなり、転送アドレスは不明です。この状態は永続的であると考えられています。サーバーが状態が永続的であるかどうかを判断できない、または判断する機能がない場合は、代わりにステータスコード404（見つかりません）を使用する必要があります（SHOULD）。特に指定のない限り、この応答はキャッシュ可能です。
The 410 response is primarily intended to assist the task of repository maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the owner of the server.
410応答は主に、リソースが意図的に使用不可であること、およびサーバー所有者がそのリソースへのリモートリンクを削除することを望んでいることを受信者に通知することにより、リポジトリメンテナンスのタスクを支援することを目的としています。このようなイベントは、期間限定のプロモーションサービスや、サーバーのサイトで働いていない個人が所有するリソースに共通です。永久に利用できないリソースをすべて「存在しない」としてマークしたり、マークを任意の期間保持したりする必要はありません。サーバーの所有者の裁量に任されています。
The precondition given in one or more of the 'if-' request-header fields evaluated to false when it was tested on the agent. See these sections for the 'if-' headers: If-Match Section 18.24, If-Modified-Since Section 18.25, and If-None-Match Section 18.26. This response code allows the agent to place preconditions on the current resource meta-information (header field data) and, thus, prevent the requested method from being applied to a resource other than the one intended.
1つ以上の「if-」リクエストヘッダーフィールドに指定された前提条件が、エージェントでテストされたときにfalseと評価されました。 「if-」ヘッダーについては、以下のセクションを参照してください。If-Matchセクション18.24、If-Modified-Sinceセクション18.25、およびIf-None-Matchセクション18.26。この応答コードにより、エージェントは現在のリソースメタ情報（ヘッダーフィールドデータ）に前提条件を設定できるため、要求されたメソッドが意図したもの以外のリソースに適用されるのを防ぐことができます。
The agent is refusing to process a request because the request message body is larger than the agent is willing or able to process. The agent MAY close the connection to prevent the requesting agent from continuing the request.
リクエストメッセージの本文がエージェントが処理できるか、または処理できるよりも大きいため、エージェントはリクエストの処理を拒否しています。エージェントは接続を閉じて、要求側エージェントが要求を続行できないようにする場合があります。
If the condition is temporary, the agent SHOULD include a Retry-After header field to indicate that it is temporary and after what time the requesting agent MAY try again.
条件が一時的なものである場合、エージェントはRetry-Afterヘッダーフィールドを含めて、それが一時的なものであること、および要求したエージェントが何時間後に再試行するかを示す必要があります。
The responding agent is refusing to service the request because the Request-URI is longer than the agent is willing to interpret. This rare condition is only likely to occur when an agent has used a request with long query information, when the agent has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the agent is under attack by an agent attempting to exploit security holes present in some agents using fixed-length buffers for reading or manipulating the Request-URI.
要求URIがエージェントが解釈するよりも長いため、応答エージェントは要求の処理を拒否しています。このまれな状態が発生する可能性が高いのは、エージェントが長いクエリ情報を含むリクエストを使用し、エージェントがリダイレクトのURI「ブラックホール」（たとえば、自身のサフィックスを指すリダイレクトされたURIプレフィックス）に到達した場合のみです。または、エージェントが、Request-URIの読み取りまたは操作に固定長バッファーを使用する一部のエージェントに存在するセキュリティホールを悪用しようとする攻撃を受けている場合。
The server is refusing to service the request because the message body of the request is in a format not supported by the requested resource for the requested method.
リクエストのメッセージ本文が、リクエストされたメソッドのリクエストされたリソースでサポートされていない形式であるため、サーバーはリクエストの処理を拒否しています。
The recipient of the request does not support one or more parameters contained in the request. When returning this error message the agent SHOULD return a message body containing the offending parameter(s).
リクエストの受信者は、リクエストに含まれる1つ以上のパラメータをサポートしていません。このエラーメッセージを返すとき、エージェントは問題のあるパラメータを含むメッセージ本文を返す必要があります（SHOULD）。
This status code MUST NOT be used in RTSP 2.0. However, it was allowed in RTSP 1.0 [RFC2326].
このステータスコードは、RTSP 2.0では使用してはなりません（MUST NOT）。ただし、RTSP 1.0 [RFC2326]では許可されていました。
The request was refused because there was insufficient bandwidth. This may, for example, be the result of a resource reservation failure.
帯域幅が不足していたため、要求は拒否されました。これは、たとえば、リソース予約の失敗の結果である可能性があります。
The RTSP session identifier in the Session header is missing, is invalid, or has timed out.
セッションヘッダーのRTSPセッションIDがないか、無効であるか、タイムアウトしました。
The agent cannot process this request in its current state. The response MUST contain an Allow header to make error recovery possible.
エージェントは、現在の状態ではこの要求を処理できません。エラーの回復を可能にするために、応答にはAllowヘッダーが含まれている必要があります。
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.
ターゲットエージェントは、必要なリクエストヘッダーを処理できませんでした。たとえば、PLAYリクエストにRangeヘッダーフィールドが含まれているが、ストリームがシークを許可していない場合。このエラーメッセージは、範囲内の時刻形式がリソースに対して不可能である場合を指定するためにも使用できます。その場合、どのフォーマットが許可されているかをエージェントに通知するためにAccept-Rangesヘッダーを返さなければなりません（MUST）。
The Range value given is out of bounds, e.g., beyond the end of the presentation.
指定された範囲値が範囲外です。たとえば、プレゼンテーションの終わりを超えています。
The parameter to be set by SET_PARAMETER can be read but not modified. When returning this error message, the sender SHOULD return a message body containing the offending parameter(s).
SET_PARAMETERによって設定されるパラメーターは読み取ることはできますが、変更することはできません。このエラーメッセージを返すとき、送信者は問題のパラメータを含むメッセージ本文を返す必要があります（SHOULD）。
The requested method may not be applied on the URI in question since it is an aggregate (presentation) URI. The method may be applied on a media URI.
要求されたメソッドは集約（プレゼンテーション）URIであるため、問題のURIに適用されない可能性があります。このメソッドは、メディアURIに適用できます。
The requested method may not be applied on the URI in question since it is not an aggregate control (presentation) URI. The method may be applied on the aggregate control URI.
要求されたメソッドは、集約コントロール（プレゼンテーション）URIではないため、問題のURIに適用されない場合があります。このメソッドは、集約コントロールURIに適用できます。
The Transport field did not contain a supported transport specification.
Transportフィールドには、サポートされているトランスポート仕様が含まれていませんでした。
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.
エージェントのアドレスに到達できなかったため、データ伝送チャネルを確立できませんでした。このエラーは、エージェントがTransportフィールドに無効なdest_addrパラメータを配置しようとした結果である可能性が高いです。
The data transmission channel was not established because the server prohibited access to the agent address. This error is most likely the result of an agent attempt to redirect media traffic to another destination with a dest_addr parameter in the Transport header.
サーバーがエージェントのアドレスへのアクセスを禁止したため、データ伝送チャネルは確立されませんでした。このエラーは、トランスポートヘッダーのdest_addrパラメータを使用して、エージェントがメディアトラフィックを別の宛先にリダイレクトしようとした結果である可能性が高いです。
The data transmission channel to the media destination is not yet ready for carrying data. However, the responding agent still expects that the data transmission channel will be established at some point in time. Note, however, that this may result in a permanent failure like 462 (Destination Unreachable).
メディア宛先へのデータ伝送チャネルは、まだデータを伝送する準備ができていません。ただし、応答エージェントは、データ送信チャネルがいずれかの時点で確立されることを期待しています。ただし、これにより462（Destination Unreachable）などの永続的な障害が発生する可能性があることに注意してください。
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接続が（この仕様に違反して）正常に確立されたことを確認する前に、クライアントがサーバーにPLAY要求を送信する場合です。サーバーはこのエラーコードを使用して、接続の確立の完了に失敗したため、要求されたアクションを実行できなかったことを示します。
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.
これは、クライアントがクライアントに不明なNotify-Reasonヘッダー（セクション18.32）を含むPLAY_NOTIFY（セクション13.5）を受信したことを示しています。
This indicates that there has been an error in a Key Management function used in conjunction with a request. For example, usage of Multimedia Internet KEYing (MIKEY) [RFC3830] according to Appendix C.1.4.1 may result in this error.
これは、リクエストと組み合わせて使用されるキー管理機能にエラーがあったことを示しています。たとえば、付録C.1.4.1に従ってマルチメディアインターネットキーイング（MIKEY）[RFC3830]を使用すると、このエラーが発生する可能性があります。
The secured connection attempt needs user or client authorization before proceeding. The next hop's certificate is included in this response in the Accept-Credentials header.
保護された接続の試行には、続行する前にユーザーまたはクライアントの承認が必要です。ネクストホップの証明書は、この応答のAccept-Credentialsヘッダーに含まれています。
When performing a secure connection over multiple connections, an intermediary has refused to connect to the next hop and carry out the request due to unacceptable credentials for the used policy.
複数の接続を介して安全な接続を実行する場合、使用されたポリシーの資格情報が受け入れられないため、仲介者が次のホップに接続してリクエストを実行することを拒否しました。
A proxy fails to establish a secure connection to the next-hop RTSP agent. This is primarily caused by a fatal failure at the TLS handshake, for example, due to the agent not accepting any cipher suites.
プロキシがネクストホップRTSPエージェントへの安全な接続を確立できません。これは主に、TLSハンドシェイクでの致命的な障害が原因です。たとえば、エージェントが暗号スイートを受け入れないことが原因です。
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. The server SHOULD include a message body containing an explanation of the error situation and whether it is a temporary or permanent condition. User agents SHOULD display any included message body to the user. These response codes are applicable to any request method.
数字「5」で始まる応答ステータスコードは、サーバーがエラーを検出したか、要求を実行できないことをサーバーが認識している場合を示します。サーバーは、エラー状況の説明と、それが一時的な状態か永続的な状態かを含むメッセージ本文を含める必要があります（SHOULD）。ユーザーエージェントは、含まれているメッセージ本文をユーザーに表示する必要があります（SHOULD）。これらの応答コードは、すべての要求メソッドに適用できます。
The agent encountered an unexpected condition that prevented it from fulfilling the request.
エージェントが予期しない状態に遭遇したため、要求を実行できませんでした。
The agent does not support the functionality required to fulfill the request. This is the appropriate response when the agent does not recognize the request method and is not capable of supporting it for any resource.
エージェントは、要求を満たすために必要な機能をサポートしていません。これは、エージェントが要求メソッドを認識せず、どのリソースに対してもそれをサポートできない場合の適切な応答です。
The agent, while acting as a gateway or proxy, received an invalid response from the upstream agent it accessed in attempting to fulfill the request.
エージェントは、ゲートウェイまたはプロキシとして機能しているときに、要求を満たすためにアクセスした上流のエージェントから無効な応答を受け取りました。
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition that will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the agent SHOULD handle the response as it would for a 500 response. The agent MUST honor the length, if given, in the Retry-After header.
サーバーの一時的な過負荷またはメンテナンスのため、サーバーは現在リクエストを処理できません。これは、これが一時的な状態であり、しばらくすると緩和されることを意味しています。既知の場合、遅延の長さはRetry-Afterヘッダーで示される場合があります。 Retry-Afterが指定されていない場合、エージェントは500応答の場合と同様に応答を処理する必要があります（SHOULD）。エージェントは、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セッションを形成することを意図していない場合、リクエストは、Request-URIのホスト名で識別されるRTSPサーバーに適用されます。
The agent, while acting as a proxy, did not receive a timely response from the upstream agent specified by the URI or some other auxiliary server (e.g., DNS) that it needed to access in attempting to complete the request.
エージェントは、プロキシとして機能しているときに、URIまたは他の補助サーバー（DNSなど）で指定されたアップストリームエージェントから、リクエストを完了するためにアクセスする必要があるタイムリーな応答を受け取りませんでした。
The agent does not support, or refuses to support, the RTSP version that was used in the request message. The agent is indicating that it is unable or unwilling to complete the request using the same major version as the agent other than with this error message. The response SHOULD contain a message body describing why that version is not supported and what other protocols are supported by that agent.
エージェントは、要求メッセージで使用されたRTSPバージョンをサポートしないか、サポートを拒否します。エージェントは、このエラーメッセージ以外では、エージェントと同じメジャーバージョンを使用してリクエストを完了できない、または実行したくないことを示しています。応答には、そのバージョンがサポートされていない理由と、そのエージェントがサポートしている他のプロトコルを説明するメッセージ本文が含まれている必要があります（SHOULD）。
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フィールドで指定された機能タグはサポートされていませんでした。 Unsupportedヘッダーは、サポートされていない機能を示すために返される必要があります。
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ヘッダーで示される場合があります。 Retry-Afterが指定されていない場合、エージェントは500応答の場合と同様に応答を処理する必要があります（SHOULD）。エージェントは、Retry-Afterヘッダーで指定されている場合、長さを尊重する必要があります。
Note: The existence of the 553 status code does not imply that a proxy must use it when becoming overloaded. Some proxies may wish to simply refuse the connection.
注：553ステータスコードの存在は、過負荷状態になったときにプロキシがそれを使用する必要があることを意味するものではありません。一部のプロキシは単に接続を拒否したい場合があります。
The response scope is dependent on the Request. If the request was in relation to an existing RTSP session, the scope of the overload response is to this individual RTSP session. If the request was non-session specific or intended to form an RTSP session, it applies to all such requests to this proxy.
応答スコープはリクエストに依存します。要求が既存のRTSPセッションに関連していた場合、過負荷応答の範囲はこの個々のRTSPセッションです。要求が非セッション固有であるか、RTSPセッションを形成することを意図していた場合、それはこのプロキシへのそのようなすべての要求に適用されます。
+---------------+----------------+--------+---------+------+
| method | direction | object | acronym | Body |
+---------------+----------------+--------+---------+------+
| DESCRIBE | C -> S | P,S | DES | r |
| | | | | |
| GET_PARAMETER | C -> S, S -> C | P,S | GPR | R,r |
| | | | | |
| OPTIONS | C -> S, S -> C | P,S | OPT | |
| | | | | |
| PAUSE | C -> S | P,S | PSE | |
| | | | | |
| PLAY | C -> S | P,S | PLY | |
| | | | | |
| PLAY_NOTIFY | S -> C | P,S | PNY | R |
| | | | | |
| REDIRECT | S -> C | P,S | RDR | |
| | | | | |
| SETUP | C -> S | S | STP | |
| | | | | |
| SET_PARAMETER | C -> S, S -> C | P,S | SPR | R,r |
| | | | | |
| TEARDOWN | C -> S | P,S | TRD | |
| | | | | |
| | S -> C | P | TRD | |
+---------------+----------------+--------+---------+------+
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：プレゼンテーション、S：ストリーム）の概要です。 「ボディ」は、メソッドがボディを運ぶことを許可されているかどうか、およびその方向を示します。 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」列は、ヘッダーフィールドを使用できるリクエストとレスポンスのタイプを示しています。この列の値は次のとおりです。
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：ヘッダーフィールドは一般的なヘッダーであり、要求と応答の両方に存在する場合があります。
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」値が常に使用されるとは限りません。これは、ヘッダーが応答と比較してリクエストに適用される場合の違いによるものです。このような違いがある場合、それらは2つの異なる行を使用して表されます。1つは「where」が「R」で、もう1つは「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.
a：存在しない場合、プロキシはヘッダーフィールドを追加または連結できます。
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 *：ヘッダーフィールドを送信する必要があります（SHOULD）が、エージェントはそのヘッダーフィールドなしでメッセージを受信できるように準備する必要があります。
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ヘッダーフィールドです。 「必須」のヘッダーフィールドはリクエストに存在する必要があり、リクエストを受信するエージェントが理解する必要があります。必須の応答ヘッダーフィールドが応答に存在する必要があり、ヘッダーフィールドは応答の処理によって理解されなければなりません（MUST）。 「該当なし」は、ヘッダーフィールドがリクエストに存在してはならないことを意味します。誤ってリクエストに配置された場合、リクエストを受信するエージェントはそれを無視する必要があります。同様に、応答に「該当なし」というラベルの付いたヘッダーフィールドは、エージェントが応答にヘッダーフィールドを配置してはならず（MUST NOT）、エージェントは応答のヘッダーフィールドを無視しなければならない（MUST）ことを意味します。
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.
FromおよびLocationヘッダーフィールドには、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 | - | - | - |
| 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：メソッドDESCRIBE、OPTIONS、SETUP、PLAY、PAUSE、およびTEARDOWNに関連する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* |
| 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：メソッドDESCRIBE、OPTIONS、SETUP、PLAY、PAUSE、およびTEARDOWNに関連する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 | - | - | - |
| 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_PARAMETER、SET_PARAMETER、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 |
| 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_PARAMETER、SET_PARAMETER、REDIRECT、およびPLAY_NOTIFYに関連するRTSPヘッダーフィールド（M-W）の概要
The Accept request-header field can be used to specify certain presentation description and parameter media types [RFC6838] that are acceptable for the response to the DESCRIBE request.
Accept request-headerフィールドを使用して、DESCRIBE要求への応答に受け入れられる特定のプレゼンテーションの説明とパラメータメディアタイプ[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.
各メディアタイプまたは範囲の後には、1つ以上のaccept-paramsが続く場合があり、「q」パラメータで始まり、相対的な品質係数を示します。最初の「q」パラメーター（存在する場合）は、メディアタイプまたは範囲のパラメーターをaccept-paramsから分離します。品質係数により、ユーザーまたはユーザーエージェントは、0から1までのqvalueスケールを使用して、そのメディアタイプの相対的な優先度を示すことができます（[RFC7231]のセクション5.3.1）。デフォルト値はq = 1です。
Example of use:
使用例：
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（Not Acceptable）応答を送信する必要があります（SHOULD）。
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".
リクエストのヘッダーには、リクエスト元が選択した認証情報を承認するためのメソッド（ユーザー、プロキシ、または任意）が含まれている必要があります。プロキシがそれを「ユーザー」に変更して、各ホップを承認するユーザーの役割を担うことができる「プロキシ」である場合を除いて、メソッドはどのプロキシによっても変更してはなりません（MUST NOT）。メソッドが「ユーザー」の場合、ヘッダーには、クライアントが受け入れる資格情報が0個以上含まれます。 「ユーザー」メソッドを使用する場合、プロキシを介したRTSPサーバーへの最初のRTSPリクエストには、ヘッダーの認証情報が含まれない場合があります。これは、クライアントが受け入れる資格情報をまだ受け取っていないためです。 [RFC4648]のセクション4に従い、プロキシまたはサーバーを識別する1つのURI、ハッシュアルゴリズム識別子、およびそのエージェントのASN.1 DERエンコード証明書[RFC5280]のハッシュをBase64で構成する必要があります。ゼロに設定されます。すべてのRTSPクライアントとプロキシは、DERエンコードされた証明書のハッシュを計算するためにSHA-256 [FIPS180-4]アルゴリズムを実装する必要があります。 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=
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リクエストヘッダーフィールドはAcceptに似ていますが、コンテンツコーディング（セクション18.15を参照）、つまり、応答で許容されるgzip圧縮などのメッセージ本文の変換コーディングを制限します。
A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules:
サーバーは、Accept-Encodingフィールドに従って、次のルールを使用して、コンテンツコーディングが許容可能かどうかをテストします。
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. content-codingがAccept-Encodingフィールドにリストされているcontent-codingの1つである場合、qvalueが0を伴わない限り許容されます（[RFC7231]のセクション5.3.1で定義されているように、qvalue 0は「受け入れられない」を意味します。）
2. The special "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header field.
2. Accept-Encodingフィールドの特別な「*」記号は、ヘッダーフィールドに明示的にリストされていない使用可能なcontent-codingと一致します。
3. If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.
3. 複数のコンテンツコーディングが許容できる場合、ゼロ以外のqvalueが最も高い許容可能なコンテンツコーディングが優先されます。
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. Accept-Encodingフィールドに "identity; q = 0"が含まれているため、またはフィールドに "*; q = 0"が含まれているために特別に拒否されない限り、 "identity"コンテンツコーディングは常に許容されます。つまり、まったく変換されません。 「ID」コンテンツコーディングを明示的に含めます。 Accept-Encodingフィールド値が空の場合、「ID」エンコーディングのみが受け入れられます。
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.
Accept-Encodingフィールドがリクエストに存在し、サーバーがAccept-Encodingヘッダーに従って受け入れ可能な応答を送信できない場合、サーバーは406（Not Acceptable）ステータスコードを含むエラー応答を送信する必要があります（SHOULD）。
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.
Accept-Encodingフィールドがリクエストに存在しない場合、サーバーはクライアントがコンテンツコーディングを受け入れると想定してもよい（MAY）。この場合、「アイデンティティ」が利用可能なコンテンツコーディングの1つである場合、サーバーは、「アイデンティティ」コンテンツコーディングを使用する必要があります（別のコンテンツコーディングがクライアントにとって意味があるという追加情報がない場合）。
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リクエストヘッダーフィールドは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:
各言語範囲には、その範囲で指定された言語に対するユーザーの好みの推定値を表す、関連する品質値を与えることができます（MAY）。品質値のデフォルトは「q = 1」です。例えば：
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ヘッダーが存在しない場合、サーバーはすべての言語が同等に受け入れ可能であると想定する必要があります（SHOULD）。 Accept-Languageヘッダーが存在する場合、0より大きい修飾係数が割り当てられているすべての言語が受け入れ可能です。
The Accept-Ranges general-header field allows indication of the format supported in the Range header. The client MUST include the header in SETUP requests to indicate which formats are acceptable when received in PLAY and PAUSE responses and REDIRECT requests. The server MUST include the header in SETUP responses and 456 (Header Field Not Valid for Resource) error responses to indicate the formats supported for the resource indicated by the Request-URI. The header MAY be included in GET_PARAMETER request and response pairs. The GET_PARAMETER request MUST contain a Session header to identify the session context the request is related to. The requester and responder will indicate their capabilities regarding Range formats respectively.
Accept-Ranges general-headerフィールドでは、Rangeヘッダーでサポートされている形式を示すことができます。クライアントはSETUPリクエストにヘッダーを含めて、PLAYおよびPAUSE応答とREDIRECTリクエストで受信したときに受け入れ可能な形式を示す必要があります。サーバーはSETUP応答にヘッダーを含めなければならず（MUST）、456（Header Field Not Valid for Resource）エラー応答は、Request-URIで示されるリソースでサポートされる形式を示します。ヘッダーは、GET_PARAMETERリクエストとレスポンスのペアに含まれる場合があります。 GET_PARAMETERリクエストには、リクエストが関連するセッションコンテキストを識別するためのセッションヘッダーが含まれている必要があります。リクエスターとレスポンダーは、それぞれ範囲フォーマットに関する機能を示します。
Accept-Ranges: npt, smpte, clock
Accept-Ranges：npt、smpte、clock
The syntax is defined in Section 20.2.3.
構文はセクション20.2.3で定義されています。
The Allow message body header field lists the methods supported by the resource identified by the Request-URI. The purpose of this field is to inform the recipient of the complete set of valid methods associated with the resource. An Allow header field MUST be present in a 405 (Method Not Allowed) response. The Allow header MUST also be present in all OPTIONS responses where the content of the header will not include exactly the same methods as listed in the Public header.
[Allow message body header]フィールドには、Request-URIで識別されるリソースがサポートするメソッドが一覧表示されます。このフィールドの目的は、リソースに関連付けられた有効なメソッドの完全なセットを受信者に通知することです。 Allowヘッダーフィールドは、405（Method Not Allowed）応答に存在する必要があります。 Allowヘッダーは、すべてのOPTIONS応答にも存在する必要があり、ヘッダーのコンテンツには、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.
リソースに許可されているメソッドがこのメモで定義されているメソッドの完全なセットと異なる場合、Allowメッセージ本文のヘッダーもSETUPおよびDESCRIBE応答に含める必要があります。
Example of use:
使用例：
Allow: SETUP, PLAY, SET_PARAMETER, DESCRIBE
許可：SETUP、PLAY、SET_PARAMETER、DESCRIBE
The Authentication-Info response-header is used by the server to communicate some information regarding the successful HTTP authentication [RFC7235] in the response message. The definition of the header is in [RFC7615], and any applicable HTTP authentication schemes appear in other RFCs, such as Digest [RFC7616]. This header MUST only be used in response messages related to client to server requests.
Authentication-Info応答ヘッダーは、応答メッセージで成功したHTTP認証[RFC7235]に関する情報を通信するためにサーバーによって使用されます。ヘッダーの定義は[RFC7615]にあり、適用可能なHTTP認証スキームは、ダイジェスト[RFC7616]などの他のRFCに記載されています。このヘッダーは、クライアントからサーバーへの要求に関連する応答メッセージでのみ使用する必要があります。
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
HTTPからの認証メカニズム[RFC7235]を使用してサーバーで自身を認証することを望むRTSPクライアントは、通常（必ずというわけではありませんが）、401応答を受け取った後、リクエストにAuthorizationリクエストヘッダーフィールドを含めることで認証します。 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認証スキームは、ダイジェスト[RFC7616]や基本[RFC7617]などの他のRFCに記載されています。このヘッダーは、クライアントからサーバーへのリクエストでのみ使用する必要があります。
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.
リクエストが認証され、レルムが指定されている場合、同じクレデンシャルはこのレルム内の他のすべてのリクエストに対して有効である必要があります（チャレンジ値によって異なるクレデンシャルや同期クロックを使用するクレデンシャルなど、認証スキーム自体はそれ以外は必要ないと想定） 。情報とともにAuthorizationヘッダーを含めることにより、クライアントからサーバーへの各要求を個別に承認する必要があります。
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を参照）がAuthorizationフィールドを含むリクエストを受け取った場合、次の特定の例外のいずれかが当てはまらない限り、対応するレスポンスを他のリクエストへの応答として返してはなりません（MUST NOT）。
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」キャッシュディレクティブが含まれている場合、キャッシュは後続の要求への応答にその応答を使用できます（MAY）。ただし、（指定された最大経過時間が経過した場合）プロキシキャッシュは、最初にオリジンサーバーで再検証し、新しいリクエストのリクエストヘッダーを使用して、オリジンサーバーが新しいリクエストを認証できるようにする必要があります。 （これは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. 応答に「must-revalidate」キャッシュ制御ディレクティブが含まれている場合、キャッシュは後続の要求への応答にその応答を使用できます（MAY）。ただし、応答が古くなっている場合は、すべてのキャッシュが最初にオリジンサーバーでそれを再検証し、新しいリクエストのリクエストヘッダーを使用して、オリジンサーバーが新しいリクエストを認証できるようにする必要があります。
3. If the response includes the "public" cache directive, it MAY be returned in reply to any subsequent request.
3. 応答に「パブリック」キャッシュディレクティブが含まれている場合、後続の要求への応答として返される場合があります。
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.
Bandwidth request-headerフィールドは、正の整数で表され、キロビット/秒で測定された、クライアントが使用できる推定帯域幅を示します。 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 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.
たとえば、最初のホップはボトルネックではないため、クライアントは使用可能な帯域幅を正確に決定できない場合があります。このようなケースは、サーバーが同じLAN内にない場合、ローカルエリアネットワーク（LAN）がボトルネックではなく、LANのインターネットアクセスリンクがボトルネックになっている場合です。したがって、WLANまたはイーサネットネットワークのリンク速度は、通常、使用可能な帯域幅を推定するための基礎にはなりません。セルラーデバイスまたはモデムまたは接続対応デバイスに直接接続されているその他のデバイスは、ボトルネックの帯域幅と、RTSPで制御されたメディアのそれに対する妥当なシェアをより正確に推定できます。クライアントは、ボトルネックを共有している他のトラフィックも考慮する必要があります。たとえば、RTSPとそのメディアストリームに特定の割合を割り当てるだけです。帯域幅のボトルネックに関する正確かつ明示的な情報を持つクライアントのみがこのヘッダーを使用することをお勧めします。
This header is not a substitute for proper congestion control. It is only a method providing an initial estimate and coarsely determines if the selected content can be delivered at all.
このヘッダーは、適切な輻輳制御の代わりにはなりません。これは、初期の見積もりを提供する方法にすぎず、選択したコンテンツをまったく配信できるかどうかを大まかに決定します。
Example:
例：
Bandwidth: 62360
帯域幅：62360
The Blocksize request-header field is sent from the client to the media server asking the server for a particular media packet size. This packet size does not include lower-layer headers such as IP, UDP, or RTP. The server is free to use a blocksize that is lower than the one requested. The server MAY truncate this packet size to the closest multiple of the minimum, media-specific block size or override it with the media-specific size, if necessary. The block size MUST be a positive decimal number measured in octets. The server only returns an error (4xx) if the value is syntactically invalid.
Blocksizeリクエストヘッダーフィールドは、クライアントからメディアサーバーに送信され、サーバーに特定のメディアパケットサイズを要求します。このパケットサイズには、IP、UDP、RTPなどの下位層ヘッダーは含まれません。サーバーは、要求されたブロックサイズよりも小さいブロックサイズを自由に使用できます。サーバーは、必要に応じて、このパケットサイズをメディア固有の最小ブロックサイズの最も近い倍数に切り捨てるか、メディア固有のサイズでオーバーライドできます。ブロックサイズは、オクテットで測定された正の10進数である必要があります。値が構文的に無効な場合のみ、サーバーはエラー（4xx）を返します。
The Cache-Control general-header field is used to specify directives that MUST be obeyed by all caching mechanisms along the request/ response chain.
Cache-Control general-headerフィールドは、要求/応答チェーンに沿ったすべてのキャッシングメカニズムに従う必要があるディレクティブを指定するために使用されます。
Cache directives MUST be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives may be applicable to all recipients along the request/response chain. It is not possible to specify a cache-directive for a specific cache.
ディレクティブは要求/応答チェーン上のすべての受信者に適用できるため、キャッシュディレクティブは、そのアプリケーションに対する重要性に関係なく、プロキシまたはゲートウェイアプリケーションによってパススルーされる必要があります。特定のキャッシュにcache-directiveを指定することはできません。
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 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.
Cache-Controlは、DESCRIBE、GET_PARAMETER、SET_PARAMETER、およびSETUP要求とその応答でのみ指定する必要があります。注：Cache-Controlは、RTSPメッセージの応答のキャッシュのみを管理するのではなく、SETUP要求によって識別されるメディアストリームにも適用されます。 RTSP要求は通常、キャッシュできません。詳細については、セクション16を参照してください。以下は、Cache-Controlヘッダーに含めることができるキャッシュディレクティブの説明です。
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.
no-cache：メディアストリームまたはRTSP応答がどこにもキャッシュされてはならないことを示します。これにより、オリジンサーバーは、クライアント要求に対して古い応答を返すように構成されているキャッシュによっても、キャッシュを防止できます。注：コンテンツのキャッシュを妨げるセキュリティ機能はありません。
public: Indicates that the media stream or RTSP response is cacheable by any cache.
public：メディアストリームまたは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.
private：メディアストリームまたは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.
no-transform：中間キャッシュ（プロキシ）では、特定のストリームのメディアタイプを変換すると便利な場合があります。たとえば、プロキシはビデオ形式を変換して、キャッシュスペースを節約したり、低速リンクのトラフィック量を削減したりできます。ただし、これらの変換が特定の種類のアプリケーション向けのストリームに適用された場合、深刻な運用上の問題が発生する可能性があります。たとえば、医用画像処理、科学データ分析、およびエンドツーエンド認証を使用するアプリケーションはすべて、元のメディアストリームまたはRTSP応答とビットごとに同一のストリームを受信することに依存しています。したがって、応答にno-transformディレクティブが含まれている場合、中間キャッシュまたはプロキシは、ストリームまたは応答のエンコーディングを変更してはなりません（MUST NOT）。 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.
only-if-cached：非常に貧弱なネットワーク接続の場合など、場合によっては、クライアントはキャッシュに、現在格納されているメディアストリームまたはRTSP応答のみを返し、配信元サーバーからこれらを受信しないようにすることがあります。これを行うために、クライアントはリクエストにonly-if-cachedディレクティブを含めることができます。キャッシュがこのディレクティブを受信した場合、キャッシュされたメディアストリームまたは要求の他の制約と一致する応答を使用して応答するか、504（ゲートウェイタイムアウト）ステータスで応答する必要があります（SHOULD）。ただし、キャッシュのグループが内部接続が良好な統合システムとして運用されている場合、そのような要求はそのキャッシュのグループ内で転送される場合があります。
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に値が割り当てられていない場合、クライアントは任意の年齢の古い応答を受け入れてもかまいません。
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.
must-revalidate：キャッシュが受信したSETUP応答にmust-revalidateディレクティブが存在する場合、そのキャッシュは、古くなった後、最初にオリジンサーバーで再検証せずに後続のリクエストに応答するためにキャッシュエントリを使用してはなりません（MUST NOT）。つまり、元のサーバーのExpiresのみに基づいてキャッシュされた応答が古くなっている場合は、毎回エンドツーエンドの再検証を行う必要があります。
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ディレクティブと同じ意味です。これは、認証された要求への応答で使用して、ユーザーのキャッシュに保存し、後で再検証する必要なく応答を返すことができます（既にそのユーザーによって一度認証されているため）一方で、多くのユーザーにサービスを提供するプロキシを必要とします毎回再検証します（各ユーザーが認証されていることを確認するため）。そのような認証された応答は、それらがまったくキャッシュされることを可能にするために、「パブリック」キャッシュディレクティブも必要とすることに注意してください。
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, 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）応答でクライアントに返すことができます。ただし、サーバーが新しいメッセージ本文とキャッシュバリデータで応答した場合、中間キャッシュは、強力な比較関数を使用して、返されたバリデータをクライアントのリクエストで提供されたバリデータと比較できます。クライアントのバリデーターがオリジンサーバーのバリデーターと等しい場合、中間キャッシュは単に304（Not Modified）を返します。それ以外の場合は、200（OK）応答で新しいメッセージ本文を返します。
The Connection general-header field allows the sender to specify options that are desired for that particular connection. It MUST NOT be communicated by proxies over further connections.
接続の一般ヘッダーフィールドを使用すると、送信者はその特定の接続に必要なオプションを指定できます。それ以上の接続を介してプロキシーと通信してはなりません。
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.
Connectionヘッダーにリストされているメッセージヘッダーには、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」の使用は、サーバーが回復できず、接続を閉じる必要があると判断した場合のエラーメッセージに限定する必要があります（SHOULD）。その理由は、クライアントは有効なメッセージを送信する限り、接続を無期限に使用し続けることを選択できるからです。
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レスポンスヘッダーは、リクエスタによる承認が必要なネクストホップのクレデンシャルチェーンを伝達するために使用されます。サーバーからクライアントへの応答でのみ使用する必要があります。
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 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].
RTSP応答のConnection-Credentialsヘッダーは、含まれている場合、仲介者が安全に接続する必要がある次のホップの資格情報（証明書のチェーンを提供する証明書のリストの形式）を含まなければなりません（MUST）。ヘッダーには、ネクストホップ（プロキシまたはサーバー）の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_CERTS）から始まります。この後に、16ビットの符号なし整数のNR_CERTS数が続き、各DERエンコード証明書のサイズをオクテットで提供します。この後に、シーケンス（チェーン）でNR_CERTS番号のDERエンコードされたX.509v3証明書が続きます。このフォーマットの例を図6に示します。プロキシまたはサーバーの証明書が構造の最初に来る必要があります。次の各証明書は、その前の証明書を直接証明する必要があります。証明書の検証ではルートキーを個別に配布する必要があるため、ルート認証局を指定する自己署名証明書は、リモートエンドがそれを検証するためにすでに所有している必要があるという前提で、オプションでチェーンから省略できます。
Example:
例：
Connection-Credentials:"rtsps://proxy2.example.com/";MIIDNTCC...
Connection-Credentials： "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 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format Example of Connection-Credentials Header Certificate
図6：Connection-Credentialsヘッダー証明書のフォーマット例
The Content-Base message body header field may be used to specify the base URI for resolving relative URIs within the message body.
Content-Baseメッセージ本文のヘッダーフィールドを使用して、メッセージ本文内の相対URIを解決するためのベースURIを指定できます。
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.
Content-Base：rtsp：//media.example.com/movie/twister/ Content-Baseフィールドが存在しない場合、メッセージ本文のベースURIは、そのContent-Location（そのContent-Location URIが絶対URI）または要求を開始するために使用されたURI（優先順位の高い順）。ただし、メッセージ本文内のコンテンツのベースURIは、そのメッセージ本文内で再定義できることに注意してください。
The Content-Encoding message body header field is used as a modifier of the media-type. When present, its value indicates what additional content-codings have been applied to the message body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type.
Content-Encodingメッセージ本文のヘッダーフィールドは、メディアタイプの修飾子として使用されます。存在する場合、その値は、メッセージ本文に適用されている追加のコンテンツコーディングを示します。したがって、Content-Typeヘッダーフィールドで参照されるメディアタイプを取得するために、どのデコードメカニズムを適用する必要があるかを示します。 Content-Encodingは主に、基になるメディアタイプのIDを失うことなくドキュメントを圧縮できるようにするために使用されます。
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.
content-codingは、Request-URIによって識別されるメッセージ本文の特性です。通常、メッセージ本文はこのエンコーディングで格納され、レンダリングまたは類似の使用の前にのみデコードされます。ただし、「no-transform」キャッシュディレクティブがメッセージに含まれていない限り、新しいコーディングが受信者に受け入れられることがわかっている場合、RTSPプロキシはコンテンツコーディングを変更できます（MAY）。
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.
メッセージ本文のコンテンツコーディングが「アイデンティティ」ではない場合、メッセージには、使用された非アイデンティティコンテンツコーディングをリストするContent-Encodingメッセージボディヘッダーを含める必要があります。
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（サポートされていないメディアタイプ）で応答する必要があります（SHOULD）。
If multiple encodings have been applied to a message body, the content-codings MUST be listed in the order in which they were applied, first to last from left to right. Additional information about the encoding parameters MAY be provided by other header fields not defined by this specification.
メッセージ本文に複数のエンコーディングが適用されている場合、コンテンツコーディングは、それらが適用された順序で最初から最後まで左から右にリストする必要があります。エンコーディングパラメータに関する追加情報は、この仕様で定義されていない他のヘッダーフィールドから提供される場合があります。
The Content-Language message body header field describes the natural language(s) of the intended audience for the enclosed message body. Note that this might not be equivalent to all the languages used within the message body.
Content-Languageメッセージ本文のヘッダーフィールドは、囲まれたメッセージ本文の対象読者の自然言語を記述します。これは、メッセージ本文内で使用されるすべての言語と同等ではない場合があることに注意してください。
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の主な目的は、ユーザーが自分の優先言語に従ってエンティティを識別および区別できるようにすることです。したがって、本文のコンテンツがデンマーク語の読み書きができる対象者のみを対象としている場合、適切なフィールドは
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.
Content-Languageが指定されていない場合、デフォルトでは、コンテンツはすべての言語の対象ユーザーを対象としています。これは、送信者がそれを自然言語に固有であると見なしていないこと、または送信者が意図する言語がわからないことを意味する場合があります。
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".
ただし、メッセージ本文内に複数の言語が存在するからといって、それが複数の言語の対象者向けであることを意味するわけではありません。例としては、「ラテン語の最初のレッスン」などの初心者向けの言語入門がありますが、これは明らかに英語の知識のある読者が使用することを目的としています。この場合、Content-Languageには「en」のみが適切に含まれます。
Content-Language MAY be applied to any media type -- it is not limited to textual documents.
Content-Languageは、あらゆるメディアタイプに適用できます（テキストドキュメントに限定されません）。
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メッセージ本文のヘッダーフィールドには、RTSPメッセージのメッセージ本文の長さ（つまり、最後のヘッダーに続く二重CRLFの後）がビットのオクテットで含まれています。 HTTPとは異なり、RTSPメッセージのヘッダー部分を超えてメッセージ本文を運ぶすべてのメッセージに含める必要があります。それがない場合は、デフォルト値のゼロが想定されます。ゼロ以上のContent-Lengthは有効な値です。
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 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.
Content-Locationメッセージ本文ヘッダーフィールドは、メッセージ本文に含まれるメッセージ本文のリソースの場所を、要求されたリソースのURIとは別の場所からアクセスできる場合に使用できます（MAY）。サーバーは、応答メッセージ本文に対応するバリアントのContent-Locationを提供する必要があります（SHOULD）。特に、リソースに複数のバリアントが関連付けられており、それらのエンティティに実際に個別にアクセスできる個別の場所がある場合、サーバーは、返される特定のバリアントのContent-Locationを提供する必要があります（SHOULD）。
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」などの特定のリソースに対してDESCRIBEリクエストを実行する場合、サーバーはUser-Agentヘッダーなどの追加情報を使用できます。 、エージェントの機能を判別します。サーバーは、そのクラスのRTSPエージェントに合わせたメディアの説明を返します。エージェントが受け取る特定の説明を示すために、リソース識別子（ "rtsp：//a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp"）がContent-Locationで提供されていますが、説明はまだ有効な応答です汎用リソース識別子。これにより、以下で説明するように、デバッグとキャッシュ操作の両方が可能になります。
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.
Content-Location値は、要求された元のURIの代わりにはなりません。これは、リクエスト時のこの特定のバリアントに対応するリソースの場所のステートメントのみです。将来のリクエストでは、特定のバリアントのソースを特定したい場合は、Content-Location URIをRequest-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とは異なるContent-Locationを持つメッセージ本文が、そのContent-Location URIに対する以降の要求に応答するために使用できると想定できません。ただし、Content-Locationを使用して、1つの要求されたリソースから取得した複数のバリアントを区別できます。
If the Content-Location is a relative URI, the relative URI is interpreted relative to the Request-URI.
Content-Locationが相対URIの場合、相対URIはRequest-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.
Content-Locationを使用して、セッション記述形式で存在する相対URIのベースURIを導出できる場合があることに注意してください。 Content-Locationを使用する場合は、これを考慮する必要があります。その問題を考慮する必要を回避する最も簡単な方法は、Content-Locationが含まれている場合は常にContent-Baseを含めることです。
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.
また、Content-Locationと組み合わせてMediaタグを使用する場合、たとえ異なるContent-Location URIで提供されていても、異なるバージョンが異なるMTagを持つことが重要です。これは、同じリクエスト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.
また、ほとんどの場合と同様に、DESCRIBEリクエストとSETUPリクエストで使用されるURIは異なります。DESCRIBEContent-Locationレスポンスで提供されるURIをSETUPリクエストで直接使用することはできません。代わりに、メディアリソースURIを取得する手順が必要です。これには一般に、SDPのa = control属性などからのメディア記述の相対URIをbase-URIと組み合わせて、SETUPリクエストで必要な絶対URIを作成することが含まれます。
The Content-Type message body header indicates the media type of the message body sent to the recipient. Note that the content types suitable for RTSP are likely to be restricted in practice to presentation descriptions and parameter-value types.
Content-Typeメッセージ本文ヘッダーは、受信者に送信されるメッセージ本文のメディアタイプを示します。 RTSPに適したコンテンツタイプは、実際にはプレゼンテーションの説明とパラメータ値タイプに制限される可能性が高いことに注意してください。
The CSeq general-header field specifies the sequence number (integer) for an RTSP request/response pair. This field MUST be present in all requests and responses. RTSP agents maintain a sequence number series for each responder to which they have an open message transport channel. For each new RTSP request an agent originates on a particular RTSP message transport, the CSeq value MUST be incremented by one. The initial sequence number can be any number; however, it is RECOMMENDED to start at 0. Each sequence number series is unique between each requester and responder, i.e., the client has one series for its requests to a server and the server has another when sending requests to the client. Each requester and responder is identified by its socket address (IP address and port number), i.e., per direction of a TCP connection. Any retransmitted request MUST contain the same sequence number as the original, i.e., the sequence number is not incremented for retransmissions of the same request. The RTSP agent receiving requests MUST process the requests arriving on a particular transport in the order of the sequence numbers. Responses are sent in the order that they are generated. The RTSP response MUST have the same sequence number as was present in the corresponding request. An RTSP agent receiving a response MAY receive the responses out of order compared to the order of the requests it sent. Thus, the agent MUST use the sequence number in the response to pair it with the corresponding request.
CSeq general-headerフィールドは、RTSP要求/応答ペアのシーケンス番号（整数）を指定します。このフィールドは、すべての要求と応答に存在する必要があります。 RTSPエージェントは、オープンメッセージトランスポートチャネルを持つ各レスポンダのシーケンス番号シリーズを維持します。エージェントが特定のRTSPメッセージトランスポートで発信する新しいRTSP要求ごとに、CSeq値を1ずつ増やす必要があります。最初のシーケンス番号は任意の番号にすることができます。ただし、0から開始することをお勧めします。各シーケンス番号シリーズは、各リクエスターとレスポンダーの間で一意です。つまり、クライアントはサーバーへの要求に対して1つのシリーズを持ち、サーバーはクライアントに要求を送信するときに別のシリーズを持ちます。各リクエスターとレスポンダーは、ソケットアドレス（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.
新しい要求ごとに1のシーケンス番号増分を使用する要件は、順序どおりの配信を提供しない、または信頼できないプロトコルを介した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.
複数の順次トランスポート接続を使用する場合、シーケンス番号は個々のトランスポート接続とその5つのタプルでスコープされるため、順序どおりの処理を保証するプロトコルメカニズムはありません。したがって、未処理の要求と同じRTSPセッションに関連する以前にディスパッチされた要求を持つトランスポート接続がすでに存在する同じホストへの新しいトランスポート接続を開くことには、潜在的な問題があります。
RTSP Proxies also need to follow the above rules. This implies that proxies that aggregate requests from multiple clients onto a single transport towards a server or a next-hop proxy need to renumber these requests to form a unified sequence on that transport, fulfilling the above rules. A proxy capable of fulfilling some agent's request without emitting its own request (e.g., a caching proxy that fulfills a request from its cache) also causes a need to renumber as the number of received requests with a particular target may not be the same as the number of emitted requests towards that target agent. A proxy that needs to renumber needs to perform the corresponding renumbering back to the original sequence number for any received response before forwarding it back to the originator of the request.
RTSPプロキシも上記のルールに従う必要があります。これは、複数のクライアントからの要求をサーバーまたは次ホッププロキシへの単一のトランスポートに集約するプロキシは、これらの要求の番号を付け直して、そのトランスポート上で統一されたシーケンスを形成し、上記のルールを満たす必要があることを意味します。独自のリクエストを発行せずに一部のエージェントのリクエストを実行できるプロキシ（たとえば、キャッシュからのリクエストを実行するキャッシングプロキシ）でも、特定のターゲットで受信したリクエストの数がそのターゲットエージェントに対して発行されたリクエストの数。番号を再設定する必要があるプロキシは、受信した応答の元のシーケンス番号に対応する再番号付けを実行してから、要求の発信者に転送する必要があります。
A client connected to a proxy, and using that transport to send requests to multiple servers, creates a situation where it is quite likely to receive the responses out of order. This is because the proxy will establish separate transports from the proxy to the servers on which to forward the client's requests. When the responses arrive from the different servers, they will be forwarded to the client in the order they arrive at the proxy and can be processed, not the order of the client's original sequence numbers. This is intentional to avoid some session's requests being blocked by another server's slow processing of requests.
プロキシに接続され、そのトランスポートを使用して複数のサーバーにリクエストを送信するクライアントは、順不同で応答を受信する可能性が非常に高い状況を作り出します。これは、プロキシがプロキシからクライアントのリクエストを転送するサーバーへの個別のトランスポートを確立するためです。応答が異なるサーバーから到着すると、プロキシに到着した順序でクライアントに転送され、クライアントの元のシーケンス番号の順序ではなく、処理できます。これは、一部のセッションのリクエストが別のサーバーのリクエストの遅い処理によってブロックされるのを防ぐための意図的なものです。
The Date general-header field represents the date and time at which the message was originated. The inclusion of the Date header in an RTSP message follows these rules:
日付の一般ヘッダーフィールドは、メッセージが発信された日時を表します。 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メッセージには、Dateヘッダーを含める必要があります。
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 サーバーに現在の時刻の妥当な概算を提供できるクロックがない場合、その応答には日付ヘッダーフィールドを含めてはなりません（MUST NOT）。この場合、このルールに従う必要があります。オリジンサーバーの実装によっては、使用可能なクロックがない場合があります。クロックのないオリジンサーバーは、ExpiresまたはLast-Modifiedの値を、信頼できるクロックを持つシステムまたはユーザーがリソースに関連付けていない限り、応答に割り当ててはなりません（MUST NOT）。サーバー構成時またはそれ以前に既知であるExpires値を割り当ててもかまいません（これにより、リソースごとに個別のExpires値を格納せずに、応答の「事前有効期限」が可能になります）。
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.
メッセージがその受信者によってキャッシュされる場合、Dateヘッダーフィールドを持たない受信メッセージは、受信者によって1つ割り当てられる必要があります。クロックなしのRTSP実装は、使用するたびに再検証せずに応答をキャッシュしてはなりません（MUST NOT）。 RTSPキャッシュ、特に共有キャッシュは、ネットワークタイムプロトコル（NTP）[RFC5905]などのメカニズムを使用して、クロックを信頼できる外部標準と同期させる必要があります（SHOULD）。
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.
[RFC5322]のセクション3.3で指定された完全な日付であるRTSP日付は、日付ヘッダーで送信され、メッセージの生成後の日付と時刻を表すべきではありません（SHOULD NOT）。これは、実装が適度に正確な日付と時刻を生成する手段を持っていない場合を除き、メッセージ生成の日付と時刻の利用可能な最良の概算を表す必要があります。理論的には、日付はメッセージ本文が生成される直前を表す必要があります。実際には、日付は、メッセージの生成中にいつでも、そのセマンティック値に影響を与えることなく生成できます。
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の日付形式よりも柔軟性があります。したがって、RFC 5322で推奨されているように、実装では区切り文字として単一のスペースを使用し、廃止された形式の受信をサポートする必要があります。
Further, note that the syntax allows for a comment to be added at the end of the date.
さらに、構文により、日付の最後にコメントを追加できることに注意してください。
The Expires message body header field gives a date and time after which the description or media-stream should be considered stale. The interpretation depends on the method:
Expiresメッセージ本文のヘッダーフィールドには、説明またはメディアストリームが古くなっていると見なされるまでの日時が示されます。解釈はメソッドによって異なります。
DESCRIBE response: The Expires header indicates a date and time after which the presentation description (body) SHOULD be considered stale.
DESCRIBE応答：Expiresヘッダーは、プレゼンテーションの説明（本文）が古くなっていると見なす必要がある日時を示します。
SETUP response: The Expires header indicates a date and time after which the media stream SHOULD be considered stale.
SETUP応答：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
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.
応答に「期限切れ」のマークを付けるには、オリジンサーバーは、Dateヘッダー値と等しいExpires日付を使用する必要があります。応答に「有効期限なし」のマークを付けるには、オリジンサーバーは、応答が送信されてから約1年後にExpires日付を使用する必要があります（SHOULD）。 RTSP 2.0サーバーは、1年以上先のExpires日付を送信すべきではありません（SHOULD NOT）。
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リクエストヘッダーフィールドが指定されている場合、SHOULDには、リクエストしているユーザーエージェントを制御する人間のユーザーのインターネット電子メールアドレスが含まれている必要があります。 [RFC1123]の「メールボックス」で定義されているように、アドレスはマシンで使用できる必要があります（SHOULD）。
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.
このヘッダーフィールドは、ロギングの目的で、および無効または不要な要求のソースを識別する手段として使用できます。安全でない形式のアクセス保護として使用しないでください。このフィールドの解釈は、実行されたメソッドの責任を受け入れる、指定された人に代わってリクエストが実行されていることです。特に、ロボットエージェントは、受信側で問題が発生した場合にロボットの実行責任者に連絡できるように、このヘッダーを含める必要があります（SHOULD）。
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.
このフィールドのインターネット電子メールアドレスは、要求を発行したインターネットホストとは別である場合があります。たとえば、リクエストがプロキシを介して渡される場合、元の発行者のアドレスを使用する必要があります（SHOULD）。
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.
クライアントは、ユーザーのプライバシー上の関心やサイトのセキュリティポリシーと競合する可能性があるため、ユーザーの承認なしにFromヘッダーフィールドを送信しないでください。ユーザーがリクエストの前にいつでもこのフィールドの値を無効化、有効化、および変更できるようにすることを強くお勧めします。
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要求ヘッダーフィールドは、プレゼンテーションの説明がどのように受信されたかに関係なく、プレゼンテーションの説明の整合性を保証するのに特に役立ちます。プレゼンテーションの説明は、RTSPの外部の手段（HTTPなど）またはDESCRIBEメッセージを介してフェッチできます。 RTSPを介してプレゼンテーションの説明を取得する場合、サーバーの実装は、DESCRIBEメッセージとSETUPメッセージの間の説明の整合性を保証します。 SETUP要求のIf-Matchヘッダー部分にセッションの説明で指定されたMTagを含めることにより、クライアントは、セットアップされたリソースが説明と一致していることを確認します。 MTag検証チェックが失敗したIf-Matchヘッダーを含むSETUPリクエストは、412（Precondition Failed）を使用して応答を生成する必要があります。
This validation check is also very useful if a session has been redirected from one server to another.
この検証チェックは、セッションがサーバー間でリダイレクトされた場合にも非常に役立ちます。
The If-Modified-Since request-header field is used with the DESCRIBE and SETUP methods to make them conditional. If the requested variant has not been modified since the time specified in this field, a description will not be returned from the server (DESCRIBE) or a stream will not be set up (SETUP). Instead, a 304 (Not Modified) response MUST be returned without any message body.
If-Modified-Sinceリクエストヘッダーフィールドは、DESCRIBEメソッドとSETUPメソッドで条件付きにするために使用されます。このフィールドで指定された時刻以降に要求されたバリアントが変更されていない場合、サーバーから説明が返されない（DESCRIBE）か、ストリームがセットアップされない（SETUP）。代わりに、メッセージ本文なしで304（Not Modified）応答を返す必要があります。
An example of the field is:
フィールドの例は次のとおりです。
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
This request-header can be used with one or several message body tags to make DESCRIBE requests conditional. A client that has one or more message bodies previously obtained from the resource can verify that none of those entities is current by including a list of their associated message body tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. As a special case, the value "*" matches any current entity of the resource.
このリクエストヘッダーを1つまたは複数のメッセージ本文タグと共に使用して、DESCRIBEリクエストを条件付きにすることができます。以前にリソースから取得した1つ以上のメッセージ本文を持つクライアントは、関連するメッセージ本文タグのリストを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).
メッセージ本文タグのいずれかが、そのリソースに対する同様のDESCRIBE要求（If-None-Matchヘッダーなし）への応答で返されるメッセージ本文のメッセージ本文タグと一致する場合、または「*」が指定されている場合そのリソースに現在のエンティティが存在する場合、リソースの変更日がリクエストのIf-Modified-Sinceヘッダーフィールドで指定されたものと一致しないため、サーバーは必要に応じて、要求されたメソッドを実行してはなりません（MUST NOT）。代わりに、リクエストメソッドがDESCRIBEの場合、サーバーは、一致したメッセージ本文の1つのキャッシュ関連ヘッダーフィールド（特にMTag）を含む304（Not Modified）レスポンスで応答する必要があります（SHOULD）。他のすべての要求メソッドの場合、サーバーはステータス412（前提条件の失敗）で応答する必要があります。
See Section 16.1.3 for rules on how to determine if two message body tags match.
2つのメッセージ本文タグが一致するかどうかを判断する方法のルールについては、セクション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（Not Modified）応答を返してはなりません（MUST NOT）。
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ヘッダーフィールドなしでリクエストが2xxまたは304ステータス以外の結果になる場合、If-None-Matchヘッダーは無視する必要があります。 （If-Modified-SinceとIf-None-Matchの両方が同じリクエストに含まれる場合のサーバーの動作については、セクション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-MatchヘッダーフィールドとIf-Matchヘッダーフィールドの両方を持つリクエストの結果は指定されておらず、不正なリクエストと見なされなければなりません（MUST）。
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メッセージ本文のヘッダーフィールドは、オリジンサーバーがプレゼンテーションの説明またはメディアストリームが最後に変更されたと信じる日時を示します。 DESCRIBEメソッドの場合、ヘッダーフィールドは、メディアストリームのSETUPの説明の最終変更日時を示します。
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.
オリジンサーバーは、サーバーのメッセージ発生時刻より後の最終変更日を送信してはなりません（MUST NOT）。そのような場合、リソースの最後の変更が将来のある時点を示す場合、サーバーはその日付をメッセージの開始日で置き換えなければなりません（MUST）。
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.
オリジンサーバーは、メッセージボディのLast-Modified値を、その応答のDate値を生成する時刻に可能な限り近く取得する必要があります（SHOULD）。これにより、受信者は、特に応答が生成された時刻近くにメッセージ本文が変更された場合に、メッセージ本文の変更時刻を正確に評価できます。
RTSP servers SHOULD send Last-Modified whenever feasible.
RTSPサーバーは、可能な限りLast-Modifiedを送信する必要があります（SHOULD）。
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応答ヘッダーフィールドは、要求の完了または新しいリソースの識別のために、受信者をRequest-URI以外の場所にリダイレクトするために使用されます。 3rr応答の場合、ロケーションは、リソースへの自動リダイレクトのためのサーバーの優先URIを示す必要があります（SHOULD）。フィールド値は、単一の絶対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はリクエストに含まれるメッセージ本文の元の場所を識別します。したがって、応答にLocationとContent-Locationの両方のヘッダーフィールドが含まれる可能性があります。また、一部のメソッドのキャッシュ要件については、セクション16.2を参照してください。
This general-header is used in SETUP responses or PLAY_NOTIFY requests to indicate the media's properties that currently are applicable to the RTSP session. PLAY_NOTIFY MAY be used to modify these properties at any point. However, the client SHOULD have received the update prior to any action related to the new media properties taking effect. For aggregated sessions, the Media-Properties header will be returned in each SETUP response. The header received in the latest response is the one that applies on the 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.
この一般的なヘッダーは、現在RTSPセッションに適用できるメディアのプロパティを示すために、SETUP応答またはPLAY_NOTIFY要求で使用されます。 PLAY_NOTIFYを使用して、これらのプロパティをいつでも変更できます。ただし、クライアントは新しいメディアプロパティに関連するアクションが有効になる前に更新を受信する必要があります（SHOULD）。集約されたセッションの場合、Media-Propertiesヘッダーが各SETUP応答で返されます。最新の応答で受信されるヘッダーは、この時点から将来の更新までのセッション全体に適用されるヘッダーです。ヘッダーは、セッションの現在のMedia-Propertiesをクエリするために含まれているセッションヘッダーを含むサーバーへのGET_PARAMETERリクエストに値なしで含まれる場合があります。レスポンダは、現在のセッションのメディアプロパティを含める必要があります。
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セッションのすべてのメディアに適用できるものです。集約されたセッションの場合、ヘッダーは結合されたメディアプロパティを表します。その結果、メディアを集約すると、メディアプロパティが変更される可能性があり、したがって、後続のSETUP応答に含まれるMedia-Propertiesヘッダーの内容が変更される可能性があります。
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:
この仕様では、次の4つのグループとそのプロパティ値を定義しています。
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.
ランダムアクセス：ランダムアクセスが可能であることを示します。オプションで、メディア内の任意の2つのランダムアクセスポイント間の最長の継続時間を示す浮動小数点値（秒単位）を含めることができます。
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.
Time-Duration：各個々のメディアユニットは、少なくとも指定されたTime-Durationの間保持されます。この定義により、時間ベースのスライディングウィンドウでデータを保持できます。時間の長さは、秒単位の浮動小数点数として表されます。値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.
スケール：コンテンツでサポートされる1つ以上の10進数値またはスケール値の範囲の、コンマ区切りの引用符付きリスト。任意の順序。範囲には、コロンで区切られた開始値と終了値があります。範囲は、コンテンツがスケール値のきめの細かい選択をサポートすることを示します。ファイングレインは、少なくともスケール値の1/10のステップを可能にします。特定のスケール値に応じてサーバーが要求された値の1/10スケール単位（0.1）未満の実際のスケールでコンテンツを生成できる場合、コンテンツはきめの細かい選択をサポートすると見なされます。負の値がサポートされています。値0は意味がなく、使用してはなりません（MUST NOT）。
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"
Live stream without recording/timeshifting:
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0.0
The Media-Range general-header is used to give the range of the media at the time of sending the RTSP message. This header MUST be included in the SETUP response, PLAY and PAUSE responses for media that are time-progressing, PLAY and PAUSE responses after any change for media that are Dynamic, and in PLAY_NOTIFY requests that are sent 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.
Media-Range general-headerは、RTSPメッセージの送信時にメディアの範囲を指定するために使用されます。このヘッダーは、SETUP応答、時間経過するメディアのPLAYおよびPAUSE応答、動的なメディアの変更後のPLAYおよびPAUSE応答、およびMedia-Property-Updateによって送信されるPLAY_NOTIFY要求に含める必要があります。範囲指定のないMedia-Rangeヘッダーは、現在の範囲を要求するサーバーへのGET_PARAMETER要求に含めることができます。この場合、サーバーは応答を送信するときに現在の範囲を含める必要があります。
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.
メディアのセットアップ時にAccept-Rangesヘッダー（セクション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プロパティを持つメディアの場合、Media-Rangeヘッダー値は、発行された特定の時点でのみ有効になります。壁時計が進むにつれて、メディアの範囲も変わります。ただし、メディア時間は、（クロックスキューを除いて）実時間と直接関係して進み、メディア範囲の合理的に正確な推定値を計算できると想定されます。
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応答ヘッダーは、DESCRIBE、GET_PARAMETER、またはSETUP応答に含まれる場合があります。 DESCRIBE応答で返されるメッセージ本文タグ（セクション4.6）とSETUPのメッセージ本文タグは、プレゼンテーション、つまり返されたセッションの説明とメディアストリームの両方を参照します。これにより、SETUP要求時にメディアリソースに対する正しいセッション記述があることを確認できます。ただし、いずれかのパーツを変更すると、すべてのパーツが無効になるという欠点があります。
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.
MTagがメッセージ本文内、たとえばSDPの「a = mtag」属性内と応答メッセージの両方で提供される場合、両方のタグは同一である必要があります。キャッシュがコンテンツの検査を必要とせずにMTagを使用できるようにするために、MTagは主にRTSP応答メッセージで指定することをお勧めします。ただし、HTTPなどを使用してRTSPの外部で配布されるセッション記述の場合、付録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).
SETUPおよびDESCRIBEリクエストは、ヘッダーのIf-Match（セクション18.24）およびIf-None-Match（セクション18.26）を使用して、MTagを条件として作成できます。
The Notify-Reason response-header is solely used in the PLAY_NOTIFY method. It indicates the reason why the server has sent the asynchronous PLAY_NOTIFY request (see Section 13.5).
Notify-Reason応答ヘッダーは、PLAY_NOTIFYメソッドでのみ使用されます。サーバーが非同期のPLAY_NOTIFYリクエストを送信した理由を示します（セクション13.5を参照）。
The Pipelined-Requests general-header is used to indicate that a request is to be executed in the context created by a previous request(s). The primary usage of this header is to allow pipelining of SETUP requests so that any additional SETUP request after the first one does not need to wait for the session ID to be sent back to the requesting agent. The header contains a unique identifier that is scoped by the persistent connection used to send the requests.
Pipelined-Requests general-headerは、前の要求によって作成されたコンテキストで要求が実行されることを示すために使用されます。このヘッダーの主な用途は、SETUP要求のパイプライン化を可能にすることです。これにより、最初の要求の後の追加のSETUP要求は、セッション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.
Pipelined-Requestsでリクエストを受信すると、応答するエージェントは、現在の永続的な接続のこのPipelined-Requests識別子とRTSPセッションIDの間にバインディングが存在するかどうかを検索する必要があります。バインディングが存在する場合、受信した要求は、見つかったセッションIDを持つセッションヘッダーが含まれているかのように処理されます。マッピングが存在せず、リクエストにセッションヘッダーが含まれていない場合、応答するエージェントは、セッション作成リクエスト、つまりSETUPが正常に完了したときにバインディングを作成する必要があります。リクエストがRTSPセッションの作成に失敗した場合、バインディングを作成してはなりません（MUST NOT）。リクエストにセッションヘッダーとPipelined-Requestsヘッダーの両方が含まれている場合、Pipelined-Requestsヘッダーは無視する必要があります。
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.
注：上記の定義に基づいて、少なくとも新しい一意のPipelined-Requestsヘッダーを含む最初のリクエストは、SETUPリクエストである必要があります（プロトコルがセッションを作成する新しいメソッドで拡張されている場合を除く）。最初のリクエストの後、追加のSETUPリクエストまたは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ヘッダーを含むリクエストに応答する場合、サーバーは、セッションコンテキストへのバインディングが存在するときに、Sessionヘッダーも含める必要があります。セッション識別子を知っているRTSPエージェントは、どの要求でもPipelined-Requestsヘッダーを使用してはならず（SHOULD NOT）、Sessionヘッダーのみを使用します。これは、セッション識別子が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 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.
Pipelined-Requestsヘッダーを使用してリクエストを送信するRTSPエージェントは、トランスポートコンテキスト内で以前は使用されていなかった一意の識別子を使用する責任があります。現在、このようなトランスポートコンテキストとして定義されているのはTCP接続のみです。サーバーは、そのセッションの終了時にPipelined-Requests識別子とそのセッションへのバインディングを削除する必要があります。以前の要件にもかかわらず、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プロキシは、リクエストを永続的な接続に集約できるようにするために、Pipelined-Requests識別子の値を受信リクエストから送信に変換する必要がある場合があります。
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].
Proxy-Authenticate応答ヘッダーフィールドは、407（Proxy Authentication Required）応答の一部として含まれている必要があります。 field-valueは、このRequest-URIのプロキシに適用可能な認証スキームとパラメータを示すチャレンジで構成されています。ヘッダーの定義は[RFC7235]にあり、適用可能なHTTP認証スキームは、ダイジェスト[RFC7616]や基本[RFC7617]などの他のRFCに記載されています。
The HTTP access authentication process is described in [RFC7235]. This header MUST only be used in response messages related to client-to-server requests.
HTTPアクセス認証プロセスは、[RFC7235]で説明されています。このヘッダーは、クライアントからサーバーへの要求に関連する応答メッセージでのみ使用する必要があります。
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.
Proxy-Authentication-Info応答ヘッダーは、ダイジェスト方式[RFC7616]などの一部の認証方式のメッセージ応答で、成功した認証に関するいくつかの情報をプロキシに通信するためにプロキシによって使用されます。ヘッダーの定義は[RFC7615]にあり、適用可能なHTTP認証スキームは他のRFCにあります。このヘッダーは、クライアントからサーバーへの要求に関連する応答メッセージでのみ使用する必要があります。このヘッダーにはホップバイホップのスコープがあります。
The Proxy-Authorization request-header field allows the client to identify itself (or its user) to a proxy that requires authentication. The Proxy-Authorization field-value consists of credentials containing the authentication information of the user agent for the proxy or realm of the resource being requested. The definition of the header is in [RFC7235], and any applicable HTTP authentication schemes appear in other RFCs, such as Digest [RFC7616] and Basic [RFC7617].
Proxy-Authorizationリクエストヘッダーフィールドを使用すると、認証を必要とするプロキシに対してクライアント（またはそのユーザー）を識別できます。 Proxy-Authorizationフィールド値は、要求されているリソースのプロキシーまたはレルムのユーザーエージェントの認証情報を含む資格情報で構成されています。ヘッダーの定義は[RFC7235]にあり、適用可能なHTTP認証スキームは、ダイジェスト[RFC7616]や基本[RFC7617]などの他のRFCに記載されています。
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.
HTTPアクセス認証プロセスは、[RFC7235]で説明されています。 Authorizationとは異なり、Proxy-Authorizationヘッダーフィールドはネクストホッププロキシにのみ適用されます。このヘッダーは、クライアントからサーバーへのリクエストでのみ使用する必要があります。
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リクエストヘッダーフィールドは、プロキシによってサポートされる必要があるプロキシ依存の機能を示すために使用されます。プロキシーでサポートされていないProxy-Requireヘッダー機能は、Unsupportedヘッダーを使用して、プロキシーからクライアントに否定的に通知される必要があります。プロキシは、応答で551（オプションはサポートされていません）ステータスコードを使用する必要があります。 Proxy-Requireに含まれる機能タグは、エンドポイント（サーバーまたはクライアント）には適用されません。機能がプロキシとサーバーの両方でサポートされるようにするには、タグを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
Proxy-Require：play.basic
The Proxy-Supported general-header field enumerates all the extensions supported by the proxy using feature tags. The header carries the intersection of extensions supported by the forwarding proxies. The Proxy-Supported header MAY be included in any request by a proxy. It MUST be added by any proxy if the Supported header is present in a request. When present in a request, the receiver MUST copy the received Proxy-Supported header in the response.
Proxy-Supported general-headerフィールドは、機能タグを使用してプロキシがサポートするすべての拡張機能を列挙します。ヘッダーは、転送プロキシがサポートする拡張機能の共通部分を伝送します。 Proxy-Supportedヘッダーは、プロキシによるリクエストに含まれる場合があります。サポートされているヘッダーがリクエストに存在する場合は、プロキシによって追加される必要があります。リクエストに存在する場合、受信者は受信したProxy-Supportedヘッダーを応答にコピーする必要があります。
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で説明されているように、Proxy-Supportedヘッダーフィールドには、プロキシに適用可能な機能タグのリストが含まれています。リストは、プロキシによって認識されるすべての機能タグの共通部分です。共通部分を実現するために、Proxy-Supportedヘッダーを追加するプロキシには、理解できるすべてのプロキシ機能タグが含まれています。ヘッダー付きのリクエストを受信するプロキシはすべて、リストをチェックして、サポートしていない機能タグを削除する必要があります。応答に存在するProxy-Supportedヘッダーは、プロキシによって変更されてはいけません。これらの機能タグは、プロキシチェーンが一般的にサポートするタグであり、リクエストリソースに固有ではありません。
Example:
例：
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
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
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フィールドには、応答の送信者がサポートする一連のメソッドが一覧表示されます。このヘッダーは送信者の一般的な機能に適用され、その唯一の目的は送信者の機能を受信者に示すことです。リストされているメソッドは、Request-URIに適用できる場合と適用できない場合があります。 Allowヘッダーフィールド（セクション18.6）は、特定のURIで許可されるメソッドを示すために使用できます（MAY）。
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 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.
一般に、プロキシはすべてのメソッドが送信側のRTSPエージェントから受信側のRTSPエージェントに透過的に通過できるようにする必要がありますが、これが特定のプロキシにとって望ましくない場合もあります。介在するプロキシによるパブリックレスポンスヘッダーフィールドの変更により、リクエストセンダーは、プロキシチェーンを介してターゲットエージェントで使用できるメソッドを示す正確なレスポンスを取得できます。
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汎用ヘッダーは、PLAY（セクション13.4）、PAUSE（セクション13.6）、SETUP（セクション13.3）、およびPLAY_NOTIFY（セクション13.5）のリクエストと応答で時間範囲を指定します。クライアントからサーバーへのGET_PARAMETERリクエストに含まれる場合があります。範囲フォーマットのみで、現在のメディアの位置をリクエストする値はありません。これは、含まれているフォーマットでセッションがPlayまたはReady状態にあるかどうかです。サーバーは、範囲形式をサポートしている場合、現在の再生ポイントまたは一時停止ポイントを範囲の開始として応答する必要があります（SHALL）。以前のPLAYリクエストで明示的な停止ポイントが使用された場合、その値は停止ポイントとして含まれます。サーバーが現在、1以外のスケール値のように、範囲ヘッダーの解釈に影響を与える任意のタイプのメディア再生操作下にある場合、その情報は、完全な情報を提供するためにスケールヘッダーを含めることにより、GET_PARAMETER応答にも含める必要があることに注意してください。 。
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）、およびclock（セクション4.4.3）の範囲の単位を定義しています。オクテット範囲（バイト範囲）（[RFC7233]のセクション2.1を参照）およびその他の拡張ユニットを使用できますが、それらはRTSPでは通常意味がないため、動作は指定されていません。 Rangeヘッダーをサポートするサーバーは、NPT範囲形式を理解する必要があり、SMPTE範囲形式を理解する必要があります。 Rangeヘッダーが理解できない時間形式で送信される場合、受信者は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.
Rangeヘッダーには、1つの範囲形式の範囲が含まれています。範囲は、開始点と終了点を含む半開区間で、開始点は含まれますが、終了点は含まれません。範囲は、開始点と終了点の明示的な値で完全に指定することも、開始点または終了点を暗黙的に指定することもできます。暗黙の開始ポイントはセッションの一時停止ポイントを示し、一時停止ポイントが設定されていない場合はコンテンツの開始を示します。暗黙のエンドポイントは、コンテンツの終わりを示します。暗黙的な開始点と終了点の両方を同じRangeヘッダーで使用することはできません。ただし、範囲ヘッダーの省略は、つまり、一時停止ポイント（または開始）からコンテンツの終わりまでの意味を持ちます。
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ミリ秒ごとに生成されると仮定します。 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タイムスケールの「現在」と暗黙の開始値の違いに注意してください。暗黙的な値は現在の一時停止ポイントを参照しますが、「現在」は現在の時間です。記録のある時間進行セッション（一部またはフルタイムの保持）では、一時停止ポイントはセッションに2分になる可能性がありますが、セッションに1時間になる可能性があります。
By default, range intervals increase, where the second point is larger than the first point.
デフォルトでは、範囲間隔は増加し、2番目のポイントは最初のポイントよりも大きくなります。
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
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
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.
Scaleヘッダーに対応する負の値がない範囲の減少間隔は無効です。
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.
クライアントは、Referrer request-headerフィールドを使用して、サーバーの利益のために、Request-URIを取得したリソースのアドレス（URI）を指定できます。 URIはプレゼンテーションの説明のURIを指し、通常はHTTP経由で取得されます。 Referrerリクエストヘッダーを使用すると、サーバーはリソースへのバックリンクのリストを生成したり、ロギング、最適化されたキャッシュなどを生成したりできます。また、メンテナンスのために古いリンクやタイプミスしたリンクを追跡できます。ユーザーキーボードからの入力など、独自のURIを持たないソースからRequest-URIを取得した場合、Referrerフィールドを送信してはならない（MUST NOT）。
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.
field-valueが相対URIの場合、Request-URIを基準にして解釈する必要があります（SHOULD）。 URIにフラグメント識別子を含めてはなりません（MUST NOT）。
Because the source of a link might be private information or might reveal an otherwise private information source, it is strongly recommended that the user be able to select whether or not the Referrer field is sent. For example, a streaming client could have a toggle switch for openly/anonymously, which would respectively enable/disable the sending of Referrer and From information.
リンクのソースはプライベートな情報であるか、それ以外の場合はプライベートな情報ソースである可能性があるため、Referrerフィールドを送信するかどうかをユーザーが選択できるようにすることを強くお勧めします。たとえば、ストリーミングクライアントには、リファラーと送信元の情報の送信をそれぞれ有効/無効にするオープン/匿名のトグルスイッチを設定できます。
Clients SHOULD NOT include a Referrer header field in an (non-secure) RTSP request if the referring page was transferred with a secure protocol.
参照ページがセキュアなプロトコルで転送された場合、クライアントは（非セキュアな）RTSPリクエストにリファラーヘッダーフィールドを含めないでください。
This request-header is used to indicate the end result for requests that take time to complete, such as PLAY (Section 13.4). It is sent in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report how the PLAY request concluded, either in success or in failure. The header carries a reference to the request it reports on using the CSeq number and the Session ID used in the request reported on. This is not ensured to be unambiguous due to the fact that the CSeq number is scoped by the transport connection. Agents originating requests 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.
このリクエストヘッダーは、PLAY（セクション13.4）など、完了するまでに時間がかかるリクエストの最終結果を示すために使用されます。これはPLAY_NOTIFY（セクション13.5）で送信され、ストリーム終了の理由とともに、成功または失敗したPLAYリクエストの終了方法を報告します。ヘッダーは、CSeq番号を使用してレポートする要求への参照と、レポートされる要求で使用されるセッションIDを伝達します。これは、CSeq番号がトランスポート接続によって有効範囲が設定されるという事実のために、明確であることは保証されません。要求を発信するエージェントは、使用されるすべての順次トランスポート全体で単調に増加するカウンターを使用することにより、問題を軽減できます。ヘッダーは、数値のステータスコード（セクション8.1.1に基づく）と人間が読める理由フレーズの両方を提供します。
Example:
Request-Status: cseq=63 status=500 reason="Media data unavailable"
Proxies that renumber the CSeq header need to perform corresponding remapping of the cseq parameter in this header when forwarding the request to the next-hop agent.
CSeqヘッダーの番号を再設定するプロキシは、要求をネクストホップエージェントに転送するときに、このヘッダーのcseqパラメーターの対応する再マッピングを実行する必要があります。
The Require request-header field is used by agents to ensure that the other endpoint supports features that are required in respect to this request. It can also be used to query if the other endpoint supports certain features; however, the use of the Supported general-header (Section 18.51) is much more effective in this purpose. In case any of the feature tags listed by the Require header are not supported by the server or client receiving the request, it MUST respond to the request using the error code 551 (Option Not Supported) and include the Unsupported header listing those feature tags that are NOT supported. This header does not apply to proxies; for the same functionality with respect to proxies, see the Proxy-Require header (Section 18.37) with the exception of media-modifying proxies. Media-modifying proxies, due to their nature of handling media in a way that is very similar to a server, do need to understand also the server's features to correctly serve the client.
Require request-headerフィールドは、他のエンドポイントがこのリクエストに関して必要な機能を確実にサポートするためにエージェントによって使用されます。また、他のエンドポイントが特定の機能をサポートしているかどうかを照会するためにも使用できます。ただし、この目的では、サポートされている一般ヘッダー（セクション18.51）を使用する方がはるかに効果的です。 Requireヘッダーにリストされている機能タグのいずれかがリクエストを受信するサーバーまたはクライアントでサポートされていない場合は、エラーコード551（Option Not Supported）を使用してリクエストに応答し、サポートされていない機能ヘッダーをリストするUnsupportedヘッダーを含める必要があります。サポートされていません。このヘッダーはプロキシには適用されません。プロキシに関する同じ機能については、メディア変更プロキシを除いて、Proxy-Requireヘッダー（セクション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
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-Parameterフィールドが必要であることをクライアントに示す機能タグです。 「funky-feature」とFunky-Parameterの関係は、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.
プロキシおよびその他の中間デバイスは、このヘッダーを無視する必要があります。特定の拡張機能で中間デバイスがサポートする必要がある場合は、代わりに拡張機能をProxy-Requireフィールドでタグ付けする必要があります（セクション18.37を参照）。機能でプロキシサポートが必要であると見なす場合については、プロキシセクション（セクション15.1）の説明を参照してください。
The Retry-After response-header field can be used with a 503 (Service Unavailable) or 553 (Proxy Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. This field MAY also be used with any 3rr (Redirection) response to indicate the minimum time the user agent is asked to wait before issuing the redirected request. A response using 413 (Request Message Body Too Large) when the restriction is temporary MAY also include the Retry-After header. The value of this field can be either an RTSP-date or an integer number of seconds (in decimal) after the time of the response.
Retry-After応答ヘッダーフィールドを503（Service Unavailable）または553（Proxy Unavailable）応答と共に使用して、要求元のクライアントがサービスを利用できないと予想される期間を示すことができます。このフィールドは、リダイレクトされた要求を発行する前にユーザーエージェントが待機するように求められる最小時間を示すために、任意の3rr（リダイレクト）応答と共に使用される場合があります。制限が一時的なものである場合に413（Request Message Body Too Large）を使用する応答には、Retry-Afterヘッダーも含まれる場合があります。このフィールドの値は、RTSP日付、または応答時間後の秒数（10進数）の整数のいずれかです。
Example:
例：
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
In the latter example, the delay is 2 minutes.
後者の例では、遅延は2分です。
The RTP-Info general-header field is used to set RTP-specific parameters in the PLAY and GET_PARAMETER responses or PLAY_NOTIFY and GET_PARAMETER requests. For streams using RTP as transport protocol, the RTP-Info header SHOULD be part of a 200 response to PLAY.
RTP-Info汎用ヘッダーフィールドは、PLAYおよびGET_PARAMETER応答またはPLAY_NOTIFYおよびGET_PARAMETER要求でRTP固有のパラメーターを設定するために使用されます。トランスポートプロトコルとしてRTPを使用するストリームの場合、RTP-Infoヘッダーは、PLAYに対する200応答の一部である必要があります（SHOULD）。
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トランスポートされたメディアのPLAY応答でRTP-Infoを除外すると、クライアントは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情報をSETUP応答に含めることができます。セクション13.3を参照してください。 RTP-InfoヘッダーとRangeヘッダーは、現在の再生ポイントと対応するRTP同期情報を要求する値なしで、クライアントからサーバーへのGET_PARAMETER要求に含めることができます。 RTP-Infoヘッダーがリクエストに含まれている場合、Rangeヘッダーも含まれている必要があります。サーバーの応答には、RangeヘッダーとRTP-Infoヘッダーの両方が含まれる必要があります（SHALL）。セッションがPlay状態の場合、Rangeヘッダーの値は、現在の再生ポイントと対応するRTP-Info値で埋められる必要があります（SHALL）。サーバーが別の状態にある場合、RTP-Infoヘッダーに値は含まれません。ヘッダーは、ストリームの終わりに関するRTP情報を提供するために、ストリームの終わりのNotify-ReasonとともにPLAY_NOTIFY要求に含まれています。
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は、このメディアストリームのSETUP要求で使用されるものと同じである必要があります。すべての相対URIは、Request-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：Range応答ヘッダーの開始時刻値に対応するRTPタイムスタンプ値を示す必要があります。明示的に指定されていない場合は、暗黙の開始点を示す必要があります。クライアントはこの値を使用して、RTP時間からNPTまたはその他のメディアタイムスケールへのマッピングを計算します。このパラメーターは、メディア間の同期が確実に行われるようにするために存在する必要があります（SHOULD）。受信した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形式のタイムスタンプ（ウォールクロック）へのマッピングは、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
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
X: NPT time value = 3.25, from Range header.
A: RTP timestamp value for Audio from RTP-Info header (12345678).
V: RTP timestamp value for Video from RTP-Info header (29567112).
PA: RTP audio packet carrying an RTP timestamp of 12344878, which
corresponds to NPT = (12344878 - A) / 16000 + 3.25 = 3.2
PV: RTP video packet carrying an RTP timestamp of 29573412, which
corresponds to NPT = (29573412 - V) / 90000 + 3.25 = 3.32
The Scale general-header indicates the requested or used view rate for the media resource being played back. A scale value of 1 indicates normal play at the normal forward viewing rate. If not 1, the value corresponds to the rate with respect to normal viewing rate. For example, a value of 2 indicates twice the normal viewing rate ("fast forward") and a value of 0.5 indicates half the normal viewing rate. In other words, a value of 2 has content time increase at twice the playback time. For every second of elapsed (wallclock) time, 2 seconds of content time will be delivered. A negative value indicates reverse direction. For certain media transports, this may require certain considerations to work consistently; see Appendix C.1 for description on how RTP handles this.
スケール一般ヘッダーは、再生されているメディアリソースの要求または使用された視聴率を示します。スケール値1は、通常の順方向視聴率での通常の再生を示します。 1でない場合、値は通常の視聴率に対する比率に対応します。たとえば、値2は通常の表示レートの2倍（「早送り」）を示し、値0.5は通常の表示レートの半分を示します。つまり、値が2の場合、再生時間の2倍でコンテンツ時間が増加します。経過時間（壁時計）の1秒ごとに、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.
送信データレートは、別のスケール値を選択することによって変更してはなりません（SHOULD NOT）。結果のビットレートは、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.
サーバーとコンテンツは、サポートするスケール値の範囲を制限する場合があります。サポートされている値は、Media-Propertiesヘッダー（セクション18.29）で示されます。クライアントは、サポートされる要求値のみを示す必要があります（SHOULD）。ただし、コンテンツの進行に伴って値が変化する可能性があるため、要求が届いたときに要求された値が無効になる可能性があります。したがって、リクエストでサポートされていない値はエラーを生成せず、サーバーに最も近い値を選択させるだけです。応答には、常にサーバーによって選択された実際のスケール値が含まれている必要があります。
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.
サーバーがスケーリングの可能性を実装していない場合、サーバーはScaleヘッダーを返しません。 PLAYのスケール操作をサポートするサーバーは、「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で説明されているように範囲の減少を示さなければなりません（MUST）。
Example of playing in reverse at 3.5 times normal rate:
通常の3.5倍の速度で逆再生する例：
Scale: -3.5
Range: npt=15-10
When a client sends a PLAY request with a Range header to perform a random access to the media, the client does not know if the server will pick the first media samples or the first random access point prior to the request range. Depending on the use case, the client may have a strong preference. To express this preference and provide the client with information on how the server actually acted on that preference, the Seek-Style general-header is defined.
クライアントがRangeヘッダーを含むPLAYリクエストを送信してメディアへのランダムアクセスを実行するとき、クライアントはサーバーがリクエスト範囲の前に最初のメディアサンプルまたは最初のランダムアクセスポイントを選択するかどうかを知りません。ユースケースによっては、クライアントに強い好みがあるかもしれません。この設定を表現し、サーバーが実際にその設定にどのように作用したかに関する情報をクライアントに提供するために、Seekスタイルの一般ヘッダーが定義されています。
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は、ランダムアクセスプロパティを持つメディアストリームに対するクライアントの設定を示すために、PLAYリクエストに含めることができる一般的なヘッダーです。サーバーは、どのポリシーが適用されたかを示すために、ランダムアクセスプロパティを持つメディアのPLAY応答に常にヘッダーを含める必要があります。不明なSeek-Styleポリシーを受信するサーバーは、それを無視して、サーバーのデフォルトポリシーを選択する必要があります。不明なポリシーを受信するクライアントはそれを無視し、サーバーが何をしたかを判断するための基礎としてRangeヘッダーとメディア同期情報を使用しなければなりません（MUST）。
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 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.
CoRAP：条件付きランダムアクセスポイント（CoRAP）は、上記のRAP動作の変形です。このポリシーは主に、メディア内のランダムアクセスポイント間の距離が長い場合を対象としています。 CoRAPは、現在の一時停止ポイントよりも要求された開始ポイントの近くにランダムアクセスポイントがあるという条件が満たされた場合に、RAPポリシーを使用します。それ以外の場合、シークは実行されず、再生は現在の一時停止ポイントから続行されます。このポリシーは、配信が続行される場合、一時停止の前に存在するメディア状態が使用可能であることを前提としています。クライアントまたはサーバーがこれが事実ではないことを知っている場合は、RAPポリシーを使用する必要があります。言い換えると、ほとんどの場合、クライアントが現在の一時停止ポイントの前に開始ポイントを要求すると、一時停止の前に配信されたメディアから、要求されたメディアユニットへの有効なデコード依存チェーンが存在しなくなります。サーバーがランダムアクセスポイントを検索した場合、サーバーはSeeRスタイルヘッダーでCoRAPポリシーを返し、選択したRAPの位置を反映するようにRangeヘッダーを調整する必要があります。ランダムアクセスポイントがより遠くにあり、サーバーが現在の一時停止ポイントから続行することを選択した場合、Seek-Styleヘッダーに "Next"ポリシーを含め、Rangeヘッダーの開始ポイントを現在の一時停止ポイントに調整する必要があります。
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-Prior：first-priorポリシーは、要求された時間より前にプレイアウト時間が最初にあるメディアユニットから配信を開始します。ディスクリートメディアの場合は、リクエスト時にレンダリングされるメディアユニットのみが含まれます。連続メディアの場合、それは範囲の要求された開始時間中にレンダリングされるメディアです。
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-Priorはどちらも、要求された範囲から先にメディアを提供するという要件を満たしています。ただし、RAPを使用しない限り、予測済みの方法を使用する多くのメディアコーデックのメディア品質は、たとえばすでにバッファリングされている、または他のサイドチャネルを通じて追加のデータが利用可能でない限り、著しく低下する可能性があります。
The Server general-header field contains information about the software used by the origin server to create or handle the request. This field can contain multiple product tokens and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance for identifying the application.
Server general-headerフィールドには、要求を作成または処理するために起点サーバーが使用するソフトウェアに関する情報が含まれています。このフィールドには、サーバーと重要なサブ製品を識別する複数の製品トークンとコメントを含めることができます。製品トークンは、アプリケーションを識別するために重要度の高い順にリストされています。
Example:
例：
Server: PhonyServer/1.0 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.
サーバー：PhonyServer / 1.0応答がプロキシ経由で転送されている場合、プロキシアプリケーションはサーバー応答ヘッダーを変更してはなりません。代わりに、Viaフィールドを含める必要があります（セクション18.57）。応答がプロキシーによって生成された場合、プロキシー・アプリケーションは、サーバーによって以前に返されたサーバー応答ヘッダーを返さなければなりません（MUST）。
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.
Session general-headerフィールドは、RTSPセッションを識別します。 RTSPセッションは、SETUP要求が成功した結果としてサーバーによって作成され、その応答でセッション識別子がクライアントに渡されます。 RTSPセッションは、TEARDOWNまたはREDIRECTによって破棄されるか、サーバーによってタイムアウトになるまで存在します。
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を参照）、SETUP応答で返される必要があります。クライアントがセッション識別子を受け取ったら、そのセッションに関連するすべてのリクエストに含める必要があります。つまり、次のメソッドを使用して、セッションヘッダーをリクエストに含める必要があります：PLAY、PAUSE、PLAY_NOTIFY、およびTEARDOWN。 SETUP、OPTIONS、SET_PARAMETER、GET_PARAMETER、およびREDIRECTに含まれる場合があります。 DESCRIBEに含めることはできません。これらのリクエストがパイプライン処理されていて、セッション識別子がまだ不明な場合、セッションヘッダーを次のメソッドに含めることはできません（PLAY、PAUSE、TEARDOWN、SETUP、OPTIONS SET_PARAMETER、およびGET_PARAMETER）。
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応答では、セッションヘッダーをメソッドSETUP、PLAY、PAUSE、およびPLAY_NOTIFYに含める必要があり、メソッドTEARDOWNおよびREDIRECTに含めることができます（MAY）。次のメソッドのリクエストに含まれている場合は、応答にも含まれている必要があります：OPTIONS、GET_PARAMETER、およびSET_PARAMETER。 DESCRIBE応答に含めることはできません。
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に対する複数の「ユーザー」セッションでは、異なるセッション識別子を使用する必要があります。
The session identifier is needed to distinguish several delivery requests for the same URI coming from the same client.
セッション識別子は、同じクライアントからの同じURIに対する複数の配信要求を区別するために必要です。
The response 454 (Session Not Found) MUST be returned if the session identifier is invalid.
セッション識別子が無効な場合、応答454（セッションが見つかりません）を返さなければなりません。
The header MAY include a parameter for session timeout period. If not explicitly provided, this value is set to 60 seconds. As this affects how often session keep-alives are needed, values smaller than 30 seconds are not recommended. However, larger-than-default values can be useful in applications of RTSP that have inactive but established sessions for longer time periods.
ヘッダーには、セッションタイムアウト期間のパラメーターが含まれる場合があります。明示的に指定しない場合、この値は60秒に設定されます。これは、セッションキープアライブが必要になる頻度に影響するため、30秒未満の値はお勧めしません。ただし、デフォルト値よりも大きい値は、非アクティブであるが確立されたセッションが長期間存在するRTSPのアプリケーションで役立ちます。
The 60-second value was chosen as the session timeout value as it results in keep-alive messages that are not too frequent and low sensitivity to variations in request/response timing. If one reduces the timeout value to below 30 seconds, the corresponding request/response timeout becomes a significant part of the session timeout. The 60-second value also allows for reasonably rapid recovery of committed server resources in case of client failure.
60秒の値がセッションタイムアウト値として選択されたのは、キープアライブメッセージが頻繁に発生せず、要求/応答タイミングの変動に対する感度が低くなるためです。タイムアウト値を30秒未満に減らすと、対応する要求/応答タイムアウトがセッションタイムアウトの重要な部分になります。 60秒の値では、クライアントに障害が発生した場合に、コミットされたサーバーリソースを適度に迅速に回復することもできます。
The Speed general-header field requests the server to deliver specific amounts of nominal media time per unit of delivery time, contingent on the server's ability and desire to serve the media stream at the given speed. The client requests the delivery speed to be within a given range with a lower and upper bound. The server SHALL deliver at the highest possible speed within the range, but not faster than the upper bound, for which the underlying network path can support the resulting transport data rates. As long as any speed value within the given range can be provided, the server SHALL NOT modify the media quality. Only if the server is unable to deliver media at the speed value provided by the lower bound shall it reduce the media quality.
Speed汎用ヘッダーフィールドは、サーバーに、サーバーの能力とメディアストリームを特定の速度で提供したいという要望に応じて、配信時間単位あたりの特定の量の公称メディア時間を配信するように要求します。クライアントは、配信速度が所定の範囲内に収まるように下限と上限を要求します。サーバーは、範囲内で可能な最高の速度で配信する必要がありますが、基盤となるネットワークパスが結果のトランスポートデータレートをサポートできる上限よりも速くはありません。指定された範囲内の速度値を提供できる限り、サーバーはメディア品質を変更してはなりません（SHALL NOT）。サーバーが下限によって提供される速度値でメディアを配信できない場合のみ、メディア品質を低下させます。
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を通じてサポートを示すことができます。応答に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.
速度パラメータ値は正の10進数値で表されます。たとえば、値2.0は、データが通常の2倍の速度で配信されることを示します。速度値0は無効です。範囲は、「下限-上限」の形式で指定されます。下限値は、上限値以下にすることができます。すべての速度がサポートできない場合があります。したがって、サーバーは要求された値をサポートされている最も近い値に変更してもよい（MAY）。実際にサポートされている速度を応答に含める必要があります。ただし、ユースケースは異なる場合があり、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以外の方法で）ネゴシエートされる可能性があるため、再ネゴシエーションが必要になる場合があることに注意してください。 Speed操作を実行するには、サーバーは、ネットワークパスが結果のビットレートをサポートできることを確認する必要があります。したがって、メディアトランスポートはフィードバックをサポートする必要があるため、サーバーは利用可能なビットレートに反応して適応できます。
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ヘッダーは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
S->C: RTSP/2.0 200 OK
Supported: bar, blech, baz
The Terminate-Reason request-header allows the server, when sending a REDIRECT or TEARDOWN request, to provide a reason for the session termination and any additional information. This specification identifies three reasons for Redirections and may be extended in the future:
Terminate-Reasonリクエストヘッダーを使用すると、サーバーは、REDIRECTまたはTEARDOWNリクエストを送信するときに、セッション終了の理由と追加情報を提供できます。この仕様は、リダイレクトの3つの理由を示しており、将来拡張される可能性があります。
Server-Admin: The server needs to be shut down for some administrative reason.
Server-Admin：管理上の理由でサーバーをシャットダウンする必要があります。
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.
time：サーバーがサービスの提供を停止する実時間を提供します。
user-msg: A UTF-8 text string with a message from the server to the user. This message SHOULD be displayed to the user.
user-msg：サーバーからユーザーへのメッセージを含むUTF-8テキスト文字列。このメッセージはユーザーに表示する必要があります。
The Timestamp general-header describes when the agent sent the request. The value of the timestamp is of significance only to the agent and may use any timescale. The responding agent MUST echo the exact same value and MAY, if it has accurate information about this, add a floating-point number indicating the number of seconds that has elapsed since it has received the request. The timestamp can be used by the agent to compute the round-trip time to the responding agent so that it can adjust the timeout value for retransmissions when running over an unreliable protocol. It also resolves retransmission ambiguities for unreliable transport of RTSP.
Timestamp general-headerは、エージェントがいつリクエストを送信したかを示します。タイムスタンプの値はエージェントにとってのみ重要であり、任意のタイムスケールを使用できます。応答するエージェントは正確に同じ値をエコーする必要があり、これに関する正確な情報がある場合は、リクエストを受信してから経過した秒数を示す浮動小数点数を追加できます。エージェントはこのタイムスタンプを使用して、応答するエージェントへの往復時間を計算し、信頼性の低いプロトコルで実行されている場合の再送信のタイムアウト値を調整できます。また、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メッセージの信頼できるトランスポートのみを提供することに注意してください。 Timestamp general-headerは、信頼性の低いトランスポートを使用するようにプロトコルが将来拡張される場合に備えて指定されています。
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.
トランスポートジェネラルヘッダーは、使用するトランスポートプロトコルを示し、宛先アドレス、圧縮、マルチキャストの存続時間、単一のストリームの宛先ポートなどのパラメーターを構成します。プレゼンテーションの説明でまだ決定されていない値を設定します。
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.
トランスポート要求ヘッダーには、クライアントが受け入れ可能なトランスポートオプションのリストが、複数のトランスポート指定エントリの形式で含まれている場合があります。トランスポート指定はコンマで区切られ、優先度の高い順にリストされています。各トランスポート仕様は、トランスポートプロトコル識別子と、それに続くセミコロンで区切られた任意の数のパラメータで構成されます。トランスポート要求ヘッダーには、同じトランスポートプロトコル識別子を使用する複数のトランスポート仕様を含めることができます（MAY）。サーバーは、実際に選択された値があれば、それを示すために応答でトランスポート応答ヘッダーを返さなければなりません（MUST）。トランスポート仕様がサポートされていない場合、トランスポートヘッダーは返されず、応答はステータスコード461（サポートされていないトランスポート）を使用する必要があります（セクション17.4.25）。リクエストに複数のトランスポート指定が存在する場合、サーバーは、実際に選択された単一のトランスポート指定（transport-spec）を返します（存在する場合）。クライアントはプレゼンテーションの説明から可能な構成に関するガイダンスを受け取るため、transport-specエントリの数は制限されると予想されます。
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.
トランスポートヘッダーは、後続のSETUPリクエストでもトランスポートパラメータを変更するために使用される場合があります。サーバーは、既存のストリームのパラメーターの変更を拒否してもよい（MAY）。
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 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エージェントに異なるオプションを提供するため、この柔軟性が提供されます。トランスポート仕様には、特定のパラメーターの1つのみを含めることができます。パラメータは、名前とオプションで値の文字列で構成されます。パラメータは任意の順序で指定できます。さらに、トランスポート仕様には、ユニキャストまたはマルチキャストのトランスポートタイプパラメータのみを含めることができます。トランスポートプロトコル識別子とすべてのパラメータは、トランスポート仕様で理解する必要があります。そうでない場合は、トランスポート仕様を無視する必要があります。トランスポート仕様（アクセスプロキシやセキュリティプロキシなど）を使用または変更する任意のタイプのRTSPプロキシは、RTSPメッセージを転送する前に、不明なパラメーターを持つ仕様を削除する必要があります。その結果、トランスポート指定が残っていない場合、プロキシはトランスポートヘッダーなしで461（サポートされていないトランスポート）（セクション17.4.25）応答を送信する必要があります（SHALL）。
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.
Transportヘッダーは、単一のメディアストリームの記述に制限されています。 （RTSPは、複数のストリームを単一のエンティティとして制御することもできます。）多数のセッション記述形式に依存するのではなく、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.
「lower-transport」パラメーターのデフォルト値は、プロファイルに固有です。 RTP / AVPの場合、デフォルトはUDPです。
There are two different methods for how to specify where the media should be delivered for unicast transport:
メディアをユニキャストトランスポート用に配信する場所を指定する方法には、2つの異なる方法があります。
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：このパラメータとその値の存在は、メディアトランスポートに必要な1つまたは複数の宛先アドレス（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：実際のマルチキャストグループがメディアを配信するアドレスと、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：トランスポートヘッダーに含まれる情報はすべて、SDPの「c =」および「m =」行などのセッション記述から取得できます。これにより、マルチキャストグループとスコープを選択するのはセッションプロバイダーであるため、以前の方法のセキュリティ問題の一部が軽減されます。セッションの説明で利用可能な場合、クライアントはその情報を含める必要があります。
No dest_addr: The behavior when no explicit multicast group is present in a request is not defined.
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.
ユニキャスト/マルチキャスト：このパラメーターは、ユニキャスト配信とマルチキャスト配信のどちらを試行するかを相互に排他的に示します。 2つの値のいずれかを指定する必要があります。ユニキャスト送信とマルチキャスト送信の両方を処理できるクライアントは、それぞれに個別のパラメーターを持つ2つの完全なトランスポート仕様を含めることにより、そのような機能を示す必要があります。
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.
layer：このメディアストリームに使用されるマルチキャストレイヤーの数。レイヤーは、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：1つ以上のアドレス指定を含むことができる一般的な宛先アドレスパラメータ。プロトコル/プロファイル/下位トランスポートの各組み合わせには、アドレス仕様のフォーマットと解釈を定義する必要があります。 RTP / AVP / UDPおよびRTP / AVP / TCPの場合、アドレス指定は、ホストアドレスとポートを含むタプルです。トランスポート仕様ごとに1つの宛先パラメーターのみが意図されていることに注意してください。単一のメディアを複数のエンティティに配布するための複数の宛先の使用は指定されていません。
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要求を発信するクライアントは、タプルの一部としてホストアドレスを使用して、ストリーム受信者の宛先アドレスを指定してもよい（MAY）。宛先アドレスが指定されている場合、受信者は要求の発信者とは異なる当事者である可能性があります。リモート制御のDoS攻撃の無意識の加害者にならないようにするために、サーバーはセキュリティチェック（セクション21.2.1を参照）を実行し、ログを記録する必要があります（SHOULD）
such attempts before allowing the client to direct a media stream to a recipient address not chosen by the server. Implementations cannot rely on TCP as a reliable means of client identification. If the server does not allow the host address part of the tuple to be set, it MUST return 463 (Destination Prohibited).
クライアントがサーバーによって選択されていない受信者アドレスにメディアストリームを送信する前に、このような試みを行います。実装は、クライアント識別の信頼できる手段としてTCPに依存できません。サーバーがタプルのホストアドレス部分の設定を許可しない場合は、463（宛先禁止）を返す必要があります。
The host address part of the tuple MAY be empty, for example ":58044", in cases when it is desired to specify only the destination port. Responses to requests including the Transport header with a dest_addr parameter SHOULD include the full destination address that is actually used by the server. The server MUST NOT remove address information that is already present in the request when responding, unless the protocol requires it.
宛先ポートのみを指定する必要がある場合は、タプルのホストアドレス部分を空にすることもできます（ "：58044"など）。 dest_addrパラメータ付きのトランスポートヘッダーを含むリクエストへの応答には、サーバーが実際に使用する完全な宛先アドレスを含める必要があります（SHOULD）。プロトコルで要求されない限り、サーバーは応答時に要求にすでに存在するアドレス情報を削除してはなりません（MUST NOT）。
src_addr: A general source address parameter that can contain one or more address specifications. Each combination of protocol/profile/lower transport needs to have the format and interpretation of its address specification defined. For RTP/AVP/UDP and RTP/AVP/TCP, the address specification is a tuple containing a host address and port.
src_addr：1つ以上のアドレス指定を含むことができる一般的なソースアドレスパラメータ。プロトコル/プロファイル/下位トランスポートの各組み合わせには、アドレス仕様のフォーマットと解釈を定義する必要があります。 RTP / AVP / UDPおよびRTP / AVP / TCPの場合、アドレス指定は、ホストアドレスとポートを含むタプルです。
This parameter MUST be specified by the server if it transmits media packets from an address other than the one RTSP messages are sent to. This will allow the client to verify the source address and give it a destination address for its RTCP feedback packets, if RTP is used. The address or addresses indicated in the src_addr parameter SHOULD be used both for the sending and receiving of the media stream's data packets. The main reasons are threefold: First, indicating the port and source address(s) lets the receiver know where from the packets is expected to originate. Second, traversal of NATs is greatly simplified when traffic is flowing symmetrically over a NAT binding. Third, certain NAT traversal mechanisms need to know to which address and port to send so-called "binding packets" from the receiver to the sender, thus creating an address binding in the NAT that the sender-to-receiver packet flow can use.
このパラメーターは、RTSPメッセージの送信先以外のアドレスからメディアパケットを送信する場合、サーバーで指定する必要があります。これにより、RTPが使用されている場合、クライアントは送信元アドレスを確認し、RTCPフィードバックパケットの宛先アドレスをクライアントに与えることができます。 src_addrパラメータで指定されたアドレスは、メディアストリームのデータパケットの送信と受信の両方に使用する必要があります（SHOULD）。主な理由は3つあります。1つ目は、ポートと送信元アドレスを示すことで、パケットの発信元がどこにあるかを受信者に知らせることです。次に、トラフィックがNATバインディングを介して対称的に流れる場合、NATのトラバーサルが大幅に簡素化されます。 3番目に、特定のNATトラバーサルメカニズムは、いわゆる「バインディングパケット」を受信側から送信側に送信するためのアドレスとポートを知る必要があるため、送信側から受信側へのパケットフローが使用できるアドレスバインディングをNATに作成します。
This information may also be available through SDP. However, since this is more a feature of transport than media initialization, the authoritative source for this information should be in the SETUP response.
この情報は、SDPからも入手できる場合があります。ただし、これはメディアの初期化よりもトランスポートの機能であるため、この情報の信頼できるソースはSETUP応答にあるはずです。
mode: The mode parameter indicates the methods to be supported for this session. The currently defined valid value is "PLAY". If not provided, the default is "PLAY". The "RECORD" value was defined in RFC 2326; in this specification, it is unspecified but reserved. RECORD and other values may be specified in the future.
mode：modeパラメータは、このセッションでサポートされるメソッドを示します。現在定義されている有効な値は「PLAY」です。指定しない場合、デフォルトは「PLAY」です。 「RECORD」値はRFC 2326で定義されています。この仕様では、指定されていませんが予約されています。 RECORDおよびその他の値は将来指定される可能性があります。
interleaved: The interleaved parameter implies mixing the media stream with the control stream in whatever protocol is being used by the control stream, using the mechanism defined in Section 14. The argument provides the channel number to be used in the $ block (see Section 14) and MUST be present. This parameter MAY be specified as an interval, e.g., interleaved=4-5 in cases where the transport choice for the media stream requires it, e.g., for RTP with RTCP. The channel number given in the request is only a guidance from the client to the server on what channel number(s) to use. The server MAY set any valid channel number in the response. The declared channels are bidirectional, so both end parties MAY send data on the given channel. One example of such usage is the second channel used for RTCP, where both server and client send RTCP packets on the same channel.
interleaved：interleavedパラメータは、セクション14で定義されたメカニズムを使用して、コントロールストリームで使用されているプロトコルでメディアストリームとコントロールストリームを混合することを意味します。引数は、$ブロックで使用されるチャネル番号を提供します（セクション14を参照） ）および存在する必要があります。このパラメータは、メディアストリームのトランスポート選択でRTPを使用するRTPなどで必要な場合に、たとえば、interleaved = 4-5などの間隔として指定できます。リクエストで指定されたチャネル番号は、使用するチャネル番号に関するクライアントからサーバーへのガイダンスにすぎません。サーバーは、応答で有効なチャネル番号を設定してもよい（MAY）。宣言されたチャネルは双方向であるため、両方のエンドパーティは指定されたチャネルでデータを送信できます（MAY）。そのような使用法の1つの例は、RTCPに使用される2番目のチャネルで、サーバーとクライアントの両方が同じチャネルでRTCPパケットを送信します。
This allows RTP/RTCP to be handled similarly to the way that it is done with UDP, i.e., one channel for RTP and the other for RTCP.
これにより、RTP / RTCPを、UDPを使用した場合と同様に処理できます。つまり、RTPの1つのチャネルとRTCPのもう1つのチャネルです。
MIKEY: This parameter is used in conjunction with transport specifications that can utilize MIKEY [RFC3830] for security context establishment. So far, only the SRTP-based RTP profiles SAVP and SAVPF can utilize MIKEY, and this is defined in Appendix C.1.4.1. This parameter can be included both in request and response messages. The binary MIKEY message SHALL be Base64-encoded [RFC4648] before being included in the value part of the parameter, where the encoding adheres to the definition in Section 4 of RFC 4648 and where the padding bits are set to zero.
MIKEY：このパラメータは、セキュリティコンテキストの確立にMIKEY [RFC3830]を利用できる転送仕様と組み合わせて使用されます。これまでのところ、SRTPベースのRTPプロファイルSAVPおよびSAVPFのみがMIKEYを利用でき、これは付録C.1.4.1で定義されています。このパラメーターは、要求メッセージと応答メッセージの両方に含めることができます。バイナリMIKEYメッセージは、パラメータの値部分に含まれる前に、Base64エンコード[RFC4648]である必要があります。この場合、エンコーディングはRFC 4648のセクション4の定義に従い、パディングビットはゼロに設定されます。
Multicast-specific:
マルチキャスト固有：
ttl: multicast time-to-live for IPv4. When included in requests, the value indicates the TTL value that the client requests the server to use. In a response, the value actually being used by the server is returned. A server will need to consider what values that are reasonable and also the authority of the user to set this value. Corresponding functions are not needed for IPv6 as the scoping is part of the IPv6 multicast address [RFC4291].
ttl：IPv4のマルチキャスト存続時間。リクエストに含まれている場合、この値は、クライアントがサーバーに使用を要求するTTL値を示します。応答では、サーバーによって実際に使用されている値が返されます。サーバーは、妥当な値と、この値を設定するユーザーの権限を考慮する必要があります。スコーピングはIPv6マルチキャストアドレス[RFC4291]の一部であるため、対応する関数はIPv6には必要ありません。
RTP-specific:
RTP固有：
These parameters MAY only be used if the media-transport protocol is RTP.
これらのパラメータは、メディア転送プロトコルがRTPの場合にのみ使用できます。
ssrc: The ssrc parameter, if included in a SETUP response, indicates the RTP SSRC [RFC3550] value(s) that will be used by the media server for RTP packets within the stream. The values are expressed as a slash-separated sequence of SSRC values, each SSRC expressed as an eight-digit hexadecimal value.
ssrc：ssrcパラメータは、SETUP応答に含まれている場合、ストリーム内のRTPパケット用にメディアサーバーによって使用されるRTP SSRC [RFC3550]値を示します。値は、スラッシュで区切られたSSRC値のシーケンスとして表され、各SSRCは8桁の16進数値として表されます。
The ssrc parameter MUST NOT be specified in requests. The functionality of specifying the ssrc parameter in a SETUP request is deprecated as it is incompatible with the specification of RTP [RFC3550]. If the parameter is included in the Transport header of a SETUP request, the server SHOULD ignore it, and choose appropriate SSRCs for the stream. The server SHOULD set the ssrc parameter in the Transport header of the response.
リクエストでssrcパラメータを指定してはなりません（MUST NOT）。 SETUPリクエストでssrcパラメータを指定する機能は、RTP [RFC3550]の仕様と互換性がないため非推奨です。パラメータがSETUPリクエストのトランスポートヘッダーに含まれている場合、サーバーはそれを無視し、ストリームに適切なSSRCを選択する必要があります（SHOULD）。サーバーは、応答のトランスポートヘッダーにssrcパラメータを設定する必要があります（SHOULD）。
RTCP-mux: Used to negotiate the usage of RTP and RTCP multiplexing [RFC5761] on a single underlying transport stream/flow. The presence of this parameter in a SETUP request indicates the client's support and requires the server to use RTP and RTCP multiplexing. The client SHALL only include one transport stream in the Transport header specification. To provide the server with a choice between using RTP/RTCP multiplexing or not, two different transport header specifications must be included.
RTCP-mux：基になる単一のトランスポートストリーム/フローでのRTPおよびRTCP多重化[RFC5761]の使用をネゴシエートするために使用されます。 SETUP要求にこのパラメーターが存在することは、クライアントのサポートを示し、サーバーがRTPおよびRTCP多重化を使用する必要があります。クライアントは、トランスポートヘッダー仕様に1つのトランスポートストリームのみを含める必要があります（SHALL）。 RTP / RTCP多重化を使用するかどうかの選択をサーバーに提供するには、2つの異なるトランスポートヘッダー仕様を含める必要があります。
The parameter setup and connection defined below MAY only be used if the media-transport protocol of the lower-level transport is connection oriented (such as TCP). However, these parameters MUST NOT be used when interleaving data over the RTSP connection.
以下で定義されているパラメータのセットアップと接続は、下位レベルのトランスポートのメディアトランスポートプロトコルが接続指向（TCPなど）である場合にのみ使用できます（MAY）。ただし、RTSP接続を介してデータをインターリーブする場合は、これらのパラメーターを使用しないでください。
setup: Clients use the setup parameter on the Transport line in a SETUP request to indicate the roles it wishes to play in a TCP connection. This parameter is adapted from [RFC4145]. The use of this parameter in RTP/AVP/TCP non-interleaved transport is discussed in Appendix C.2.2; the discussion below is limited to syntactic issues. Clients may specify the following values for the setup parameter:
セットアップ：クライアントは、SETUPリクエストのトランスポートラインのセットアップパラメータを使用して、TCP接続で果たす役割を示します。このパラメータは[RFC4145]から適応されます。 RTP / AVP / TCP非インターリーブトランスポートでのこのパラメーターの使用については、付録C.2.2で説明します。以下の説明は構文の問題に限定されています。クライアントは、セットアップパラメータに次の値を指定できます。
active: The client will initiate an outgoing connection.
アクティブ：クライアントは発信接続を開始します。
passive: The client will accept an incoming connection.
パッシブ：クライアントは着信接続を受け入れます。
actpass: The client is willing to accept an incoming connection or to initiate an outgoing connection.
actpass：クライアントは、着信接続を受け入れるか、発信接続を開始する用意があります。
If a client does not specify a setup value, the "active" value is assumed.
クライアントが設定値を指定しない場合、「アクティブ」値が想定されます。
In response to a client SETUP request where the setup parameter is set to "active", a server's 2xx reply MUST assign the setup parameter to "passive" on the Transport header line.
セットアップパラメータが「アクティブ」に設定されているクライアントのSETUP要求に応じて、サーバーの2xx応答は、トランスポートヘッダー行でセットアップパラメータを「パッシブ」に割り当てなければなりません（MUST）。
In response to a client SETUP request where the setup parameter is set to "passive", a server's 2xx reply MUST assign the setup parameter to "active" on the Transport header line.
セットアップパラメータが「パッシブ」に設定されているクライアントのSETUP要求に応答して、サーバーの2xx応答は、トランスポートヘッダー行でセットアップパラメータを「アクティブ」に割り当てる必要があります。
In response to a client SETUP request where the setup parameter is set to "actpass", a server's 2xx reply MUST assign the setup parameter to "active" or "passive" on the Transport header line.
セットアップパラメータが「actpass」に設定されているクライアントのSETUP要求に応答して、サーバーの2xx応答は、トランスポートヘッダー行のセットアップパラメータを「アクティブ」または「パッシブ」に割り当てなければなりません（MUST）。
Note that the "holdconn" value for setup is not defined for RTSP use, and MUST NOT appear on a Transport line.
セットアップの "holdconn"値はRTSPの使用に対して定義されておらず、トランスポートラインに表示されてはならないことに注意してください。
connection: Clients use the connection parameter in a transport specification part of the Transport header in a SETUP request to indicate the client's preference for either reusing an existing connection between client and server (in which case the client sets the "connection" parameter to "existing") or requesting the creation of a new connection between client and server (in which cast the client sets the "connection" parameter to "new"). Typically, clients use the "new" value for the first SETUP request for a URL, and "existing" for subsequent SETUP requests for a URL.
接続：クライアントは、SETUPリクエストのトランスポートヘッダーのトランスポート指定部分にある接続パラメーターを使用して、クライアントとサーバー間の既存の接続を再利用するためのクライアントの設定を示します（この場合、クライアントは「接続」パラメーターを「既存」に設定します"）または、クライアントとサーバー間の新しい接続の作成を要求します（この場合、クライアントは"接続 "パラメーターを"新規 "に設定します）。通常、クライアントは、URLの最初のSETUP要求には「新しい」値を使用し、URLの後続のSETUP要求には「既存」の値を使用します。
If a client SETUP request assigns the "new" value to "connection", the server response MUST also assign the "new" value to "connection" on the Transport line.
クライアントのSETUPリクエストが「新しい」値を「接続」に割り当てる場合、サーバーの応答も「新しい」値をトランスポートラインの「接続」に割り当てる必要があります。
If a client SETUP request assigns the "existing" value to "connection", the server response MUST assign a value of "existing" or "new" to "connection" on the Transport line, at its discretion.
クライアントのSETUPリクエストが「既存」の値を「接続」に割り当てる場合、サーバー応答は、トランスポートラインの「接続」に、その裁量で「既存」または「新規」の値を割り当てなければなりません（MUST）。
The default value of "connection" is "existing", for all SETUP requests (initial and subsequent).
「接続」のデフォルト値は、すべてのSETUP要求（初期および後続）で「既存」です。
The combination of transport protocol, profile and lower transport needs to be defined. A number of combinations are defined in the Appendix C.
トランスポートプロトコル、プロファイル、下位トランスポートの組み合わせを定義する必要があります。付録Cでは、さまざまな組み合わせが定義されています。
Below is a usage example, showing a client advertising the capability to handle multicast or unicast, preferring multicast. Since this is a unicast-only stream, the server responds with the proper transport parameters for unicast.
以下は、マルチキャストまたはユニキャストを処理する機能をアドバタイズし、マルチキャストを優先するクライアントを示す使用例です。これはユニキャストのみのストリームであるため、サーバーはユニキャストの適切なトランスポートパラメータで応答します。
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/2.0
CSeq: 302
Transport: RTP/AVP;multicast;mode="PLAY",
RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";mode="PLAY"
Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 302
Date: Fri, 20 Dec 2013 10:20:32 +0000
Session: rQi1hBrGlFdiYld241FxUO
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:3456"/
"192.0.2.5:3457";src_addr="192.0.2.224:6256"/
"192.0.2.224:6257";mode="PLAY"
Accept-Ranges: npt
Media-Properties: Random-Access=0.6, Dynamic,
Time-Limited=20081128T165900
The Unsupported response-header lists the features not supported by the responding RTSP agent. In the case where the feature was specified via the Proxy-Require field (Section 18.37), if there is a proxy on the path between the client and the server, the proxy MUST send a response message with a status code of 551 (Option Not Supported). The request MUST NOT be forwarded.
Unsupported response-headerは、応答するRTSPエージェントによってサポートされていない機能をリストします。機能がProxy-Requireフィールド（セクション18.37）で指定されている場合、クライアントとサーバー間のパスにプロキシがある場合、プロキシはステータスコード551（Option Notサポートされています）。リクエストは転送してはいけません。
See Section 18.43 for a usage example.
使用例については、セクション18.43を参照してください。
The User-Agent general-header field contains information about the user agent originating the request or producing a response. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. The field can contain multiple product tokens and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application.
User-Agent general-headerフィールドには、要求を発信したり応答を生成したりするユーザーエージェントに関する情報が含まれます。これは、統計上の目的、プロトコル違反の追跡、特定のユーザーエージェントの制限を回避するために応答を調整するためのユーザーエージェントの自動認識のためのものです。ユーザーエージェントは、リクエストにこのフィールドを含める必要があります。このフィールドには、エージェントとユーザーエージェントの重要な部分を形成するサブプロダクトを識別する複数の製品トークンとコメントを含めることができます。慣例により、製品トークンは、アプリケーションを識別するために重要度の高い順にリストされています。
Example:
例：
User-Agent: PhonyClient/1.2
ユーザーエージェント：PhonyClient / 1.2
The Via general-header field MUST be used by proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests and between the origin server and the client on responses. The field is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request/response chain.
Via general-headerフィールドは、リクエストでユーザーエージェントとサーバーの間、および応答でオリジンサーバーとクライアントの間の中間プロトコルと受信者を示すためにプロキシで使用する必要があります。このフィールドは、メッセージ転送の追跡、要求ループの回避、および要求/応答チェーンに沿ったすべての送信者のプロトコル機能の識別に使用することを目的としています。
Each of multiple values in the Via field represents each proxy that has forwarded the message. Each recipient MUST append its information such that the end result is ordered according to the sequence of forwarding applications. So messages originating with the client or server do not include the Via header. The first proxy or other intermediate adds the header and its information into the field. Any additional intermediate adds additional field-values. Resulting in the server seeing the chains of intermediates in a client-to-server request and the client seeing the full chain in the response message.
Viaフィールドの複数の値のそれぞれは、メッセージを転送した各プロキシを表します。各受信者は、転送アプリケーションのシーケンスに従って最終結果が順序付けられるように、その情報を追加する必要があります。したがって、クライアントまたはサーバーから発信されたメッセージには、Viaヘッダーは含まれません。最初のプロキシまたはその他の中間体は、ヘッダーとその情報をフィールドに追加します。追加の中間値があると、追加のフィールド値が追加されます。その結果、サーバーはクライアントからサーバーへのリクエストで中間のチェーンを確認し、クライアントは応答メッセージで完全なチェーンを確認します。
Proxies (e.g., Access Proxy or Translator Proxy) SHOULD NOT, by default, forward the names and ports of hosts within the private/ protected region. This information SHOULD only be propagated if explicitly enabled. If not enabled, the via-received of any host behind the firewall/NAT SHOULD be replaced by an appropriate pseudonym for that host.
プロキシ（アクセスプロキシやトランスレータプロキシなど）は、デフォルトでは、プライベート/保護リージョン内のホストの名前とポートを転送しないでください。この情報は、明示的に有効化されている場合にのみ伝達されるべきです（SHOULD）。有効になっていない場合、ファイアウォール/ NATの背後にあるホストのvia-receivedは、そのホストの適切な仮名に置き換えられる必要があります（SHOULD）。
For organizations that have strong privacy requirements for hiding internal structures, a proxy MAY combine an ordered subsequence of Via header field entries with identical sent-protocol values into a single such entry. Applications MUST NOT combine entries that have different received-protocol values.
内部構造を非表示にするための強力なプライバシー要件がある組織の場合、プロキシは、Viaヘッダーフィールドエントリの順序付けられたサブシーケンスを、同一の送信プロトコル値と組み合わせて、そのような単一のエントリにすることができます（MAY）。アプリケーションは、異なる受信プロトコル値を持つエントリを組み合わせてはなりません（MUST NOT）。
The WWW-Authenticate header is specified in [RFC7235]; its usage depends on the used authentication schemes, such as Digest [RFC7616] and Basic [RFC7617]. The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field-value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI. This header MUST only be used in response messages related to client to server requests.
WWW-Authenticateヘッダーは[RFC7235]で指定されています。その使用法は、ダイジェスト[RFC7616]や基本[RFC7617]などの使用されている認証方式に依存します。 WWW-Authenticate応答ヘッダーフィールドは、401（無許可）応答メッセージに含まれている必要があります。 field-valueは、Request-URIに適用可能な認証スキームとパラメーターを示す少なくとも1つのチャレンジで構成されます。このヘッダーは、クライアントからサーバーへの要求に関連する応答メッセージでのみ使用する必要があります。
The HTTP access authentication process is described in [RFC7235] with some clarification in Section 19.1. User agents are advised to take special care in parsing the WWW-Authenticate field-value as it might contain more than one challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a comma-separated list of authentication parameters.
HTTPアクセス認証プロセスは[RFC7235]で説明されており、セクション19.1である程度明確化されています。ユーザーエージェントは、WWW-Authenticateフィールド値の解析に特別な注意を払うことをお勧めします。複数のチャレンジが含まれている可能性があるか、複数のWWW-Authenticateヘッダーフィールドが提供されている場合、チャレンジ自体の内容にコンマが含まれている可能性があるためです認証パラメーターの分離リスト。
The RTSP security framework consists of two high-level components: the pure authentication mechanisms based on HTTP authentication and the message transport protection based on TLS, which is independent of RTSP. Because of the similarity in syntax and usage between RTSP servers and HTTP servers, the security for HTTP is reused to a large extent.
RTSPセキュリティフレームワークは、HTTP認証に基づく純粋な認証メカニズムと、RTSPに依存しないTLSに基づくメッセージ転送保護の2つの高レベルコンポーネントで構成されています。 RTSPサーバーとHTTPサーバーの構文と使用法は類似しているため、HTTPのセキュリティは大幅に再利用されます。
RTSP and HTTP share common authentication schemes; thus, they follow the same framework as specified in [RFC7235]. RTSP uses the corresponding RTSP error codes (401 and 407) and headers (WWW-Authenticate, Authorization, Proxy-Authenticate, Proxy-Authorization) by importing the definitions from [RFC7235]. Servers SHOULD implement both the Basic [RFC7617] and the Digest [RFC7616] authentication schemes. Clients MUST implement both the Basic and the Digest authentication schemes so that a server that requires the client to authenticate can trust that the capability is present. If implementing the Digest authentication scheme, then the additional considerations specified below in Section 19.1.1 MUST be followed.
RTSPとHTTPは共通の認証スキームを共有します。したがって、それらは[RFC7235]で指定されたのと同じフレームワークに従います。 RTSPは、[RFC7235]から定義をインポートすることにより、対応するRTSPエラーコード（401および407）およびヘッダー（WWW-Authenticate、Authorization、Proxy-Authenticate、Proxy-Authorization）を使用します。サーバーは、基本[RFC7617]とダイジェスト[RFC7616]の両方の認証スキームを実装する必要があります（SHOULD）。クライアントは、基本認証方式とダイジェスト認証方式の両方を実装する必要があるため、クライアントに認証を要求するサーバーは、機能が存在することを信頼できます。ダイジェスト認証スキームを実装する場合は、以下のセクション19.1.1で指定されている追加の考慮事項に従う必要があります。
It should be stressed that using the HTTP authentication alone does not provide full RTSP message security. Therefore, TLS SHOULD be used; see Section 19.2. Any RTSP message containing an Authorization header using the Basic authentication scheme MUST be using a TLS connection with confidentiality protection enabled, i.e., no NULL encryption.
HTTP認証のみを使用しても、RTSPメッセージの完全なセキュリティは提供されないことを強調しておく必要があります。したがって、TLSを使用する必要があります（SHOULD）。セクション19.2を参照してください。基本認証スキームを使用するAuthorizationヘッダーを含むRTSPメッセージは、機密保護が有効になっている、つまりNULL暗号化なしのTLS接続を使用している必要があります。
In cases where there is a chain of proxies between the client and the server, each proxy may individually request the client or previous proxy to authenticate itself. This is done using the Proxy-Authenticate (Section 18.34), the Proxy-Authorization (Section 18.36), and the Proxy-Authentication-Info (Section 18.35) headers. These headers are hop-by-hop headers and are only scoped to the current connection and hop. Thus, if a proxy chain exists, a proxy connecting to another proxy will have to act as a client to authorize itself towards the next proxy. The WWW-Authenticate (Section 18.58), Authorization (Section 18.8), and Authentication-Info (Section 18.7) headers are end-to-end and MUST NOT be modified by proxies.
クライアントとサーバーの間にプロキシのチェーンがある場合、各プロキシはクライアントまたは以前のプロキシにそれ自体を認証するように個別に要求します。これは、Proxy-Authenticate（セクション18.34）、Proxy-Authorization（セクション18.36）、およびProxy-Authentication-Info（セクション18.35）ヘッダーを使用して行われます。これらのヘッダーはホップバイホップのヘッダーであり、現在の接続とホップにのみスコープされます。したがって、プロキシチェーンが存在する場合、別のプロキシに接続するプロキシは、次のプロキシに向けて自身を承認するクライアントとして機能する必要があります。 WWW-Authenticate（セクション18.58）、Authorization（セクション18.8）、およびAuthentication-Info（セクション18.7）ヘッダーはエンドツーエンドであり、プロキシによって変更してはなりません（MUST NOT）。
This authentication mechanism works only for client-to-server requests as currently defined. This leaves server-to-client request outside of the context of TLS-based communication more vulnerable to message-injection attacks on the client. Based on the server-to-client methods that exist, the potential risks are various: hijacking (REDIRECT), denial of service (TEARDOWN and PLAY_NOTIFY), or attacks with uncertain results (SET_PARAMETER).
この認証メカニズムは、現在定義されているクライアントからサーバーへの要求に対してのみ機能します。これにより、TLSベースの通信のコンテキスト外のサーバーからクライアントへの要求が、クライアントへのメッセージインジェクション攻撃に対してより脆弱になります。存在するサーバーからクライアントへの方法に基づいて、潜在的なリスクはさまざまです：ハイジャック（REDIRECT）、サービス拒否（TEARDOWNおよびPLAY_NOTIFY）、または不確実な結果を伴う攻撃（SET_PARAMETER）。
This section describes the modifications and clarifications required to apply the HTTP Digest authentication scheme to RTSP. The RTSP scheme usage is almost completely identical to that for HTTP [RFC7616]. These modifications are based on the procedures defined for SIP 2.0 [RFC3261] (in Section 22.4) but updated to use RFC 7235, RFC 7616 and RFC 7615 instead of RFC 2617.
このセクションでは、HTTPダイジェスト認証スキームをRTSPに適用するために必要な変更と説明について説明します。 RTSPスキームの使用法は、HTTP [RFC7616]の使用法とほぼ完全に同じです。これらの変更は、SIP 2.0 [RFC3261]（セクション22.4）で定義された手順に基づいていますが、RFC 2617の代わりにRFC 7235、RFC 7616、およびRFC 7615を使用するように更新されています。
Digest authentication uses two additional headers, Authentication-Info and Proxy-Authentication-Info, that are defined as in [RFC7615]. The rules for Digest authentication follow those defined in [RFC7616], with "HTTP/1.1" replaced by "RTSP/2.0" in addition to the following differences:
ダイジェスト認証は、[RFC7615]で定義されている2つの追加ヘッダー、Authentication-InfoおよびProxy-Authentication-Infoを使用します。ダイジェスト認証のルールは、[RFC7616]で定義されているルールに従い、以下の違いに加えて、「HTTP / 1.1」が「RTSP / 2.0」に置き換えられています。
1. Use the ABNF specified in the referenced documents, with the difference that the URI parameter uses the request URI format for RTSP, i.e. the ABNF element: Request-URI (see Section 20.2.1). The domain parameter uses the RTSP-URI-Ref element for absolute and relative URIs.
1. 参照ドキュメントで指定されているABNFを使用します。ただし、URIパラメーターはRTSPの要求URI形式、つまりABNF要素：Request-URIを使用する点が異なります（セクション20.2.1を参照）。ドメインパラメータは、絶対および相対URIにRTSP-URI-Ref要素を使用します。
2. If MTags are used, then the example procedure for choosing a nonce based on ETag can work, based on replacing the ETag with the MTag.
2. MTagが使用されている場合、ETagをMTagで置き換えることに基づいて、ETagに基づいてnonceを選択する手順の例が機能します。
3. As a clarification to the calculation of the A2 value for message integrity assurance in the Digest authentication scheme, implementers should assume, when the entity-body is empty (that is, when the RTSP messages have no message body) that the hash of the message body resolves to the hash of an empty string, or: H(entity-body), example MD5("") = "d41d8cd98f00b204e9800998ecf8427e".
3. ダイジェスト認証方式でのメッセージ整合性保証のA2値の計算の明確化として、実装者は、エンティティボディが空の場合（つまり、RTSPメッセージにメッセージボディがない場合）、メッセージのハッシュを想定する必要があります。 bodyは空の文字列のハッシュに解決されます。または、H（entity-body）、例MD5（ ""）= "d41d8cd98f00b204e9800998ecf8427e"のようになります。
RTSP agents MUST implement RTSP over TLS as defined in this section and the next Section 19.3. RTSP MUST follow the same guidelines with regard to TLS [RFC5246] usage as specified for HTTP; see [RFC2818]. RTSP over TLS is separated from unsecured RTSP both on the URI level and the port level. Instead of using the "rtsp" scheme identifier in the URI, the "rtsps" scheme identifier MUST be used to signal RTSP over TLS. If no port is given in a URI with the "rtsps" scheme, port 322 MUST be used for TLS over TCP/IP.
RTSPエージェントは、このセクションと次のセクション19.3で定義されているように、RTSP over TLSを実装する必要があります。 RTSPは、HTTP [RFC5246]の使用に関して、HTTPで指定されているのと同じガイドラインに従う必要があります。 [RFC2818]を参照してください。 RTSP over TLSは、URIレベルとポートレベルの両方で、保護されていないRTSPから分離されています。 URIで「rtsp」スキーム識別子を使用する代わりに、「rtsps」スキーム識別子を使用して、TLS経由でRTSPをシグナリングする必要があります。 「rtsps」スキームのURIでポートが指定されていない場合、TCP / IP上のTLSにはポート322を使用する必要があります。
When a client tries to set up an insecure channel to the server (using the "rtsp" URI), and the policy for the resource requires a secure channel, the server MUST redirect the client to the secure service by sending a 301 redirect response code together with the correct Location URI (using the "rtsps" scheme). A user or client MAY upgrade a non secured URI to a secured by changing the scheme from "rtsp" to "rtsps". A server implementing support for "rtsps" MUST allow this.
クライアントが（ "rtsp" URIを使用して）安全でないチャネルをサーバーに設定しようとし、リソースのポリシーが安全なチャネルを要求する場合、サーバーは301リダイレクト応答コードを送信してクライアントを安全なサービスにリダイレクトする必要があります正しいロケーションURIとともに（「rtsps」スキームを使用）。ユーザーまたはクライアントは、スキームを「rtsp」から「rtsps」に変更することにより、非セキュアなURIをセキュアなURIにアップグレードできます。 「rtsps」のサポートを実装するサーバーは、これを許可する必要があります。
It should be noted that TLS allows for mutual authentication (when using both server and client certificates). Still, one of the more common ways TLS is used is to provide only server-side authentication (often to avoid client certificates). TLS is then used in addition to HTTP authentication, providing transport security and server authentication, while HTTP Authentication is used to authenticate the client.
TLSでは相互認証が可能です（サーバー証明書とクライアント証明書の両方を使用する場合）。それでも、TLSが使用される最も一般的な方法の1つは、サーバー側の認証のみを提供することです（多くの場合、クライアント証明書を回避するため）。次に、HTTP認証に加えてTLSが使用され、トランスポートセキュリティとサーバー認証が提供されます。一方、クライアントの認証にはHTTP認証が使用されます。
RTSP includes the possibility to keep a TCP session up between the client and server, throughout the RTSP session lifetime. It may be convenient to keep the TCP session, not only to save the extra setup time for TCP, but also the extra setup time for TLS (even if TLS uses the resume function, there will be almost two extra round trips). Still, when TLS is used, such behavior introduces extra active state in the server, not only for TCP and RTSP, but also for TLS. This may increase the vulnerability to DoS attacks.
RTSPには、RTSPセッションの存続期間を通じて、クライアントとサーバー間のTCPセッションを維持する可能性が含まれています。 TCPの追加のセットアップ時間を節約するだけでなく、TLSの追加のセットアップ時間も節約するために、TCPセッションを維持することは便利かもしれません（TLSが再開機能を使用する場合でも、ほぼ2つの追加のラウンドトリップがあります）。それでも、TLSが使用されている場合、そのような動作により、TCPとRTSPだけでなくTLSでもサーバーに余分なアクティブ状態が発生します。これにより、DoS攻撃に対する脆弱性が増加する可能性があります。
There exists a potential security vulnerability when reusing TCP and TLS state for different resources (URIs). If two different hostnames point at the same IP address, it can be desirable to reuse the TCP/ TLS connection to that server. In that case, the RTSP agent having the TCP/TLS connection MUST verify that the server certificate associated with the connection has a SubjectAltName matching the hostname present in the URI for the resource an RTSP request is to be issued.
異なるリソース（URI）に対してTCPとTLSの状態を再利用する際に、潜在的なセキュリティの脆弱性が存在します。 2つの異なるホスト名が同じIPアドレスを指している場合、そのサーバーへのTCP / TLS接続を再利用することが望ましい場合があります。その場合、TCP / TLS接続を持つRTSPエージェントは、接続に関連付けられたサーバー証明書に、RTSP要求が発行されるリソースのURIに存在するホスト名と一致するSubjectAltNameがあることを確認する必要があります。
In addition to these recommendations, Section 19.3 gives further recommendations of TLS usage with proxies.
これらの推奨事項に加えて、セクション19.3では、プロキシを使用したTLSの使用に関するさらなる推奨事項を示しています。
The nature of a proxy is often to act as a "man in the middle", while security is often about preventing the existence of one. This section provides clients with the possibility to use proxies even when applying secure transports (TLS) between the RTSP agents. The TLS proxy mechanism allows for server and proxy identification using certificates. However, the client cannot be identified based on certificates. The client needs to select between using the procedure specified below or using a TLS connection directly (bypassing any proxies) to the server. The choice may be dependent on policies.
プロキシの性質は、多くの場合、「中間者」として機能することですが、セキュリティは、プロキシの存在を防ぐことを目的としています。このセクションでは、RTSPエージェント間でセキュアなトランスポート（TLS）を適用する場合でも、プロキシを使用する可能性をクライアントに提供します。 TLSプロキシメカニズムでは、証明書を使用してサーバーとプロキシを識別できます。ただし、証明書に基づいてクライアントを識別することはできません。クライアントは、以下に示す手順を使用するか、サーバーへのTLS接続を直接（プロキシをバイパスして）使用するかを選択する必要があります。選択はポリシーに依存する場合があります。
In general, there are two categories of proxies: the transparent proxies (of which the client is not aware) and the non-transparent proxies (of which the client is aware). This memo specifies only non-transparent RTSP proxies, i.e., proxies visible to the RTSP client and RTSP server. An infrastructure based on proxies requires that the trust model be such that both client and server can trust the proxies to handle the RTSP messages correctly. To be able to trust a proxy, the client and server also need to be aware of the proxy. Hence, transparent proxies cannot generally be seen as trusted and will not work well with security (unless they work only at the transport layer). In the rest of this section, any reference to "proxy" will be to a non-transparent proxy, which inspects or manipulates the RTSP messages.
一般に、プロキシには2つのカテゴリがあります。透過的なプロキシ（クライアントが認識していない）と非透過的なプロキシ（クライアントが認識している）です。このメモは、非透過的なRTSPプロキシ、つまりRTSPクライアントとRTSPサーバーから見えるプロキシのみを指定しています。プロキシに基づくインフラストラクチャでは、RTSPメッセージを正しく処理するためにクライアントとサーバーの両方がプロキシを信頼できるような信頼モデルである必要があります。プロキシを信頼できるようにするには、クライアントとサーバーもプロキシを認識する必要があります。したがって、トランスペアレントプロキシは通常、信頼できると見なすことはできず、（トランスポート層でのみ機能する場合を除いて）セキュリティでうまく機能しません。このセクションの残りの部分では、「プロキシ」への参照はすべて、RTSPメッセージを検査または操作する非透過プロキシを指します。
HTTP Authentication is built on the assumption of proxies and can provide user-proxy authentication and proxy-proxy/server authentication in addition to the client-server authentication.
HTTP認証は、プロキシを想定して構築されており、クライアント/サーバー認証に加えて、ユーザー/プロキシ認証とプロキシ/プロキシ認証を提供できます。
When TLS is applied and a proxy is used, the client will connect to the proxy's address when connecting to any RTSP server. This implies that for TLS, the client will authenticate the proxy server and not the end server. Note that when the client checks the server certificate in TLS, it MUST check the proxy's identity (URI or possibly other known identity) against the proxy's identity as presented in the proxy's Certificate message.
TLSが適用され、プロキシが使用されている場合、クライアントはRTSPサーバーに接続するときにプロキシのアドレスに接続します。これは、TLSの場合、クライアントがエンドサーバーではなくプロキシサーバーを認証することを意味します。クライアントがTLSでサーバー証明書をチェックするとき、プロキシの証明書メッセージで提示されているように、プロキシのアイデンティティ（URIまたはおそらく他の既知のアイデンティティ）をプロキシのアイデンティティと照合しなければならないことに注意してください。
The problem is that for a proxy accepted by the client, the proxy needs to be provided information on which grounds it should accept the next-hop certificate. Both the proxy and the user may have rules for this, and the user should have the possibility to select the desired behavior. To handle this case, the Accept-Credentials header (see Section 18.2) is used, where the client can request the proxy or proxies to relay back the chain of certificates used to authenticate any intermediate proxies as well as the server. The assumption that the proxies are viewed as trusted gives the user a possibility to enforce policies on each trusted proxy of whether it should accept the next agent in the chain. However, it should be noted that not all deployments will return the chain of certificates used to authenticate any intermediate proxies as well as the server. An operator of such a deployment may want to hide its topology from the client. It should be noted well that the client does not have any insight into the proxy's operation. Even if the proxy is trusted, it can still return an incomplete chain of certificates.
問題は、クライアントによって受け入れられたプロキシの場合、ネクストホップ証明書を受け入れる根拠に関する情報をプロキシに提供する必要があることです。プロキシとユーザーの両方にこれに関するルールがあり、ユーザーは希望する動作を選択できる可能性があります。このケースを処理するには、Accept-Credentialsヘッダー（セクション18.2を参照）を使用します。クライアントはプロキシまたはプロキシに要求して、サーバーだけでなく中間プロキシの認証に使用される証明書のチェーンをリレーバックできます。プロキシが信頼できるものと見なされるという前提により、ユーザーは、信頼できるプロキシごとに、チェーン内の次のエージェントを受け入れるかどうかのポリシーを適用する可能性があります。ただし、すべての展開が、サーバーだけでなく中間プロキシの認証に使用される証明書のチェーンを返すわけではないことに注意してください。そのようなデプロイメントのオペレーターは、そのトポロジーをクライアントから隠したい場合があります。クライアントはプロキシの操作をまったく理解していないことに注意してください。プロキシが信頼されている場合でも、不完全な証明書チェーンを返す可能性があります。
A proxy MUST use TLS for the next hop if the RTSP request includes an "rtsps" URI. TLS MAY be applied on intermediate links (e.g., between client and proxy or between proxy and proxy) even if the resource and the end server are not required to use it. The chain of proxies used by a client to reach a server and its TLS sessions MUST have commensurate security. Therefore, a proxy MUST, when initiating the next-hop TLS connection, use the incoming TLS connections cipher-suite list, only modified by removing any cipher suites that the proxy does not support. In case a proxy fails to establish a TLS connection due to cipher-suite mismatch between proxy and next-hop proxy or server, this is indicated using error code 472 (Failure to Establish Secure Connection).
RTSP要求に「rtsps」URIが含まれている場合、プロキシはネクストホップにTLSを使用する必要があります。リソースとエンドサーバーがTLSを使用する必要がない場合でも、TLSは中間リンク（クライアントとプロキシの間、またはプロキシとプロキシの間など）に適用できます（MAY）。クライアントがサーバーに到達するために使用する一連のプロキシとそのTLSセッションは、相応のセキュリティを備えている必要があります。したがって、プロキシは、ネクストホップTLS接続を開始するときに、プロキシがサポートしない暗号スイートを削除することによってのみ変更される、着信TLS接続の暗号スイートリストを使用する必要があります。プロキシとネクストホッププロキシまたはサーバーの間の暗号スイートの不一致によりプロキシがTLS接続の確立に失敗した場合、これはエラーコード472（Failure to Establish Secure Connection）を使用して示されます。
The Accept-Credentials header can be used by the client to distribute simple authorization policies to intermediate proxies. The client includes the Accept-Credentials header to dictate how the proxy treats the server / next proxy certificate. There are currently three methods defined:
クライアントはAccept-Credentialsヘッダーを使用して、単純な承認ポリシーを中間プロキシに配布できます。クライアントにはAccept-Credentialsヘッダーが含まれており、プロキシーがサーバー/次のプロキシー証明書を処理する方法を指示します。現在、3つのメソッドが定義されています。
Any: With "any", the proxy (or proxies) MUST accept whatever certificate is presented. Of course, this is not a recommended option to use, but it may be useful in certain circumstances (such as testing).
Any：「any」の場合、プロキシ（またはプロキシ）は、提示された証明書をすべて受け入れる必要があります。もちろん、これは推奨されるオプションではありませんが、特定の状況（テストなど）で役立つ場合があります。
Proxy: For the "proxy" method, the proxy (or proxies) MUST use its own policies to validate the certificate and decide whether or not to accept it. This is convenient in cases where the user has a strong trust relation with the proxy. Reasons why a strong trust relation may exist are personal/company proxy or the proxy has an out-of-band policy configuration mechanism.
プロキシ：「プロキシ」メソッドの場合、プロキシ（またはプロキシ）は独自のポリシーを使用して証明書を検証し、それを受け入れるかどうかを決定する必要があります。これは、ユーザーがプロキシとの強い信頼関係を持っている場合に便利です。強力な信頼関係が存在する理由は、個人/会社のプロキシであるか、プロキシに帯域外ポリシー構成メカニズムがあるためです。
User: For the "user" method, the proxy (or proxies) MUST send credential information about the next hop to the client for authorization. The client can then decide whether or not the proxy should accept the certificate. See Section 19.3.2 for further details.
ユーザー：「ユーザー」メソッドの場合、プロキシー（またはプロキシー）は、許可のためにクライアントにネクスト・ホップに関する資格情報を送信する必要があります。クライアントは、プロキシが証明書を受け入れるかどうかを決定できます。詳細は19.3.2項を参照してください。
If the Accept-Credentials header is not included in the RTSP request from the client, then the "Proxy" method MUST be used as default. If a method other than the "Proxy" is to be used, then the Accept-Credentials header MUST be included in all of the RTSP requests from the client. This is because it cannot be assumed that the proxy always keeps the TLS state or the user's previous preference between different RTSP messages (in particular, if the time interval between the messages is long).
Accept-CredentialsヘッダーがクライアントからのRTSPリクエストに含まれていない場合、「プロキシ」メソッドをデフォルトとして使用する必要があります。 「プロキシ」以外の方法を使用する場合は、クライアントからのすべてのRTSP要求にAccept-Credentialsヘッダーを含める必要があります。これは、プロキシが常に異なるRTSPメッセージ間でTLS状態またはユーザーの以前の設定を維持するとは想定できないためです（特に、メッセージ間の時間間隔が長い場合）。
With the "Any" and "Proxy" methods, the proxy will apply the policy as defined for each method. If the policy does not accept the credentials of the next hop, the proxy MUST respond with a message using status code 471 (Connection Credentials Not Accepted).
「Any」および「Proxy」メソッドを使用すると、プロキシは各メソッドに定義されているポリシーを適用します。ポリシーがネクストホップの資格情報を受け入れない場合、プロキシはステータスコード471（接続資格情報が受け入れられない）を使用してメッセージで応答する必要があります。
An RTSP request in the direction server to client MUST NOT include the Accept-Credentials header. As for the non-secured communication, the possibility for these requests depends on the presence of a client established connection. However, if the server-to-client request is in relation to a session established over a TLS secured channel, it MUST be sent in a TLS secured connection. That secured connection MUST also be the one used by the last client-to-server request. If no such transport connection exists at the time when the server desires to send the request, the server MUST discard the message.
サーバーからクライアントへの方向でのRTSP要求には、Accept-Credentialsヘッダーを含めてはなりません（MUST NOT）。非セキュア通信に関しては、これらの要求の可能性は、クライアントが確立した接続の存在に依存します。ただし、サーバーからクライアントへの要求がTLSで保護されたチャネルを介して確立されたセッションに関連している場合は、TLSで保護された接続で送信する必要があります。その保護された接続は、最後のクライアントからサーバーへの要求で使用されたものでもある必要があります。サーバーがリクエストを送信したいときにそのようなトランスポート接続が存在しない場合、サーバーはメッセージを破棄しなければなりません（MUST）。
Further policies MAY be defined and registered, but this should be done with caution.
追加のポリシーを定義および登録できますが、これは注意して行う必要があります。
For the "User" method, each proxy MUST perform the following procedure for each RTSP request:
「ユーザー」メソッドの場合、各プロキシは各RTSP要求に対して次の手順を実行する必要があります。
o Set up the TLS session to the next hop if not already present (i.e., run the TLS handshake, but do not send the RTSP request).
o TLSセッションがまだ存在しない場合は、次のホップへのTLSセッションを設定します（つまり、TLSハンドシェイクを実行しますが、RTSP要求を送信しません）。
o Extract the peer certificate chain for the TLS session.
o TLSセッションのピア証明書チェーンを抽出します。
o Check if a matching identity and hash of the peer certificate are present in the Accept-Credentials header. If present, send the message to the next hop and conclude these procedures. If not, go to the next step.
o 一致するIDとピア証明書のハッシュがAccept-Credentialsヘッダーに存在するかどうかを確認します。存在する場合は、メッセージを次のホップに送信し、これらの手順を完了します。そうでない場合は、次の手順に進みます。
o The proxy responds to the RTSP request with a 470 or 407 response code. The 407 response code MAY be used when the proxy requires both user and connection authorization from user or client. In this message the proxy MUST include a Connection-Credentials header, see Section 18.13, with the next hop's identity and certificate.
o プロキシは、RTSP要求に470または407応答コードで応答します。プロキシーがユーザーとクライアントまたはユーザーからの接続承認の両方を必要とする場合、407応答コードが使用される場合があります。このメッセージでは、プロキシにConnection-Credentialsヘッダーを含める必要があります（セクション18.13を参照）。ネクストホップのIDと証明書が必要です。
The client MUST upon receiving a 470 (Connection Authorization Required) or 407 (Proxy Authentication Required) response with Connection-Credentials header take the decision on whether or not to accept the certificate (if it cannot do so, the user SHOULD be consulted). Using IP addresses in the next-hop URI and certificates rather than domain names makes it very difficult for a user to determine whether or not it should approve the next hop. Proxies are RECOMMENDED to use domain names to identify themselves in URIs and in the certificates. If the certificate is accepted, the client has to again send the RTSP request. In that request, the client has to include the Accept-Credentials header including the hash over the DER-encoded certificate for all trusted proxies in the chain.
クライアントは、Connection-Credentialsヘッダーを含む470（接続許可が必要）または407（プロキシ認証が必要）の応答を受信すると、証明書を受け入れるかどうかを決定する必要があります（受け入れられない場合は、ユーザーに相談する必要があります）。ドメイン名ではなくネクストホップURIと証明書でIPアドレスを使用すると、ユーザーがネクストホップを承認する必要があるかどうかを判断することが非常に困難になります。プロキシは、URIおよび証明書でドメイン名を使用して自身を識別することをお勧めします。証明書が受け入れられた場合、クライアントはRTSP要求を再度送信する必要があります。その要求では、チェーン内のすべての信頼できるプロキシのDERエンコードされた証明書にハッシュを含むAccept-Credentialsヘッダーをクライアントに含める必要があります。
Example:
例：
C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 2
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589"
Accept-Ranges: npt, smpte, clock
Accept-Credentials: User
P->C: RTSP/2.0 470 Connection Authorization Required CSeq: 2 Connection-Credentials: "rtsps://test.example.org"; MIIDNTCCAp...
P-> C：RTSP / 2.0 470接続許可が必要CSeq：2つの接続資格情報： "rtsps：//test.example.org"; MIIDNTCCAp ...
C->P: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 3
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589"
Accept-Credentials: User "rtsps://test.example.org";sha-256;
dPYD7txpoGTbAqZZQJ+vaeOkyH4=
Accept-Ranges: npt, smpte, clock
P->S: SETUP rtsps://test.example.org/secret/audio RTSP/2.0
CSeq: 3
Transport: RTP/AVP;unicast;dest_addr="192.0.2.5:4588"/
"192.0.2.5:4589"
Via: RTSP/2.0 proxy.example.org
Accept-Credentials: User "rtsps://test.example.org";sha-256;
dPYD7txpoGTbAqZZQJ+vaeOkyH4=
Accept-Ranges: npt, smpte, clock
One implication of this process is that the connection for secured RTSP messages may take significantly more round-trip times for the first message. A complete extra message exchange between the proxy connecting to the next hop and the client results because of the process for approval for each hop. However, if each message contains the chain of proxies that the requester accepts, the remaining message exchange should not be delayed. The procedure of including the credentials in each request rather than building state in each proxy avoids the need for revocation procedures.
このプロセスの影響の1つは、保護されたRTSPメッセージの接続で、最初のメッセージのラウンドトリップ時間が大幅に長くなる可能性があることです。各ホップの承認プロセスのため、ネクストホップに接続するプロキシとクライアント間の完全な追加メッセージ交換が行われます。ただし、各メッセージにリクエスターが受け入れるプロキシのチェーンが含まれている場合、残りのメッセージ交換は遅延されません。各プロキシで状態を構築するのではなく、各要求に資格情報を含める手順により、失効手順の必要がなくなります。
The RTSP syntax is described in an Augmented Backus-Naur Form (ABNF) as defined in RFC 5234 [RFC5234]. It uses the basic definitions present in RFC 5234.
RTSP構文は、RFC 5234 [RFC5234]で定義されているように、拡張バッカスナウアフォーム（ABNF）で記述されています。 RFC 5234にある基本的な定義を使用します。
Please note that ABNF strings, e.g., "Accept", are case insensitive as specified in Section 2.3 of RFC 5234.
RFC 5234のセクション2.3で指定されているように、「Accept」などのABNF文字列は大文字と小文字が区別されないことに注意してください。
The RTSP syntax makes use of the ISO 10646 character set in UTF-8 encoding [RFC3629].
RTSP構文は、UTF-8エンコーディング[RFC3629]でISO 10646文字セットを利用します。
RTSP header values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear whitespace, including folding, has the same semantics as SP. A recipient MAY replace any linear whitespace with a single SP before interpreting the field-value or forwarding the message downstream. The SWS construct is used when linear whitespace is optional, generally between tokens and separators.
継続行がスペースまたは水平タブで始まる場合、RTSPヘッダー値は複数行に折りたたむことができます。折りたたみを含むすべての線形空白は、SPと同じセマンティクスを持っています。受信者は、フィールド値を解釈したり、メッセージをダウンストリームに転送したりする前に、任意の線形空白を単一のSPで置き換えてもよい（MAY）。 SWSコンストラクトは、線形の空白がオプションの場合に使用されます。通常、トークンとセパレータの間です。
To separate the header name from the rest of value, a colon is used, which, by the above rule, allows whitespace before, but no line break, and whitespace after, including a line break. The HCOLON defines this construct.
ヘッダー名を残りの値から分離するために、コロンが使用されます。これは、上記のルールにより、前に空白を許可しますが、改行は含めず、後に空白を許可します。 HCOLONはこの構成を定義します。
OCTET = %x00-FF ; any 8-bit sequence of data
CHAR = %x01-7F ; any US-ASCII character (octets 1 - 127)
UPALPHA = %x41-5A ; any US-ASCII uppercase letter "A".."Z"
LOALPHA = %x61-7A ; any US-ASCII lowercase letter "a".."z"
ALPHA = UPALPHA / LOALPHA
DIGIT = %x30-39 ; any US-ASCII digit "0".."9"
CTL = %x00-1F / %x7F ; any US-ASCII control character
; (octets 0 - 31) and DEL (127)
CR = %x0D ; US-ASCII CR, carriage return (13)
LF = %x0A ; US-ASCII LF, linefeed (10)
SP = %x20 ; US-ASCII SP, space (32)
HT = %x09 ; US-ASCII HT, horizontal-tab (9)
BACKSLASH = %x5C ; US-ASCII backslash (92)
CRLF = CR LF
LWS = [CRLF] 1*( SP / HT ) ; Line-breaking whitespace
SWS = [LWS] ; Separating whitespace
HCOLON = *( SP / HT ) ":" SWS
TEXT = %x20-7E / %x80-FF ; any OCTET except CTLs
tspecials = "(" / ")" / "<" / ">" / "@"
/ "," / ";" / ":" / BACKSLASH / DQUOTE
/ "/" / "[" / "]" / "?" / "="
/ "{" / "}" / SP / HT
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7A / %x7C / %x7E)
; 1*<any CHAR except CTLs or tspecials>
quoted-string = ( DQUOTE *qdtext DQUOTE ) qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair
/ UTF8-NONASCII
; No DQUOTE and no "\"
quoted-pair = "\\" / ( "\" DQUOTE )
ctext = %x20-27 / %x2A-7E
/ %x80-FF ; any OCTET except CTLs, "(" and ")"
generic-param = token [ EQUAL gen-value ]
gen-value = token / host / quoted-string
safe = "$" / "-" / "_" / "." / "+"
extra = "!" / "*" / "'" / "(" / ")" / ","
rtsp-extra = "!" / "*" / "'" / "(" / ")"
HEX = DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
/ "a" / "b" / "c" / "d" / "e" / "f"
LHEX = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
; lowercase "a-f" Hex
reserved = ";" / "/" / "?" / ":" / "@" / "&" / "="
unreserved = ALPHA / DIGIT / safe / extra
rtsp-unreserved = ALPHA / DIGIT / safe / rtsp-extra
base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = (2base64-char "==") / (3base64-char "=")
base64-char = ALPHA / DIGIT / "+" / "/"
SLASH = SWS "/" SWS ; slash
EQUAL = SWS "=" SWS ; equal
LPAREN = SWS "(" SWS ; left parenthesis
RPAREN = SWS ")" SWS ; right parenthesis
COMMA = SWS "," SWS ; comma
SEMI = SWS ";" SWS ; semicolon
COLON = SWS ":" SWS ; colon
MINUS = SWS "-" SWS ; minus/dash
LDQUOT = SWS DQUOTE ; open double quotation mark
RDQUOT = DQUOTE SWS ; close double quotation mark
RAQUOT = ">" SWS ; right angle quote
LAQUOT = SWS "<" ; left angle quote
TEXT-UTF8char = %x21-7E / UTF8-NONASCII
UTF8-NONASCII = UTF8-2 / UTF8-3 / UTF8-4
UTF8-1 = <As defined in RFC 3629>
UTF8-2 = <As defined in RFC 3629>
UTF8-3 = <As defined in RFC 3629>
UTF8-4 = <As defined in RFC 3629>
UTF8-tail = <As defined in RFC 3629>
POS-FLOAT = 1*12DIGIT ["." 1*9DIGIT]
FLOAT = ["-"] POS-FLOAT
RTSP-IRI = schemes ":" IRI-rest
IRI-rest = ihier-part [ "?" iquery ]
ihier-part = "//" iauthority ipath-abempty
RTSP-IRI-ref = RTSP-IRI / irelative-ref
irelative-ref = irelative-part [ "?" iquery ]
irelative-part = "//" iauthority ipath-abempty
/ ipath-absolute
/ ipath-noscheme
/ ipath-empty
iauthority = < As defined in RFC 3987>
ipath = ipath-abempty ; begins with "/" or is empty
/ ipath-absolute ; begins with "/" but not "//"
/ ipath-noscheme ; begins with a non-colon segment
/ ipath-rootless ; begins with a segment
/ ipath-empty ; zero characters
ipath-abempty = *( "/" isegment )
ipath-absolute = "/" [ isegment-nz *( "/" isegment ) ]
ipath-noscheme = isegment-nz-nc *( "/" isegment )
ipath-rootless = isegment-nz *( "/" isegment )
ipath-empty = 0<ipchar>
isegment = *ipchar [";" *ipchar] isegment-nz = 1*ipchar [";" *ipchar] / ";" *ipchar isegment-nz-nc = (1*ipchar-nc [";" *ipchar-nc]) / ";" *ipchar-nc ; non-zero-length segment without any colon ":" ; No parameter (; delimited) inside path.
isegment = * ipchar [";" * ipchar] isegment-nz = 1 * ipchar [";" * ipchar] / ";" * ipchar isegment-nz-nc =（1 * ipchar-nc [";" * ipchar-nc]）/ ";" * ipchar-nc;コロンのない長さがゼロでないセグメント "：";パス内にパラメーターはありません（;区切り）。
ipchar = iunreserved / pct-encoded / sub-delims / ":" / "@"
ipchar-nc = iunreserved / pct-encoded / sub-delims / "@"
; sub-delims is different from RFC 3987
; not including ";"
iquery = < As defined in RFC 3987>
iunreserved = < As defined in RFC 3987>
pct-encoded = < As defined in RFC 3987>
RTSP-URI = schemes ":" URI-rest
RTSP-REQ-URI = schemes ":" URI-req-rest
RTSP-URI-Ref = RTSP-URI / RTSP-Relative
RTSP-REQ-Ref = RTSP-REQ-URI / RTSP-REQ-Rel
schemes = "rtsp" / "rtsps" / scheme
scheme = < As defined in RFC 3986>
URI-rest = hier-part [ "?" query ]
URI-req-rest = hier-part [ "?" query ]
; Note fragment part not allowed in requests
hier-part = "//" authority path-abempty
RTSP-Relative = relative-part [ "?" query ]
RTSP-REQ-Rel = relative-part [ "?" query ]
relative-part = "//" authority path-abempty
/ path-absolute
/ path-noscheme
/ path-empty
authority = < As defined in RFC 3986>
query = < As defined in RFC 3986>
path = path-abempty ; begins with "/" or is empty
/ path-absolute ; begins with "/" but not "//"
/ path-noscheme ; begins with a non-colon segment
/ path-rootless ; begins with a segment
/ path-empty ; zero characters
path-abempty = *( "/" segment )
path-absolute = "/" [ segment-nz *( "/" segment ) ]
path-noscheme = segment-nz-nc *( "/" segment )
path-rootless = segment-nz *( "/" segment )
path-empty = 0<pchar>
segment = *pchar [";" *pchar] segment-nz = ( 1*pchar [";" *pchar]) / (";" *pchar) segment-nz-nc = ( 1*pchar-nc [";" *pchar-nc]) / (";" *pchar-nc) ; non-zero-length segment without any colon ":" ; No parameter (; delimited) inside path.
セグメント= * pchar [";" * pchar]セグメント-nz =（1 * pchar [";" * pchar]）/（ ";" * pchar）セグメント-nz-nc =（1 * pchar-nc [";" * pchar-nc]）/ （ ";" * pchar-nc）;コロンのない長さがゼロでないセグメント "：";パス内にパラメーターはありません（;区切り）。
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
pchar-nc = unreserved / pct-encoded / sub-delims / "@"
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / "="
; sub-delims is different from RFC 3986/3987
; not including ";"
smpte-range = smpte-type [EQUAL smpte-range-spec]
; See section 4.4
smpte-range-spec = ( smpte-time "-" [ smpte-time ] )
/ ( "-" smpte-time )
smpte-type = "smpte" / "smpte-30-drop"
/ "smpte-25" / smpte-type-extension
; other timecodes may be added
smpte-type-extension = "smpte" token
smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT
[ ":" 1*2DIGIT [ "." 1*2DIGIT ] ]
npt-range = "npt" [EQUAL npt-range-spec]
npt-range-spec = ( npt-time "-" [ npt-time ] ) / ( "-" npt-time )
npt-time = "now" / npt-sec / npt-hhmmss / npt-hhmmss-comp
npt-sec = 1*19DIGIT [ "." 1*9DIGIT ]
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." 1*9DIGIT ]
npt-hh = 2*19DIGIT ; any positive number
npt-mm = 2*2DIGIT ; 0-59
npt-ss = 2*2DIGIT ; 0-59
npt-hhmmss-comp = npt-hh-comp ":" npt-mm-comp ":" npt-ss-comp
[ "." 1*9DIGIT ] ; Compatibility format
npt-hh-comp = 1*19DIGIT ; any positive number
npt-mm-comp = 1*2DIGIT ; 0-59
npt-ss-comp = 1*2DIGIT ; 0-59
utc-range = "clock" [EQUAL utc-range-spec]
utc-range-spec = ( utc-time "-" [ utc-time ] ) / ( "-" utc-time )
utc-time = utc-date "T" utc-clock "Z"
utc-date = 8DIGIT
utc-clock = 6DIGIT [ "." 1*9DIGIT ]
feature-tag = token
機能タグ=トークン
session-id = 1*256( ALPHA / DIGIT / safe )
extension-header = header-name HCOLON header-value
header-name = token
header-value = *(TEXT-UTF8char / LWS)
RTSP-message = Request / Response ; RTSP/2.0 messages
Request = Request-Line *((general-header / request-header / message-body-header) CRLF) CRLF [ message-body-data ]
Request = Request-Line *（（general-header / request-header / message-body-header）CRLF）CRLF [message-body-data]
Response = Status-Line *((general-header / response-header / message-body-header) CRLF) CRLF [ message-body-data ]
Response = Status-Line *（（general-header / response-header / message-body-header）CRLF）CRLF [message-body-data]
Request-Line = Method SP Request-URI SP RTSP-Version CRLF
Request-Line =メソッドSP Request-URI SP RTSP-Version CRLF
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
Method = "DESCRIBE" / "GET_PARAMETER" / "OPTIONS" / "PAUSE" / "PLAY" / "PLAY_NOTIFY" / "REDIRECT" / "SETUP" / "SET_PARAMETER" / "TEARDOWN" / extension-method
メソッド= "DESCRIBE" / "GET_PARAMETER" / "OPTIONS" / "PAUSE" / "PLAY" / "PLAY_NOTIFY" / "REDIRECT" / "SETUP" / "SET_PARAMETER" / "TEARDOWN" / extension-method
extension-method = token
extension-method = token
Request-URI = "*" / RTSP-REQ-URI
RTSP-Version = "RTSP/" 1*DIGIT "." 1*DIGIT
message-body-data = 1*OCTET
メッセージ本体データ= 1 * OCTET
Status-Code = "100" ; Continue
/ "200" ; OK
/ "301" ; Moved Permanently
/ "302" ; Found
/ "303" ; See Other
/ "304" ; Not Modified
/ "305" ; Use Proxy
/ "400" ; Bad Request
/ "401" ; Unauthorized
/ "402" ; Payment Required
/ "403" ; Forbidden
/ "404" ; Not Found
/ "405" ; Method Not Allowed
/ "406" ; Not Acceptable
/ "407" ; Proxy Authentication Required
/ "408" ; Request Timeout
/ "410" ; Gone
/ "412" ; Precondition Failed
/ "413" ; Request Message Body Too Large
/ "414" ; Request-URI Too Long
/ "415" ; Unsupported Media Type
/ "451" ; Parameter Not Understood
/ "452" ; reserved
/ "453" ; Not Enough Bandwidth
/ "454" ; Session Not Found
/ "455" ; Method Not Valid In This State
/ "456" ; Header Field Not Valid for Resource
/ "457" ; Invalid Range
/ "458" ; Parameter Is Read-Only
/ "459" ; Aggregate Operation Not Allowed
/ "460" ; Only Aggregate Operation Allowed
/ "461" ; Unsupported Transport
/ "462" ; Destination Unreachable
/ "463" ; Destination Prohibited
/ "464" ; Data Transport Not Ready Yet
/ "465" ; Notification Reason Unknown
/ "466" ; Key Management Error
/ "470" ; Connection Authorization Required
/ "471" ; Connection Credentials Not Accepted
/ "472" ; Failure to Establish Secure Connection
/ "500" ; Internal Server Error
/ "501" ; Not Implemented
/ "502" ; Bad Gateway
/ "503" ; Service Unavailable
/ "504" ; Gateway Timeout
/ "505" ; RTSP Version Not Supported
/ "551" ; Option Not Supported
/ "553" ; Proxy Unavailable
/ extension-code
extension-code = 3DIGIT
拡張コード= 3DIGIT
Reason-Phrase = 1*(TEXT-UTF8char / HT / SP) rtsp-header = general-header
/ request-header
/ response-header
/ message-body-header
general-header = Accept-Ranges / Cache-Control / Connection / CSeq / Date / Media-Properties / Media-Range / Pipelined-Requests / Proxy-Supported / Range / RTP-Info / Scale / Seek-Style / Server / Session / Speed / Supported / Timestamp / Transport / User-Agent / Via / extension-header
general-header = Accept-Ranges / Cache-Control / Connection / CSeq / Date / Media-Properties / Media-Range / Pipelined-Requests / Proxy-Supported / Range / RTP-Info / Scale / Seek-Style / Server / Session /速度/サポートされている/タイムスタンプ/トランスポート/ユーザーエージェント/経由/拡張ヘッダー
request-header = Accept / Accept-Credentials / Accept-Encoding / Accept-Language / Authorization / Bandwidth / Blocksize / From / If-Match / If-Modified-Since / If-None-Match / Notify-Reason / Proxy-Authorization / Proxy-Require / Referrer / Request-Status / Require / Terminate-Reason / extension-header
request-header = Accept / Accept-Credentials / Accept-Encoding / Accept-Language / Authorization / Bandwidth / Blocksize / From / If-Match / If-Modified-Since / If-None-Match / Notify-Reason / Proxy-Authorization / Proxy-Require / Referrer / Request-Status / Require / Terminate-Reason / extension-header
response-header = Authentication-Info / Connection-Credentials / Location / MTag / Proxy-Authenticate / Proxy-Authentication-Info / Public / Retry-After / Unsupported / WWW-Authenticate / extension-header
response-header = Authentication-Info / Connection-Credentials / Location / MTag / Proxy-Authenticate / Proxy-Authentication-Info / Public / Retry-After / Unsupported / WWW-Authenticate / extension-header
message-body-header = Allow / Content-Base / Content-Encoding / Content-Language / Content-Length / Content-Location / Content-Type / Expires / Last-Modified / extension-header
message-body-header = Allow / Content-Base / Content-Encoding / Content-Language / Content-Length / Content-Location / Content-Type / Expires / Last-Modified / extension-header
Accept = "Accept" HCOLON
[ accept-range *(COMMA accept-range) ]
accept-range = media-type-range [SEMI accept-params]
media-type-range = ( "*/*"
/ ( m-type SLASH "*" )
/ ( m-type SLASH m-subtype )
) *( SEMI m-parameter )
accept-params = "q" EQUAL qvalue *(SEMI generic-param )
qvalue = ( "0" [ "." *3DIGIT ] )
/ ( "1" [ "." *3("0") ] )
Accept-Credentials = "Accept-Credentials" HCOLON cred-decision
cred-decision = ("User" [LWS cred-info])
/ "Proxy"
/ "Any"
/ (token [LWS 1*header-value])
; For future extensions
cred-info = cred-info-data *(COMMA cred-info-data)
cred-info-data = DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg SEMI base64 hash-alg = "sha-256" / extension-alg extension-alg = token Accept-Encoding = "Accept-Encoding" HCOLON
cred-info-data = DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg SEMI base64 hash-alg = "sha-256" / extension-alg extension-alg = token Accept-Encoding = "Accept-Encoding" HCOLON
[ encoding *(COMMA encoding) ]
encoding = codings [SEMI accept-params]
codings = content-coding / "*"
content-coding = "identity" / token
Accept-Language = "Accept-Language" HCOLON
language *(COMMA language)
language = language-range [SEMI accept-params]
language-range = language-tag / "*"
language-tag = primary-tag *( "-" subtag )
primary-tag = 1*8ALPHA
subtag = 1*8ALPHA
Accept-Ranges = "Accept-Ranges" HCOLON acceptable-ranges
acceptable-ranges = (range-unit *(COMMA range-unit))
range-unit = "npt" / "smpte" / "smpte-30-drop" / "smpte-25"
/ "clock" / extension-format
extension-format = token
Allow = "Allow" HCOLON Method *(COMMA Method)
Authentication-Info = "Authentication-Info" HCOLON auth-param-list
auth-param-list = <As the Authentication-Info element in RFC 7615>
Authorization = "Authorization" HCOLON credentials
credentials = <As defined by RFC 7235>
Bandwidth = "Bandwidth" HCOLON 1*19DIGIT
帯域幅= "帯域幅" HCOLON 1 * 19DIGIT
Blocksize = "Blocksize" HCOLON 1*9DIGIT
ブロックサイズ= "ブロックサイズ" HCOLON 1 * 9DIGIT
Cache-Control = "Cache-Control" HCOLON cache-directive *(COMMA cache-directive) cache-directive = cache-rqst-directive / cache-rspns-directive
Cache-Control = "Cache-Control" HCOLON cache-directive *（COMMA cache-directive）cache-directive = cache-rqst-directive / cache-rspns-directive
cache-rqst-directive = "no-cache" / "max-stale" [EQUAL delta-seconds] / "min-fresh" EQUAL delta-seconds / "only-if-cached" / cache-extension
cache-rqst-directive = "no-cache" / "max-stale" [EQUAL delta-seconds] / "min-fresh" EQUAL delta-seconds / "only-if-cached" / cache-extension
cache-rspns-directive = "public" / "private" / "no-cache" / "no-transform" / "must-revalidate" / "proxy-revalidate" / "max-age" EQUAL delta-seconds / cache-extension
cache-rspns-directive = "public" / "private" / "no-cache" / "no-transform" / "must-revalidate" / "proxy-revalidate" / "max-age" EQUAL delta-seconds / cache-拡張
cache-extension = token [EQUAL (token / quoted-string)]
delta-seconds = 1*19DIGIT Connection = "Connection" HCOLON connection-token
*(COMMA connection-token)
connection-token = "close" / token
Connection-Credentials = "Connection-Credentials" HCOLON cred-chain cred-chain = DQUOTE RTSP-REQ-URI DQUOTE SEMI base64
Connection-Credentials = "Connection-Credentials" HCOLON cred-chain cred-chain = DQUOTE RTSP-REQ-URI DQUOTE SEMI base64
Content-Base = "Content-Base" HCOLON RTSP-URI
Content-Encoding = "Content-Encoding" HCOLON
content-coding *(COMMA content-coding)
Content-Language = "Content-Language" HCOLON
language-tag *(COMMA language-tag)
Content-Length = "Content-Length" HCOLON 1*19DIGIT
Content-Location = "Content-Location" HCOLON RTSP-REQ-Ref
Content-Type = "Content-Type" HCOLON media-type
media-type = m-type SLASH m-subtype *(SEMI m-parameter)
m-type = discrete-type / composite-type
discrete-type = "text" / "image" / "audio" / "video"
/ "application" / extension-token
composite-type = "message" / "multipart" / extension-token
extension-token = ietf-token / x-token
ietf-token = token
x-token = "x-" token
m-subtype = extension-token / iana-token
iana-token = token
m-parameter = m-attribute EQUAL m-value
m-attribute = token
m-value = token / quoted-string
CSeq = "CSeq" HCOLON cseq-nr
cseq-nr = 1*9DIGIT
Date = "Date" HCOLON RTSP-date
RTSP-date = date-time ;
date-time = <As defined in RFC 5322>
Expires = "Expires" HCOLON RTSP-date
From = "From" HCOLON from-spec
from-spec = ( name-addr / addr-spec ) *( SEMI from-param )
name-addr = [ display-name ] LAQUOT addr-spec RAQUOT
addr-spec = RTSP-REQ-URI / absolute-URI
absolute-URI = < As defined in RFC 3986>
display-name = *(token LWS) / quoted-string
from-param = tag-param / generic-param
tag-param = "tag" EQUAL token
If-Match = "If-Match" HCOLON ("*" / message-tag-list)
message-tag-list = message-tag *(COMMA message-tag)
message-tag = [ weak ] opaque-tag
weak = "W/"
opaque-tag = quoted-string If-Modified-Since = "If-Modified-Since" HCOLON RTSP-date
If-None-Match = "If-None-Match" HCOLON ("*" / message-tag-list)
Last-Modified = "Last-Modified" HCOLON RTSP-date
Location = "Location" HCOLON RTSP-REQ-URI
Media-Properties = "Media-Properties" HCOLON [media-prop-list]
media-prop-list = media-prop-value *(COMMA media-prop-value)
media-prop-value = ("Random-Access" [EQUAL POS-FLOAT])
/ "Beginning-Only"
/ "No-Seeking"
/ "Immutable"
/ "Dynamic"
/ "Time-Progressing"
/ "Unlimited"
/ ("Time-Limited" EQUAL utc-time)
/ ("Time-Duration" EQUAL POS-FLOAT)
/ ("Scales" EQUAL scale-value-list)
/ media-prop-ext
media-prop-ext = token [EQUAL (1*rtsp-unreserved / quoted-string)]
scale-value-list = DQUOTE scale-entry *(COMMA scale-entry) DQUOTE
scale-entry = scale-value / (scale-value COLON scale-value)
scale-value = FLOAT
Media-Range = "Media-Range" HCOLON [ranges-list]
ranges-list = ranges-spec *(COMMA ranges-spec)
MTag = "MTag" HCOLON message-tag
Notify-Reason = "Notify-Reason" HCOLON Notify-Reas-val
Notify-Reas-val = "end-of-stream"
/ "media-properties-update"
/ "scale-change"
/ Notify-Reason-extension
Notify-Reason-extension = token
Pipelined-Requests = "Pipelined-Requests" HCOLON startup-id
startup-id = 1*8DIGIT
Proxy-Authenticate = "Proxy-Authenticate" HCOLON challenge-list
challenge-list = <As defined by the WWW-Authenticate in RFC 7235>
Proxy-Authentication-Info = "Proxy-Authentication-Info" HCOLON
auth-param-list
Proxy-Authorization = "Proxy-Authorization" HCOLON credentials
Proxy-Require = "Proxy-Require" HCOLON feature-tag-list
feature-tag-list = feature-tag *(COMMA feature-tag)
Proxy-Supported = "Proxy-Supported" HCOLON [feature-tag-list]
Public = "Public" HCOLON Method *(COMMA Method)
Range = "Range" HCOLON ranges-spec
範囲= "範囲" HCOLON範囲-仕様
ranges-spec = npt-range / utc-range / smpte-range
/ range-ext
range-ext = extension-format [EQUAL range-value]
range-value = 1*(rtsp-unreserved / quoted-string / ":" )
Referrer = "Referrer" HCOLON (absolute-URI / RTSP-URI-Ref)
Request-Status = "Request-Status" HCOLON req-status-info
req-status-info = cseq-info LWS status-info LWS reason-info
cseq-info = "cseq" EQUAL cseq-nr
status-info = "status" EQUAL Status-Code
reason-info = "reason" EQUAL DQUOTE Reason-Phrase DQUOTE
Require = "Require" HCOLON feature-tag-list RTP-Info = "RTP-Info" HCOLON [rtsp-info-spec
*(COMMA rtsp-info-spec)]
rtsp-info-spec = stream-url 1*ssrc-parameter
stream-url = "url" EQUAL DQUOTE RTSP-REQ-Ref DQUOTE
ssrc-parameter = LWS "ssrc" EQUAL ssrc HCOLON
ri-parameter *(SEMI ri-parameter)
ri-parameter = ("seq" EQUAL 1*5DIGIT)
/ ("rtptime" EQUAL 1*10DIGIT)
/ generic-param
Retry-After = "Retry-After" HCOLON (RTSP-date / delta-seconds)
Scale = "Scale" HCOLON scale-value
Seek-Style = "Seek-Style" HCOLON Seek-S-values
Seek-S-values = "RAP"
/ "CoRAP"
/ "First-Prior"
/ "Next"
/ Seek-S-value-ext
Seek-S-value-ext = token
Server = "Server" HCOLON ( product / comment )
*(LWS (product / comment))
product = token [SLASH product-version]
product-version = token
comment = LPAREN *( ctext / quoted-pair) RPAREN
Session = "Session" HCOLON session-id [ SEMI "timeout" EQUAL delta-seconds ]
セッション= "Session" HCOLON session-id [SEMI "timeout" EQUAL delta-seconds]
Speed = "Speed" HCOLON lower-bound MINUS upper-bound lower-bound = POS-FLOAT upper-bound = POS-FLOAT
速度= "速度" HCOLON下限MINUS上限下限= POS-FLOAT上限= POS-FLOAT
Supported = "Supported" HCOLON [feature-tag-list] Terminate-Reason = "Terminate-Reason" HCOLON TR-Info
TR-Info = TR-Reason *(SEMI TR-Parameter)
TR-Reason = "Session-Timeout"
/ "Server-Admin"
/ "Internal-Error"
/ token
TR-Parameter = TR-time / TR-user-msg / generic-param
TR-time = "time" EQUAL utc-time
TR-user-msg = "user-msg" EQUAL quoted-string
Timestamp = "Timestamp" HCOLON timestamp-value [LWS delay]
timestamp-value = *19DIGIT [ "." *9DIGIT ]
delay = *9DIGIT [ "." *9DIGIT ]
Transport = "Transport" HCOLON transport-spec
*(COMMA transport-spec)
transport-spec = transport-id *trns-parameter
transport-id = trans-id-rtp / other-trans
trans-id-rtp = "RTP/" profile ["/" lower-transport]
; no LWS is allowed inside transport-id
other-trans = token *("/" token) profile = "AVP" / "SAVP" / "AVPF" / "SAVPF" / token
lower-transport = "TCP" / "UDP" / token
trns-parameter = (SEMI ( "unicast" / "multicast" ))
/ (SEMI "interleaved" EQUAL channel ["-" channel])
/ (SEMI "ttl" EQUAL ttl)
/ (SEMI "layers" EQUAL 1*DIGIT)
/ (SEMI "ssrc" EQUAL ssrc *(SLASH ssrc))
/ (SEMI "mode" EQUAL mode-spec)
/ (SEMI "dest_addr" EQUAL addr-list)
/ (SEMI "src_addr" EQUAL addr-list)
/ (SEMI "setup" EQUAL contrans-setup)
/ (SEMI "connection" EQUAL contrans-con)
/ (SEMI "RTCP-mux")
/ (SEMI "MIKEY" EQUAL MIKEY-Value)
/ (SEMI trn-param-ext)
contrans-setup = "active" / "passive" / "actpass"
contrans-con = "new" / "existing"
trn-param-ext = par-name [EQUAL trn-par-value]
par-name = token
trn-par-value = *(rtsp-unreserved / quoted-string)
ttl = 1*3DIGIT ; 0 to 255
ssrc = 8HEX
channel = 1*3DIGIT ; 0 to 255
MIKEY-Value = base64
mode-spec = ( DQUOTE mode *(COMMA mode) DQUOTE )
mode = "PLAY" / token
addr-list = quoted-addr *(SLASH quoted-addr)
quoted-addr = DQUOTE (host-port / extension-addr) DQUOTE
host-port = ( host [":" port] )
/ ( ":" port )
extension-addr = 1*qdtext
host = < As defined in RFC 3986>
port = < As defined in RFC 3986>
Unsupported = "Unsupported" HCOLON feature-tag-list
User-Agent = "User-Agent" HCOLON ( product / comment )
*(LWS (product / comment))
Via = "Via" HCOLON via-parm *(COMMA via-parm)
via-parm = sent-protocol LWS sent-by *( SEMI via-params )
via-params = via-ttl / via-maddr
/ via-received / via-extension
via-ttl = "ttl" EQUAL ttl
via-maddr = "maddr" EQUAL host
via-received = "received" EQUAL (IPv4address / IPv6address)
IPv4address = < As defined in RFC 3986>
IPv6address = < As defined in RFC 3986>
via-extension = generic-param
sent-protocol = protocol-name SLASH protocol-version
SLASH transport-prot
protocol-name = "RTSP" / token
protocol-version = token
transport-prot = "UDP" / "TCP" / "TLS" / other-transport
other-transport = token
sent-by = host [ COLON port ]
WWW-Authenticate = "WWW-Authenticate" HCOLON challenge-list
WWW-Authenticate = "WWW-Authenticate" HCOLONチャレンジリスト
This section defines in ABNF the SDP extensions defined for RTSP. See Appendix D for the definition of the extensions in text.
このセクションでは、RTNF用に定義されたSDP拡張をABNFで定義します。テキスト内の拡張子の定義については、付録Dを参照してください。
control-attribute = "a=control:" *SP RTSP-REQ-Ref CRLF
a-range-def = "a=range:" ranges-spec CRLF
a-mtag-def = "a=mtag:" message-tag CRLF
The security considerations and threats around RTSP and its usage can be divided into considerations around the signaling protocol itself and the issues related to the media-stream delivery. However, when it comes to mitigation of security threats, a threat depending on the media-stream delivery may in fact be mitigated by a mechanism in the signaling protocol.
RTSPとその使用に関するセキュリティの考慮事項と脅威は、シグナリングプロトコル自体に関する考慮事項と、メディアストリーム配信に関連する問題に分けられます。ただし、セキュリティの脅威の軽減に関しては、メディアストリーム配信に依存する脅威は、実際にはシグナリングプロトコルのメカニズムによって軽減される場合があります。
There are several chapters and an appendix in this document that define security solutions for the protocol. These sections will be referenced when discussing the threats below. However, the reader should take special notice of the Security Framework (Section 19) and the specification of how to use SRTP and its key-management (Appendix C.1.4) to achieve certain aspects of the media security.
このドキュメントには、プロトコルのセキュリティソリューションを定義するいくつかの章と付録があります。これらのセクションは、以下の脅威について説明するときに参照されます。ただし、メディアセキュリティの特定の側面を実現するために、読者はセキュリティフレームワーク（セクション19）およびSRTPとそのキー管理（付録C.1.4）の使用方法の仕様に特別な注意を払う必要があります。
This section focuses on issues related to the signaling protocol. Because of the similarity in syntax and usage between RTSP servers and HTTP servers, the security considerations outlined in [RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235] apply as well.
このセクションでは、シグナリングプロトコルに関連する問題に焦点を当てています。 RTSPサーバーとHTTPサーバーの構文と使用法は類似しているため、[RFC7230]、[RFC7231]、[RFC7232]、[RFC7233]、[RFC7234]、および[RFC7235]で概説されているセキュリティの考慮事項も適用されます。
Specifically, please note the following:
具体的には、次の点に注意してください。
Abuse of Server Log Information: A server is in the position to save personal data about a user's requests that might identify their media consumption patterns or subjects of interest. This information is clearly confidential in nature, and its handling can be constrained by law in certain countries. Log information needs to be securely stored and appropriate guidelines followed for its analysis. See Section 9.8 of [RFC7230] for additional guidelines.
サーバーログ情報の悪用：サーバーは、ユーザーのメディア消費パターンや関心のある対象を特定する可能性のあるユーザーのリクエストに関する個人データを保存する立場にあります。この情報は本質的に明らかに機密情報であり、特定の国では法律によりその取り扱いが制限される場合があります。ログ情報は安全に保管し、適切なガイドラインに従って分析する必要があります。追加のガイドラインについては、[RFC7230]のセクション9.8を参照してください。
Transfer of Sensitive Information: There is no reason to believe that information transferred in RTSP message, such as the URI and the content of headers, especially the Server, Via, Referrer, and From headers, may be any less sensitive than when used in HTTP. Therefore, all of the precautions regarding the protection of data privacy and user privacy apply to implementers of RTSP clients, servers, and proxies. See Sections 9.3-9.6 of [RFC7231] for further details.
機密情報の転送：RTSPメッセージで転送される情報（URIやヘッダーのコンテンツ、特にServer、Via、Referer、およびFromヘッダーなど）は、HTTPで使用する場合よりも機密性が低くなる可能性があると信じる理由はありません。 。したがって、データのプライバシーとユーザーのプライバシーの保護に関するすべての予防措置は、RTSPクライアント、サーバー、およびプロキシの実装者に適用されます。詳細については、[RFC7231]のセクション9.3〜9.6を参照してください。
The RTSP methods defined in this document are primarily used to establish and control the delivery of the media data represented by the URI; thus, the RTSP message bodies are generally less sensitive than the ones in HTTP. Where HTTP bodies could contain, for example, your medical records, in RTSP, the sensitive video of your medical operation would be in the media stream over the media-transport protocol, not in the RTSP message. Still, one has to take note of what potential sensitive information is included in RTSP. The protection of the media data is separate, can be applied directly between client and server, and is dependent on the media-transport protocol in use. See Section 21.2 for further discussion. This possibility for separation of security between media- resource content and the signaling protocol mitigates the risk of exposing the media content when using hop-by-hop security for RTSP signaling using proxies (Section 19.3).
このドキュメントで定義されているRTSPメソッドは、主に、URIで表されるメディアデータの配信を確立および制御するために使用されます。したがって、RTSPメッセージの本文は、通常、HTTPのものよりも感度が低くなります。たとえば、HTTPボディにRTSPの医療記録が含まれる可能性がある場合、医療行為の機密ビデオは、RTSPメッセージではなく、メディア転送プロトコルを介したメディアストリームに含まれます。それでも、RTSPに含まれる可能性のある機密情報に注意する必要があります。メディアデータの保護は独立しており、クライアントとサーバー間で直接適用でき、使用中のメディア転送プロトコルに依存します。詳細については、セクション21.2を参照してください。メディアリソースコンテンツとシグナリングプロトコルの間でセキュリティを分離するこの可能性は、プロキシを使用したRTSPシグナリングにホップバイホップセキュリティを使用するときにメディアコンテンツを公開するリスクを軽減します（セクション19.3）。
Attacks Based On File and Path Names: Though RTSP URIs are opaque handles that do not necessarily have file-system semantics, it is anticipated that many implementations will translate portions of the Request-URIs directly to file-system calls. In such cases, file systems SHOULD follow the precautions outlined in Section 9.1 of [RFC7231], such as checking for ".." in path components.
ファイル名とパス名に基づく攻撃：RTSP URIは不透明なハンドルであり、必ずしもファイルシステムのセマンティクスは必要ありませんが、多くの実装ではRequest-URIの一部を直接ファイルシステムの呼び出しに変換することが予想されます。このような場合、ファイルシステムは、[RFC7231]のセクション9.1で概説されている予防措置（パスコンポーネントの「..」のチェックなど）に従う必要があります（SHOULD）。
Personal Information: RTSP clients are often privy to the same information that HTTP clients are (username, location, etc.) and thus should be equally sensitive. See Section 9.8 of [RFC7230], Sections 9.3-9.7 of [RFC7231], and Section 8 of [RFC7234] for further recommendations.
個人情報：RTSPクライアントは、HTTPクライアントと同じ情報（ユーザー名、場所など）を知っていることが多いため、同様に機密性が必要です。さらなる推奨事項については、[RFC7230]のセクション9.8、[RFC7231]のセクション9.3〜9.7、および[RFC7234]のセクション8を参照してください。
Privacy Issues Connected to Accept Headers: Since similar usages of the "Accept" headers exist in RTSP as in HTTP, the same caveats outlined in Section 9.4 of [RFC7231] with regard to their use should be followed.
Acceptヘッダーに関連するプライバシーの問題：RTSPでもHTTPと同様の「Accept」ヘッダーの使用法が存在するため、[RFC7231]のセクション9.4で概説されているものと同じ注意事項に従ってください。
Establishing Authority: RTSP shares with HTTP the question of how a client communicates with the authoritative source for media streams (Section 9.1 of [RFC7230]). The used DNS servers, the security of the communication, and any possibility of a man in the middle, and the trust in any RTSP proxies all affect the possibility that a client has received a non-authoritative response to a request. Ensuring that a client receives an authoritative response is challenging, although using the secure communication for RTSP signaling (rtsps) simplifies it significantly as the server can provide a hostname identity assertion in the TLS handshake.
権限の確立：RTSPは、クライアントがメディアストリームの信頼できるソースとどのように通信するかという質問をHTTPと共有します（[RFC7230]のセクション9.1）。使用されているDNSサーバー、通信のセキュリティ、中間者の可能性、RTSPプロキシへの信頼はすべて、クライアントが要求に対して権限のない応答を受け取った可能性に影響を与えます。サーバーがTLSハンドシェイクでホスト名IDアサーションを提供できるため、RTSPシグナリング（rtsps）に安全な通信を使用すると、クライアントを信頼できる応答を確実に受信することは非常に簡単になります。
Location Headers and Spoofing: If a single server supports multiple organizations that do not trust each another, then it MUST check the values of the Content-Location header fields in responses that are generated under control of said organizations to make sure that they do not attempt to invalidate resources over which they have no authority (see Section 15.4 of [RFC2616]).
ロケーションヘッダーとスプーフィング：単一のサーバーが相互に信頼しない複数の組織をサポートしている場合、その組織の制御下で生成された応答のContent-Locationヘッダーフィールドの値をチェックして、それらが試行しないことを確認する必要があります。権限を持たないリソースを無効にするため（[RFC2616]のセクション15.4を参照）。
In addition to the recommendations in the current HTTP specifications ([RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235] as of this writing) and also those of the previous relevant RFCs [RFC2068] [RFC2616], future HTTP specifications may provide additional guidance on security issues.
現在のHTTP仕様の推奨事項（[RFC7230]、[RFC7231]、[RFC7232]、[RFC7233]、[RFC7234]、および[RFC7235]の執筆時点））に加えて、以前の関連RFC [RFC2068 ] [RFC2616]、将来のHTTP仕様では、セキュリティ問題に関する追加のガイダンスが提供される可能性があります。
The following are added considerations for RTSP implementations.
以下は、RTSP実装に関する追加の考慮事項です。
Session Hijacking: Since there is no or little relation between a transport-layer connection and an RTSP session, it is possible for a malicious client to issue requests with random session identifiers that could affect other clients of an unsuspecting server. To mitigate this, the server SHALL use a large, random and non-sequential session identifier to minimize the possibility of this kind of attack. However, unless the RTSP signaling is always confidentiality protected, e.g., using TLS, an on-path attacker will be able to hijack a session. Another choice for preventing session hijacking is to use client authentication and only allow the authenticated client creating the session to access that session.
セッションハイジャック：トランスポート層接続とRTSPセッションの間にはほとんどまたはほとんど関係がないため、悪意のあるクライアントが、疑いを持たないサーバーの他のクライアントに影響を与える可能性のあるランダムセッション識別子を使用して要求を発行する可能性があります。これを軽減するために、サーバーはこの種の攻撃の可能性を最小限に抑えるために、大きくランダムで非順次のセッション識別子を使用する必要があります（SHALL）。ただし、RTSPシグナリングが常に機密保護されている場合（TLSを使用するなど）を除いて、パス上の攻撃者はセッションを乗っ取ることができます。セッションの乗っ取りを防ぐためのもう1つの選択肢は、クライアント認証を使用して、セッションを作成する認証されたクライアントのみがそのセッションにアクセスできるようにすることです。
Authentication: Servers SHOULD implement both basic and Digest [RFC2617] authentication. In environments requiring tighter security for the control messages, the transport-layer mechanism TLS [RFC5246] SHOULD be used.
認証：サーバーは、基本認証とダイジェスト認証[RFC2617]の両方を実装する必要があります（SHOULD）。制御メッセージに対してより厳しいセキュリティを必要とする環境では、トランスポート層メカニズムTLS [RFC5246]を使用する必要があります（SHOULD）。
Suspicious Behavior: Upon detecting instances of behavior that is deemed a security risk, RTSP servers SHOULD return error code 403 (Forbidden). RTSP servers SHOULD also be aware of attempts to probe the server for weaknesses and entry points and MAY arbitrarily disconnect and ignore further requests from clients that are deemed to be in violation of local security policy.
不審な動作：セキュリティリスクと見なされる動作のインスタンスを検出すると、RTSPサーバーはエラーコード403（禁止）を返す必要があります（SHOULD）。 RTSPサーバーは、サーバーの弱点とエントリポイントをプローブする試みにも注意し、ローカルセキュリティポリシーに違反していると見なされるクライアントからの要求を任意に切断して無視してもよい（MAY）。
TLS through Proxies: If one uses the possibility to connect TLS in multiple legs (Section 19.3), one really needs to be aware of the trust model. This procedure requires trust in all proxies part of the path to the server. The proxies one connects through are identified, assuming the proxies so far connected through are well behaved and fulfilling the trust. The accepted proxies are men in the middle and have access to all that goes on over the TLS connection. Thus, it is important to consider if that trust model is acceptable in the actual application. Further discussion of the actual trust model is in Section 19.3. It is important to note what difference in security properties, if any, may exist with the used media-transport protocol and its security mechanism. Using SRTP and the MIKEY-based key-establishment defined in Appendix C.1.4.1 enables media key-establishment to be done end-to-end without revealing the keys to the proxies.
プロキシを介したTLS：複数のレッグでTLSを接続する可能性を使用する場合（セクション19.3）、本当に信頼モデルを認識する必要があります。この手順では、サーバーへのパスのすべてのプロキシ部分で信頼が必要です。これまでに接続されたプロキシが適切に動作し、信頼を満たしていると仮定して、1つが接続するプロキシが識別されます。受け入れられるプロキシは中間の男性であり、TLS接続を介して行われるすべてのアクセス権を持っています。したがって、その信頼モデルが実際のアプリケーションで受け入れ可能かどうかを検討することが重要です。実際の信頼モデルの詳細については、セクション19.3を参照してください。使用するメディア転送プロトコルとそのセキュリティメカニズムによって、セキュリティプロパティにどのような違いがあるかを確認することが重要です。 SRTPと、付録C.1.4.1で定義されているMIKEYベースのキー確立を使用すると、プロキシにキーを公開することなく、メディアキーの確立をエンドツーエンドで実行できます。
Resource Exhaustion: As RTSP is a stateful protocol and establishes resource usage on the server, there is a clear possibility to attack the server by trying to overbook these resources to perform a DoS attack. This attack can be both against ongoing sessions and to prevent others from establishing sessions. RTSP agents will need to have mechanisms to prevent single peers from consuming extensive amounts of resources. The methods for guarding against this are varied and depend on the agent's role and capabilities and policies. Each implementation has to carefully consider its methods and policies to mitigate this threat. There are recommendations regarding the handling of connections in Section 10.7.
リソースの枯渇：RTSPはステートフルプロトコルであり、サーバーでリソースの使用を確立するため、DoS攻撃を実行するためにこれらのリソースをオーバーブッキングしようとすることでサーバーを攻撃する可能性があります。この攻撃は、進行中のセッションに対するものであり、他のユーザーがセッションを確立するのを防ぐためのものです。 RTSPエージェントには、単一のピアが大量のリソースを消費しないようにするメカニズムが必要です。これを防ぐ方法はさまざまで、エージェントの役割と機能、およびポリシーによって異なります。各実装では、この脅威を軽減するために、その方法とポリシーを慎重に検討する必要があります。セクション10.7には、接続の処理に関する推奨事項があります。
The above threats and considerations have resulted in a set of security functions and mechanisms built into or used by the protocol. The signaling protocol relies on two security features defined in the Security Framework (Section 19): namely client authentication using HTTP authentication and TLS-based transport protection of the signaling messages. Both of these mechanisms are required to be implemented by any RTSP agent.
上記の脅威と考慮事項により、プロトコルに組み込まれた、またはプロトコルによって使用される一連のセキュリティ機能とメカニズムがもたらされました。シグナリングプロトコルは、セキュリティフレームワーク（セクション19）で定義されている2つのセキュリティ機能、つまりHTTP認証を使用したクライアント認証とシグナリングメッセージのTLSベースのトランスポート保護に依存しています。これらのメカニズムはいずれも、RTSPエージェントで実装する必要があります。
A number of different security mitigations have been designed into the protocol and will be instantiated if the specification is implemented as written, for example, by ensuring sufficient amounts of entropy in the randomly generated session identifiers when not using client authentication to minimize the risk of session hijacking. When client authentication is used, protection against hijacking will be greatly improved by scoping the accessible sessions to the one this client identity has created. Some of the above threats are such that the implementation of the RTSP functionality itself needs to consider which policy and strategy it uses to mitigate them.
多くの異なるセキュリティ緩和策がプロトコルに設計されており、仕様が記述どおりに実装されている場合は、たとえば、クライアント認証を使用せずにランダムに生成されたセッション識別子に十分な量のエントロピーを確保してセッションのリスクを最小限に抑えることにより、インスタンス化されますハイジャック。クライアント認証を使用すると、アクセス可能なセッションをこのクライアントIDが作成したセッションにスコープすることで、ハイジャックからの保護が大幅に向上します。上記の脅威の一部は、RTSP機能の実装自体が、それらを軽減するために使用するポリシーと戦略を考慮する必要があるようなものです。
The fact that RTSP establishes and controls a media-stream delivery results in a set of security issues related to the media streams. This section will attempt to analyze general threats; however, the choice of media-stream transport protocol, such as RTP, will result in some differences in threats and what mechanisms exist to mitigate them. Thus, it becomes important that each specification of a new media-stream transport and delivery protocol usable by RTSP requires its own security analysis. This section includes one for RTP.
RTSPがメディアストリーム配信を確立および制御するという事実により、メディアストリームに関連する一連のセキュリティ問題が発生します。このセクションでは、一般的な脅威の分析を試みます。ただし、RTPなどのメディアストリームトランスポートプロトコルを選択すると、脅威とそれらを軽減するために存在するメカニズムにいくつかの違いが生じます。したがって、RTSPで使用可能な新しいメディアストリームのトランスポートおよび配信プロトコルの仕様ごとに、独自のセキュリティ分析が必要になることが重要になります。このセクションには、RTP用のセクションが含まれています。
The set of general threats from or by the media-stream delivery itself are:
メディアストリーム配信自体による、またはメディアストリーム配信自体による一連の一般的な脅威は次のとおりです。
Concentrated Denial-of-Service Attack: The protocol offers the opportunity for a remote-controlled DoS attack, where the media stream is the hammer in that DoS attack. See Section 21.2.1.
集中型サービス拒否攻撃：このプロトコルは、リモート制御のDoS攻撃の機会を提供します。この場合、メディアストリームはそのDoS攻撃のハンマーです。セクション21.2.1を参照してください。
Media Confidentiality: The media delivery may contain content of any type, and it is not possible, in general, to determine how sensitive this content is from a confidentiality point. Thus, it is a strong requirement that any media delivery protocol supply a method for providing confidentiality of the actual media content. In addition to the media-level confidentiality, it becomes critical that no resource identifiers used in the signaling be exposed to an attacker as they may have human-understandable names or may be available to the attacker, allowing it to determine the content the user received. Thus, the signaling protocol must also provide confidentiality protection of any information related to the media resource.
メディアの機密性：メディア配信には任意のタイプのコンテンツが含まれる可能性があり、通常、このコンテンツが機密性の点からどの程度機密であるかを判断することはできません。したがって、メディア配信プロトコルが実際のメディアコンテンツの機密性を提供する方法を提供することは、強力な要件です。メディアレベルの機密性に加えて、シグナリングで使用されるリソース識別子は、人間が理解できる名前を持っているか、攻撃者が利用できる可能性があるため、攻撃者に公開されないことが重要になります。これにより、ユーザーが受け取ったコンテンツを特定できます。 。したがって、シグナリングプロトコルは、メディアリソースに関連する情報の機密保護も提供する必要があります。
Media Integrity and Authentication: There are several reasons why an attacker will be interested in substituting the media stream sent out from the RTSP server with one of the attacker's creation or selection, such as discrediting the target and misinformation about the target. Therefore, it is important that the media protocol provide mechanisms to verify the source authentication and integrity and to prevent replay attacks on the media stream.
メディアの整合性と認証：攻撃者がRTSPサーバーから送信されたメディアストリームを攻撃者の作成または選択の1つに置き換えることに関心がある理由はいくつかあります。したがって、メディアプロトコルがソースの認証と整合性を確認し、メディアストリームへのリプレイアタックを防ぐメカニズムを提供することが重要です。
Scope of Multicast: If RTSP is used to control the transmission of media onto a multicast network, the scope of the delivery must be considered. RTSP supports the TTL Transport header parameter to indicate this scope for IPv4. IPv6 has a different mechanism for the scope boundary. However, such scope control has risks, as it may be set too large and distribute media beyond the intended scope.
マルチキャストの範囲：RTSPを使用してマルチキャストネットワークへのメディアの送信を制御する場合、配信の範囲を考慮する必要があります。 RTSPは、TTLトランスポートヘッダーパラメーターをサポートして、IPv4のこのスコープを示します。 IPv6には、スコープ境界の異なるメカニズムがあります。ただし、設定が大きすぎて意図した範囲を超えてメディアを配信する可能性があるため、このような範囲制御にはリスクがあります。
Below (Section 21.2.2) a protocol-specific analysis of security considerations for RTP-based media transport is included. In that section, the requirements on implementing security functions for RTSP agents supporting media delivery over RTP are made clear.
以下（セクション21.2.2）には、RTPベースのメディアトランスポートのセキュリティに関する考慮事項のプロトコル固有の分析が含まれています。そのセクションでは、RTPを介したメディア配信をサポートするRTSPエージェントのセキュリティ機能の実装に関する要件が明らかにされています。
The attacker may initiate traffic flows to one or more IP addresses by specifying them as the destination in SETUP requests. While the attacker's IP address may be known in this case, this is not always useful in the prevention of more attacks or ascertaining the attacker's identity. Thus, an RTSP server MUST only allow client-specified destinations for RTSP-initiated traffic flows if the server has ensured that the specified destination address accepts receiving media through different security mechanisms. Security mechanisms that are acceptable in order of increasing generality are:
攻撃者は、SETUP要求で宛先として指定することにより、1つ以上のIPアドレスへのトラフィックフローを開始する可能性があります。この場合、攻撃者のIPアドレスがわかっている可能性がありますが、これは、それ以上の攻撃の防止や攻撃者のIDの確認に常に役立つとは限りません。したがって、RTSPサーバーは、指定された宛先アドレスが異なるセキュリティメカニズムを通じて受信メディアを受け入れることをサーバーが保証している場合にのみ、RTSPによって開始されたトラフィックフローに対してクライアント指定の宛先を許可する必要があります。一般性の高い順に許容できるセキュリティメカニズムは次のとおりです。
o Verification of the client's identity against a database of known users using RTSP authentication mechanisms (preferably Digest authentication or stronger)
o RTSP認証メカニズム（できればダイジェスト認証以上）を使用した既知のユーザーのデータベースに対するクライアントのIDの検証
o A list of addresses that have consented to be media destinations, especially considering user identity
o メディアの宛先であることに同意したアドレスのリスト、特にユーザーIDを考慮する
o Verification based on media path
o メディアパスに基づく検証
The server SHOULD NOT allow the destination field to be set unless a mechanism exists in the system to authorize the request originator to direct streams to the recipient. It is preferred that this authorization be performed by the media recipient (destination) itself and the credentials be passed along to the server. However, in certain cases, such as when the recipient address is a multicast group or when the recipient is unable to communicate with the server in an out-of-band manner, this may not be possible. In these cases, the server may choose another method such as a server-resident authorization list to ensure that the request originator has the proper credentials to request stream delivery to the recipient.
リクエストの発信者がストリームを受信者に送信することを承認するメカニズムがシステムに存在しない限り、サーバーは宛先フィールドの設定を許可すべきではありません（SHOULD NOT）。この許可はメディア受信者（宛先）自体によって実行され、資格情報はサーバーに渡されることが望ましいです。ただし、受信者のアドレスがマルチキャストグループである場合や、受信者が帯域外でサーバーと通信できない場合など、特定の状況では、これができない場合があります。これらの場合、サーバーはサーバーに常駐する承認リストなどの別の方法を選択して、要求の発信者が受信者へのストリーム配信を要求するための適切な資格情報を持っていることを確認します。
One solution that performs the necessary verification of acceptance of media suitable for unicast-based delivery is the NAT traversal method based on Interactive Connectivity Establishment (ICE) [RFC5245] described in [RFC7825]. This mechanism uses random passwords and a username so that the probability of unintended indication as a valid media destination is very low. In addition, the server includes in its Session Traversal Utilities for NAT (STUN) [RFC5389] requests a cookie (consisting of random material) that the destination echoes back; thus, the solution also safeguards against having an off-path attacker being able to spoof the STUN checks. This leaves this solution vulnerable only to on-path attackers that can see the STUN requests go to the target of attack and thus forge a response.
ユニキャストベースの配信に適したメディアの受け入れの必要な検証を実行する1つのソリューションは、[RFC7825]で説明されているInteractive Connectivity Establishment（ICE）[RFC5245]に基づくNATトラバーサル方式です。このメカニズムはランダムなパスワードとユーザー名を使用するため、有効なメディアの宛先として意図しない表示が行われる可能性は非常に低くなります。さらに、サーバーはそのNAT向けセッショントラバーサルユーティリティ（STUN）[RFC5389]に含まれ、宛先がエコーバックするCookie（ランダムな素材で構成される）を要求します。したがって、このソリューションは、オフパスの攻撃者がSTUNチェックを偽装できるようにすることも保護します。これにより、このソリューションは、STUN要求が攻撃のターゲットに送信され、応答が偽造されることを確認できるパス上の攻撃者に対してのみ脆弱になります。
For delivery to multicast addresses, there is a need for another solution that is not specified in this memo.
マルチキャストアドレスへの配信のために、このメモで指定されていない別のソリューションが必要です。
RTP is a commonly used media-transport protocol and has been the most common choice for RTSP 1.0 implementations. The core RTP protocol has been in use for a long time, and it has well-known security properties and the RTP security consideration (Section 9 of [RFC3550]) needs to be reviewed. In perspective of the usage of RTP in the context of RTSP, the following properties should be noted:
RTPは一般的に使用されるメディア転送プロトコルであり、RTSP 1.0実装で最も一般的な選択肢です。コアRTPプロトコルは長い間使用されており、既知のセキュリティプロパティがあり、RTPセキュリティの考慮事項（[RFC3550]のセクション9）を確認する必要があります。 RTSPのコンテキストでのRTPの使用の観点から、次のプロパティに注意する必要があります。
Stream Additions: RTP has support for multiple simultaneous media streams in each RTP session. As some use cases require support for non-synchronized adding and removal of media streams and their identifiers, an attacker can easily insert additional media streams into a session context that, according to protocol design, is intended to be played out. Another threat vector is one of DoS by exhausting the resources of the RTP session receiver, for example, by using a large number of SSRC identifiers simultaneously. The strong mitigation of this is to ensure that one cryptographically authenticates any incoming packet flow to the RTP session. Weak mitigations like blocking additional media streams in session contexts easily lead to a DoS vulnerability in addition to preventing certain RTP extensions or use cases that rely on multiple media streams, such as RTP retransmission [RFC4588] to function.
ストリームの追加：RTPは、各RTPセッションで複数の同時メディアストリームをサポートしています。一部のユースケースでは、メディアストリームとその識別子の非同期の追加と削除のサポートが必要であるため、攻撃者は、プロトコルの設計に従って、再生することを目的としたセッションコンテキストに追加のメディアストリームを簡単に挿入できます。別の脅威ベクトルは、たとえば多数のSSRC識別子を同時に使用するなど、RTPセッションレシーバーのリソースを使い果たすDoSの1つです。この強力な緩和策は、RTPセッションへの着信パケットフローを暗号化して認証することです。セッションコンテキストで追加のメディアストリームをブロックするなどの弱い緩和策は、特定のRTP拡張機能や、RTP再送信[RFC4588]などの複数のメディアストリームに依存する機能の使用を阻止することに加えて、DoS脆弱性を簡単に引き起こします。
Forged Feedback: The built-in RTCP also offers a large attack surface for a couple of different types of attacks. One venue is to send RTCP feedback to the media sender indicating large amounts of packet loss and thus trigger a media bitrate adaptation response from the sender resulting in lowered media quality and potentially a shutdown of the media stream. Another attack is to perform a resource-exhaustion attack on the receiver by using many SSRC identifiers to create large state tables and increase the RTCP-related processing demands.
偽造フィードバック：組み込みのRTCPは、いくつかの異なるタイプの攻撃に対して大きな攻撃面も提供します。 1つの場は、大量のパケット損失を示すRTCPフィードバックをメディア送信者に送信し、送信者からのメディアビットレート適応応答をトリガーして、メディア品質を低下させ、場合によってはメディアストリームをシャットダウンすることです。もう1つの攻撃は、多くのSSRC識別子を使用して受信側にリソース枯渇攻撃を実行し、大きな状態テーブルを作成して、RTCP関連の処理要求を増やすことです。
RTP/RTCP Extensions: RTP and RTCP extensions generally provide additional and sometimes extremely powerful tools for DoS attacks or service disruption. For example, the Code Control Message [RFC5104] RTCP extensions enables both the lock down of the bitrate to low values and disruption of video quality by requesting intra-frames.
RTP / RTCP拡張：RTPおよびRTCP拡張は、一般に、DoS攻撃またはサービス中断のための追加の、場合によっては非常に強力なツールを提供します。たとえば、コード制御メッセージ[RFC5104] RTCP拡張機能は、ビットレートを低い値にロックダウンすることと、フレーム内を要求することによりビデオ品質を破壊することの両方を可能にします。
Taking into account the above general discussion in Section 21.2 and the RTP-specific discussion in this section, it is clear that it is necessary that a strong security mechanism be supported to protect RTP. Therefore, this specification has the following requirements on RTP security functions for all RTSP agents that handle media streams and where media-stream transport is completed using RTP.
上記のセクション21.2での一般的な説明とこのセクションでのRTP固有の説明を考慮すると、RTPを保護するために強力なセキュリティメカニズムをサポートする必要があることは明らかです。したがって、この仕様には、メディアストリームを処理するすべてのRTSPエージェントのRTPセキュリティ機能に関する次の要件があり、RTPを使用してメディアストリーム転送が完了します。
RTSP agents supporting RTP MUST implement Secure RTP (SRTP) [RFC3711] and, thus, SAVP. In addition, SAVPF [RFC5124] MUST also be supported if AVPF is implemented. This specification requires no additional cryptographic transforms or configuration values beyond those specified as mandatory to implement in RFC 3711, i.e., AES-CM and HMAC-SHA1. The default key-management mechanism that MUST be implemented is the one defined in MIKEY Key Establishment (Appendix C.1.4.1). The MIKEY implementation MUST implement the necessary functions for MIKEY-RSA-R mode [RFC4738] and the SRTP parameter negotiation necessary to negotiate the supported SRTP transforms and parameters.
RTPをサポートするRTSPエージェントは、Secure RTP（SRTP）[RFC3711]、したがってSAVPを実装する必要があります。さらに、AVPFが実装されている場合は、SAVPF [RFC5124]もサポートする必要があります。この仕様では、RFC 3711での実装に必須として指定されている値（AES-CMおよびHMAC-SHA1）を超える追加の暗号変換または構成値は必要ありません。実装しなければならないデフォルトの鍵管理メカニズムは、MIKEY鍵の確立（付録C.1.4.1）で定義されているものです。 MIKEY実装は、MIKEY-RSA-Rモード[RFC4738]に必要な機能と、サポートされているSRTP変換およびパラメーターのネゴシエーションに必要なSRTPパラメーターネゴシエーションを実装する必要があります。
This section describes a number of registries for RTSP 2.0 that have been established and are maintained by IANA. These registries are separate from any registries existing for RTSP 1.0. For each registry, there is a description of the required content, the registration procedures, and the entries that this document registers. For more information on extending RTSP, see Section 2.7. In addition, this document registers three SDP attributes.
このセクションでは、IANAによって確立および維持されているRTSP 2.0の多数のレジストリについて説明します。これらのレジストリは、RTSP 1.0に存在するレジストリとは別のものです。レジストリごとに、必要なコンテンツ、登録手順、およびこのドキュメントが登録するエントリの説明があります。 RTSPの拡張の詳細については、セクション2.7を参照してください。さらに、このドキュメントでは3つのSDP属性を登録しています。
Registries or entries in registries that have been made for RTSP 1.0 are not moved to RTSP 2.0: the registries and entries of RTSP 1.0 and RTSP 2.0 are independent. If any registry or entry in a registry is also required in RTSP 2.0, it MUST follow the procedure defined below to allocate the registry or entry in a registry.
RTSP 1.0用に作成されたレジストリまたはレジストリ内のエントリはRTSP 2.0に移動されません。RTSP1.0とRTSP 2.0のレジストリとエントリは独立しています。レジストリまたはレジストリのエントリがRTSP 2.0でも必要な場合は、以下に定義されている手順に従って、レジストリまたはレジストリのエントリを割り当てる必要があります。
The sections describing how to register an item use some of the registration policies described in [RFC5226] -- namely, "First Come First Served", "Expert Review", "Specification Required", and "Standards Action".
アイテムを登録する方法を説明するセクションでは、[RFC5226]で説明されている登録ポリシーの一部、つまり「先着順」、「エキスパートレビュー」、「必要な仕様」、および「標準アクション」を使用します。
In case a registry requires a contact person, the authors (with Magnus Westerlund <magnus.westerlund@ericsson.com> as primary) are the contact persons for any entries created by this document.
レジストリに連絡先担当者が必要な場合、作成者（Magnus Westerlund <magnus.westerlund@ericsson.com>をプライマリとして）は、このドキュメントで作成されたエントリの連絡先担当者です。
IANA will request the following information for any registration request:
IANAはすべての登録要求に対して次の情報を要求します。
o A name of the item to register according to the rules specified by the intended registry
o 対象のレジストリで指定されたルールに従って登録するアイテムの名前
o Indication of who has change control over the feature (for example, the IETF, ISO, ITU-T, other international standardization bodies, a consortium, a particular company or group of companies, or an individual)
o 誰がその機能を変更管理できるかを示す（たとえば、IETF、ISO、ITU-T、その他の国際標準化団体、コンソーシアム、特定の企業または企業グループ、あるいは個人）
o A reference to a further description, if available, for example (in decreasing order of preference), an RFC, a published standard, a published paper, a patent filing, a technical report, documented source code or a computer manual
o 可能な場合は、詳細な説明への参照（たとえば、優先度の高い順）、RFC、公開された規格、公開された論文、特許出願、技術レポート、文書化されたソースコード、またはコンピューターのマニュアル
o For proprietary features, contact information (postal and email address)
o 独自の機能については、連絡先情報（郵便および電子メールアドレス）
When a client and server try to determine what part and functionality of the RTSP specification and any future extensions that its counterpart implements, there is need for a namespace. This registry contains named entries representing certain functionality.
クライアントとサーバーがRTSP仕様のどの部分と機能、および対応するものが実装する将来の拡張機能を決定しようとする場合、名前空間が必要です。このレジストリには、特定の機能を表す名前付きエントリが含まれています。
The usage of feature tags is explained in Section 11 and Section 13.1.
機能タグの使用法については、セクション11およびセクション13.1で説明します。
The registering of feature tags is done on a First Come, First Served [RFC5226] basis.
機能タグの登録は、先着順で行われます[RFC5226]。
The registry entry for a feature tag has the following information:
機能タグのレジストリエントリには、次の情報が含まれています。
o The name of the feature tag
o 機能タグの名前
* If the registrant indicates that the feature is proprietary, IANA should request a vendor "prefix" portion of the name. The name will then be the vendor prefix followed by a "." followed by the rest of the provided feature name.
* 登録者が機能が独占的であることを示す場合、IANAは名前のベンダー「プレフィックス」部分を要求する必要があります。その場合、名前はベンダープレフィックスとそれに続く「。」になります。提供された機能名の残りが続きます。
* If the feature is not proprietary, then IANA need not collect a prefix for the name.
* 機能が独自仕様でない場合、IANAは名前のプレフィックスを収集する必要はありません。
o A one-paragraph description of what the feature tag represents
o 機能タグが何を表すかについての1段落の説明
o The applicability (server, client, proxy, or some combination)
o 適用範囲（サーバー、クライアント、プロキシ、またはいくつかの組み合わせ）
o A reference to a specification, if applicable Feature tag names (including the vendor prefix) may contain any non-space and non-control characters. There is no length limit on feature tags.
o 仕様への参照（該当する場合）（ベンダープレフィックスを含む）機能タグ名には、スペースや制御文字以外の文字が含まれる場合があります。機能タグには長さの制限はありません。
Examples for a vendor tag describing a proprietary feature are:
独自の機能を説明するベンダータグの例は次のとおりです。
vendorA.specfeat01
vendor.spetsfeat01
vendorA.specfeat02
vendor.spetsfeat02
The following feature tags are defined in this specification and hereby registered. The change control belongs to the IETF.
次の機能タグは、この仕様で定義され、ここに登録されています。変更管理はIETFに属しています。
play.basic: The implementation for delivery and playback operations according to the core RTSP specification, as defined in this memo. Applies for clients, servers, and proxies. See Section 11.1.
play.basic：このメモで定義されているコアRTSP仕様に従った配信および再生操作の実装。クライアント、サーバー、およびプロキシに適用されます。セクション11.1を参照してください。
play.scale: Support of scale operations for media playback. Applies only for servers. See Section 18.46.
play.scale：メディア再生のためのスケール操作のサポート。サーバーにのみ適用されます。セクション18.46を参照してください。
play.speed: Support of the speed functionality for media delivery. Applies only for servers. See Section 18.50.
play.speed：メディア配信の速度機能のサポート。サーバーにのみ適用されます。セクション18.50を参照してください。
setup.rtp.rtcp.mux: Support of the RTP and RTCP multiplexing as discussed in Appendix C.1.6.4. Applies for both client and servers and any media caching proxy.
setup.rtp.rtcp.mux：付録C.1.6.4で説明されているRTPおよびRTCP多重化のサポート。クライアントとサーバーの両方、および任意のメディアキャッシュプロキシに適用されます。
The IANA registry is a table with the name, description, and reference for each feature tag.
IANAレジストリは、各機能タグの名前、説明、および参照を含むテーブルです。
Methods are described in Section 13. Extending the protocol with new methods allows for totally new functionality.
メソッドについては、セクション13で説明します。プロトコルを新しいメソッドで拡張すると、まったく新しい機能が可能になります。
A new method is registered through a Standards Action [RFC5226] because new methods may radically change the protocol's behavior and purpose.
新しいメソッドは、プロトコルの動作と目的を根本的に変更する可能性があるため、標準アクション[RFC5226]を通じて登録されます。
A specification for a new RTSP method consists of the following items:
新しいRTSPメソッドの仕様は、次の項目で構成されています。
o A method name that follows the ABNF rules for methods.
o メソッドのABNFルールに従うメソッド名。
o A clear specification of what a request using the method does and what responses are expected. In which directions the method is used: C->S, S->C, or both. How the use of headers, if any, modifies the behavior and effect of the method.
o メソッドを使用したリクエストが実行すること、および予期される応答の明確な仕様。メソッドが使用される方向：C-> S、S-> C、またはその両方。ヘッダーを使用すると、メソッドの動作と効果が変更されます。
o A list or table specifying which of the IANA-registered headers that are allowed to be used with the method in the request or/and response. The list or table SHOULD follow the format of tables in Section 18.
o 要求または応答、あるいはその両方のメソッドで使用できるIANA登録ヘッダーを指定するリストまたはテーブル。リストまたはテーブルは、セクション18のテーブルの形式に従う必要があります。
o Describe how the method relates to network proxies.
o この方法がネットワークプロキシにどのように関連するか説明してください。
This specification, RFC 7826, registers 10 methods: DESCRIBE, GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY, REDIRECT, SETUP, SET_PARAMETER, and TEARDOWN. The initial table of the registry is provided below.
この仕様であるRFC 7826は、DESCRIBE、GET_PARAMETER、OPTIONS、PAUSE、PLAY、PLAY_NOTIFY、REDIRECT、SETUP、SET_PARAMETER、およびTEARDOWNの10のメソッドを登録しています。レジストリの最初の表を以下に示します。
Method Directionality Reference
-----------------------------------------------------
DESCRIBE C->S RFC 7826
GET_PARAMETER C->S, S->C RFC 7826
OPTIONS C->S, S->C RFC 7826
PAUSE C->S RFC 7826
PLAY C->S RFC 7826
PLAY_NOTIFY S->C RFC 7826
REDIRECT S->C RFC 7826
SETUP C->S RFC 7826
SET_PARAMETER C->S, S->C RFC 7826
TEARDOWN C->S, S->C RFC 7826
A status code is the three-digit number used to convey information in RTSP response messages; see Section 8. The number space is limited, and care should be taken not to fill the space.
ステータスコードは、RTSP応答メッセージで情報を伝えるために使用される3桁の番号です。セクション8を参照してください。スペースには制限があり、スペースを埋めないように注意してください。
A new status code registration follows the policy of IETF Review [RFC5226]. New RTSP functionality requiring Status Codes should first be registered in the range of x50-x99. Only when the range is full should registrations be made in the x00-x49 range, unless it is to adopt an HTTP extension to RTSP. This is done to enable any HTTP extension to be adopted to RTSP without needing to renumber any related status codes. A specification for a new status code must include the following:
新しいステータスコードの登録は、IETFレビュー[RFC5226]のポリシーに従います。ステータスコードを必要とする新しいRTSP機能は、最初にx50〜x99の範囲で登録する必要があります。 RTSPにHTTP拡張を採用する場合を除き、範囲がいっぱいの場合にのみ、x00-x49の範囲で登録を行う必要があります。これは、関連するステータスコードを再番号付けする必要なく、RTSPにHTTP拡張を採用できるようにするために行われます。新しいステータスコードの仕様には、以下を含める必要があります。
o The registered number.
o 登録番号。
o A description of what the status code means and the expected behavior of the sender and receiver of the code.
o ステータスコードの意味と、コードの送信者と受信者の予想される動作の説明。
RFC 7826 (this document) registers the numbered status code defined in the ABNF entry "Status-Code", except "extension-code" (that defines the syntax allowed for future extensions) in Section 20.2.2.
RFC 7826（このドキュメント）は、セクション20.2.2の「extension-code」（将来の拡張で許可される構文を定義する）を除き、ABNFエントリ「Status-Code」で定義された番号付きステータスコードを登録します。
By specifying new headers, one or more methods can be enhanced in many different ways. An unknown header will be ignored by the receiving agent. If the new header is vital for certain functionality, a feature tag for the functionality can be created and demanded to be used by the counterpart with the inclusion of a Require header carrying the feature tag.
新しいヘッダーを指定することにより、1つ以上のメソッドをさまざまな方法で拡張できます。不明なヘッダーは、受信エージェントによって無視されます。新しいヘッダーが特定の機能にとって不可欠である場合、その機能の機能タグを作成し、機能タグを運ぶRequireヘッダーを含めて、対応する機能で使用するように要求できます。
Registrations can be made following the Expert Review policy [RFC5226]. A specification is recommended to be provided, preferably an RFC or other specification from a Standards Developing Organization. The minimal information in a registration request is the header name and the contact information.
登録は、エキスパートレビューポリシー[RFC5226]に従って行うことができます。仕様を提供することをお勧めします。できればRFCまたはその他の仕様を標準策定組織から提供することをお勧めします。登録要求の最小限の情報は、ヘッダー名と連絡先情報です。
The expert reviewer verifies that the registration request contains the following information:
エキスパートレビューアーは、登録リクエストに次の情報が含まれていることを確認します。
o The name of the header.
o ヘッダーの名前。
o An ABNF specification of the header syntax.
o ヘッダー構文のABNF仕様。
o A list or table specifying when the header may be used, encompassing all methods, their request or response, and the direction (C->S or S->C).
o ヘッダーをいつ使用できるかを指定するリストまたはテーブル。すべてのメソッド、それらの要求または応答、および方向（C-> SまたはS-> C）が含まれます。
o How the header is to be handled by proxies.
o ヘッダーがプロキシによって処理される方法。
o A description of the purpose of the header.
o ヘッダーの目的の説明。
All headers specified in Section 18 in RFC 7826 have been registered. The registry includes the header name and reference.
RFC 7826のセクション18で指定されているすべてのヘッダーが登録されています。レジストリには、ヘッダー名と参照が含まれています。
Furthermore, the following legacy RTSP headers defined in other specifications are registered with header name, and reference according to below list. Note: these references may not fulfill all of the above rules for registrations due to their legacy status.
さらに、他の仕様で定義されている以下のレガシーRTSPヘッダーはヘッダー名で登録され、以下のリストに従って参照されます。注：これらの参照は、レガシーステータスのため、登録に関する上記のルールのすべてを満たさない場合があります。
o x-wap-profile defined in [TS-26234]. The x-wap-profile request-header contains one or more absolute URLs to the requesting agent's device-capability profile.
o [TS-26234]で定義されているx-wap-profile。 x-wap-profile要求ヘッダーには、要求元エージェントのデバイス機能プロファイルへの1つ以上の絶対URLが含まれています。
o x-wap-profile-diff defined in [TS-26234]. The x-wap-profile-diff request-header contains a subset of a device-capability profile.
o [TS-26234]で定義されているx-wap-profile-diff。 x-wap-profile-diff要求ヘッダーには、デバイス機能プロファイルのサブセットが含まれています。
o x-wap-profile-warning defined in [TS-26234]. The x-wap-profile-warning is a response-header that contains error codes explaining to what extent the server has been able to match the terminal request in regard to device-capability profiles, as described using x-wap-profile and x-wap-profile-diff headers.
o [TS-26234]で定義されているx-wap-profile-warning。 x-wap-profile-warningは、x-wap-profileおよびx-を使用して説明したように、サーバーがデバイス機能プロファイルに関して端末要求にどの程度一致できたかを説明するエラーコードを含む応答ヘッダーです。 wap-profile-diffヘッダー。
o x-predecbufsize defined in [TS-26234]. This response-header provides an RTSP agent with the TS 26.234 Annex G hypothetical pre-decoder buffer size.
o [TS-26234]で定義されているx-predecbufsize。このレスポンスヘッダーは、RTSPエージェントにTS 26.234 Annex G仮想プリデコーダバッファーサイズを提供します。
o x-initpredecbufperiod defined in [TS-26234]. This response-header provides an RTSP agent with the TS 26.234 Annex G hypothetical pre-decoder buffering period.
o [TS-26234]で定義されているx-initpredecbufperiod。この応答ヘッダーは、RTSPエージェントにTS 26.234 Annex G仮想プリデコーダバッファリング期間を提供します。
o x-initpostdecbufperiod defined in [TS-26234]. This response-header provides an RTSP agent with the TS 26.234 Annex G post-decoder buffering period.
o [TS-26234]で定義されているx-initpostdecbufperiod。この応答ヘッダーは、RTSPエージェントにTS 26.234 Annex Gポストデコーダバッファリング期間を提供します。
o 3gpp-videopostdecbufsize defined in [TS-26234]. This response-header provides an RTSP agent with the TS 26.234 defined post-decoder buffer size usable for H.264 (AVC) video streams.
o [TS-26234]で定義されている3gpp-videopostdecbufsize。この応答ヘッダーは、RTSPエージェントに、H.264（AVC）ビデオストリームに使用できるTS 26.234定義のポストデコーダバッファーサイズを提供します。
o 3GPP-Link-Char defined in [TS-26234]. This request-header provides the RTSP server with the RTSP client's link characteristics as determined from the radio interface. The information that can be provided are guaranteed bitrate, maximum bitrate and maximum transfer delay.
o [TS-26234]で定義されている3GPP-Link-Char。この要求ヘッダーは、無線インターフェイスから決定されたRTSPクライアントのリンク特性をRTSPサーバーに提供します。提供できる情報は、保証されたビットレート、最大ビットレート、最大転送遅延です。
o 3GPP-Adaptation defined in [TS-26234]. This general-header is part of the bitrate adaptation solution specified for the Packet-switched Streaming Service (PSS). It provides the RTSP client's buffer sizes and target buffer levels to the server, and responses are used to acknowledge the support and values.
o [TS-26234]で定義されている3GPP-Adaptation。この一般的なヘッダーは、パケット交換ストリーミングサービス（PSS）に指定されたビットレート適応ソリューションの一部です。 RTSPクライアントのバッファーサイズとターゲットバッファーレベルをサーバーに提供し、応答を使用してサポートと値を確認します。
o 3GPP-QoE-Metrics defined in [TS-26234]. This general-header is used by PSS RTSP agents to negotiate the quality of experience metrics that a client should gather and report to the server.
o [TS-26234]で定義されている3GPP-QoE-Metrics。この一般的なヘッダーは、クライアントが収集してサーバーに報告する必要があるエクスペリエンス品質のメトリックをネゴシエートするためにPSS RTSPエージェントによって使用されます。
o 3GPP-QoE-Feedback defined in [TS-26234]. This request-header is used by RTSP clients supporting PSS to report the actual values of the metrics gathered in its quality of experience metering.
o [TS-26234]で定義されている3GPP-QoE-Feedback。この要求ヘッダーは、PSSをサポートするRTSPクライアントによって使用され、エクスペリエンス品質の測定で収集されたメトリックの実際の値を報告します。
The use of "x-" is NOT RECOMMENDED, but the above headers in the list were defined prior to the clarification.
「x-」の使用は推奨されませんが、リスト内の上記のヘッダーは、明確化の前に定義されています。
The security framework's TLS connection mechanism has two registerable entities.
セキュリティフレームワークのTLS接続メカニズムには、2つの登録可能なエンティティがあります。
This registry is for policies for an RTSP proxy's handling and verification of TLS certificates when establishing an outbound TLS connection on behalf of a client. In Section 19.3.1, three policies for how to handle certificates are specified. Further policies may be defined; registration is made through Standards Action [RFC5226]. A registration request is required to contain the following information:
このレジストリは、クライアントに代わって発信TLS接続を確立するときのRTSPプロキシの処理とTLS証明書の検証に関するポリシー用です。セクション19.3.1では、証明書の処理方法に関する3つのポリシーが指定されています。さらにポリシーを定義することができます。登録は、Standards Action [RFC5226]を通じて行われます。登録リクエストには、次の情報を含める必要があります。
o Name of the policy.
o ポリシーの名前。
o Text that describes how the policy works for handling the certificates.
o 証明書を処理するためのポリシーの機能を説明するテキスト。
o A contact person.
o 担当者。
This specification registers the following values:
この仕様は、次の値を登録します。
Any: A policy requiring the proxy to accept any received certificate.
Any：プロキシが受信した証明書を受け入れることを要求するポリシー。
Proxy: A policy where the proxy applies its own policies to determine which certificates are accepted.
プロキシ：プロキシが独自のポリシーを適用して、どの証明書を受け入れるかを決定するポリシー。
User: A policy where the certificate is required to be forwarded down the proxy chain to the client, thus allowing the user to decided to accept or refuse a certificate.
ユーザー：証明書をプロキシチェーンからクライアントに転送する必要があるポリシー。これにより、ユーザーは証明書を受け入れるか拒否するかを決定できます。
The Accept-Credentials header (see Section 18.2) allows for the usage of other algorithms for hashing the DER records of accepted entities. The registration of any future algorithm is expected to be extremely rare and could also cause interoperability problems. Therefore, the bar for registering new algorithms is intentionally placed high.
Accept-Credentialsヘッダー（セクション18.2を参照）では、他のアルゴリズムを使用して、受け入れられたエンティティのDERレコードをハッシュ化できます。将来のアルゴリズムの登録は非常にまれであると予想され、相互運用性の問題を引き起こす可能性もあります。したがって、新しいアルゴリズムを登録するための基準は意図的に高く設定されています。
Any registration of a new hash algorithm requires Standards Action [RFC5226]. The registration needs to fulfill the following requirement:
新しいハッシュアルゴリズムを登録するには、標準アクション[RFC5226]が必要です。登録は次の要件を満たす必要があります。
o The algorithms identifier meeting the "token" ABNF requirement.
o 「トークン」ABNF要件を満たすアルゴリズム識別子。
o Provide a definition of the algorithm.
o アルゴリズムの定義を提供します。
The registered value is:
登録されている値は次のとおりです。
Hash Alg. ID Reference
------------------------
sha-256 RFC 7826
There exist a number of cache directives that can be sent in the Cache-Control header. A registry for these cache directives has been established by IANA. New registrations in this registry require Standards Action or IESG Approval [RFC5226]. A registration request needs to contain the following information.
Cache-Controlヘッダーで送信できるいくつかのキャッシュディレクティブが存在します。これらのキャッシュディレクティブのレジストリは、IANAによって確立されています。このレジストリの新規登録には、標準化アクションまたはIESG承認[RFC5226]が必要です。登録リクエストには、次の情報を含める必要があります。
o The name of the cache directive.
o キャッシュディレクティブの名前。
o A definition of the parameter value, if any is allowed.
o パラメータ値の定義（許可されている場合）。
o The specification if it is a request or response directive.
o 要求または応答ディレクティブの場合の仕様。
o Text that explains how the cache directive is used for RTSP-controlled media streams.
o RTSP制御のメディアストリームでキャッシュディレクティブがどのように使用されるかを説明するテキスト。
o A contact person.
o 担当者。
This specification registers the following values:
この仕様は、次の値を登録します。
no-cache:
キャッシュなし：
public:
公衆：
private:
民間：
no-transform:
変換なし：
only-if-cached:
キャッシュのみの場合：
max-stale:
max-stale：
min-fresh:
マットレス：
must-revalidate:
再検証が必要：
proxy-revalidate:
プロキシ再検証：
max-age:
最大年齢：
The registry contains the name of the directive and the reference.
レジストリには、ディレクティブの名前と参照が含まれています。
The media streams being controlled by RTSP can have many different properties. The media properties required to cover the use cases that were in mind when writing the specification are defined. However, it can be expected that further innovation will result in new use cases or media streams with properties not covered by the ones specified here. Thus, new media properties can be specified. As new media properties may need a substantial amount of new definitions to correctly specify behavior for this property, the bar is intended to be high.
RTSPによって制御されているメディアストリームには、さまざまなプロパティがあります。仕様を書くときに心に留めたユースケースをカバーするために必要なメディアプロパティが定義されています。ただし、さらなるイノベーションにより、ここで指定されたものではカバーされないプロパティを持つ新しいユースケースまたはメディアストリームが生じることが予想されます。したがって、新しいメディアプロパティを指定できます。新しいメディアプロパティは、このプロパティの動作を正しく指定するために大量の新しい定義を必要とする場合があるため、バーは高くなるように設計されています。
Registering a new media property is done following the Specification Required policy [RFC5226]. The expert reviewer verifies that a registration request fulfills the following requirements.
新しいメディアプロパティの登録は、Specification Requiredポリシー[RFC5226]に従って行われます。エキスパートレビューアーは、登録リクエストが次の要件を満たしていることを確認します。
o An ABNF definition of the media property value name that meets "media-prop-ext" definition is included.
o 「media-prop-ext」定義を満たすメディアプロパティ値名のABNF定義が含まれています。
o A definition of which media property group it belongs to or define a new group is included.
o それが属するメディアプロパティグループの定義、または新しいグループを定義することが含まれます。
o A description of all changes to the behavior of RTSP as result of these changes is included.
o これらの変更の結果としてのRTSPの動作に対するすべての変更の説明が含まれています。
o A contact person for the registration is listed.
o 登録の担当者が表示されます。
This specification registers the ten values listed in Section 18.29. The registry contains the property group, the name of the media property, and the reference.
この仕様は、セクション18.29にリストされている10個の値を登録します。レジストリには、プロパティグループ、メディアプロパティの名前、および参照が含まれています。
Notify-Reason values are used to indicate the reason the notification was sent. Each reason has its associated rules on what headers and information may or must be included in the notification. New notification behaviors need to be specified to enable interoperable usage; thus, a specification of each new value is required.
Notify-Reason値は、通知が送信された理由を示すために使用されます。それぞれの理由には、通知に含めるヘッダーと情報を含める必要があるかどうかに関するルールが関連付けられています。相互運用可能な使用を可能にするには、新しい通知動作を指定する必要があります。したがって、それぞれの新しい値の指定が必要です。
Registrations for new Notify-Reason values follow the Specification Required policy [RFC5226]. The expert reviewer verifies that the request fulfills the following requirements:
新しいNotify-Reason値の登録は、Specification Requiredポリシー[RFC5226]に従います。エキスパートレビューアーは、要求が次の要件を満たしていることを確認します。
o An ABNF definition of the Notify-Reason value name that meets "Notify-Reason-extension" definition is included.
o 「Notify-Reason-extension」の定義を満たすNotify-Reason値の名前のABNF定義が含まれています。
o A description of which headers shall be included in the request and response, when it should be sent, and any effect it has on the server client state is made clear.
o 要求と応答に含まれるヘッダー、送信するタイミング、およびサーバークライアントの状態に及ぼす影響についての説明が明確になりました。
o A contact person for the registration is listed.
o 登録の担当者が表示されます。
This specification registers three values defined in the Notify-Reas-val ABNF, Section 20.2.3:
この仕様は、Notify-Reas-val ABNF、セクション20.2.3で定義された3つの値を登録します。
end-of-stream: This Notify-Reason value indicates the end of a media stream.
end-of-stream：このNotify-Reason値は、メディアストリームの終わりを示します。
media-properties-update: This Notify-Reason value allows the server to indicate that the properties of the media have changed during the playout.
media-properties-update：このNotify-Reason値により、サーバーは再生中にメディアのプロパティが変更されたことを示すことができます。
scale-change: This Notify-Reason value allows the server to notify the client about a change in the scale of the media.
scale-change：このNotify-Reason値により、サーバーはメディアのスケールの変更についてクライアントに通知できます。
The registry contains the name, description, and reference.
レジストリには、名前、説明、および参照が含まれています。
The Range header (Section 18.40) allows for different range formats. These range formats also need an identifier to be used in the Accept-Ranges header (Section 18.5). New range formats may be registered, but moderation should be applied as it makes interoperability more difficult.
Rangeヘッダー（セクション18.40）では、さまざまな範囲形式を使用できます。これらの範囲形式では、Accept-Rangesヘッダーで使用する識別子も必要です（セクション18.5）。新しい範囲形式が登録される可能性がありますが、相互運用性がより困難になるため、モデレートを適用する必要があります。
A registration follows the Specification Required policy [RFC5226]. The expert reviewer verifies that the request fulfills the following requirements:
登録は、Specification Requiredポリシー[RFC5226]に従います。エキスパートレビューアーは、要求が次の要件を満たしていることを確認します。
o An ABNF definition of the range format that fulfills the "range-ext" definition is included.
o 「範囲拡張」定義を満たす範囲フォーマットのABNF定義が含まれています。
o The range format identifier used in Accept-Ranges header according to the "extension-format" definition is defined.
o 「extension-format」定義に従ってAccept-Rangesヘッダーで使用される範囲フォーマット識別子が定義されています。
o Rules for how one handles the range when using a negative Scale are included.
o 負のスケールを使用するときに範囲を処理する方法に関するルールが含まれています。
o A contact person for the registration is listed.
o 登録の担当者が表示されます。
The registry contains the Range header format identifier, the name of the range format, and the reference. This specification registers the following values.
レジストリには、範囲ヘッダー形式の識別子、範囲形式の名前、および参照が含まれています。この仕様は以下の値を登録します。
npt: Normal Play Time
npt：通常の再生時間
clock: UTC Absolute Time format
クロック：UTC絶対時刻形式
smpte: SMPTE Timestamps
smpte：SMPTEタイムスタンプ
smpte-30-drop: SMPTE Timestamps 29.97 Frames/sec (30 Hz with Drop)
smpte-25: SMPTE Timestamps 25 Frames/sec
smpte-25：SMPTEタイムスタンプ25フレーム/秒
The Terminate-Reason header (Section 18.52) has two registries for extensions.
Terminate-Reasonヘッダー（セクション18.52）には、拡張用の2つのレジストリがあります。
This registry contains reasons for session termination that can be included in a Terminate-Reason header (Section 18.52). Registrations follow the Expert Review policy [RFC5226]. The expert reviewer verifies that the registration request contains the following information:
このレジストリには、Terminate-Reasonヘッダー（セクション18.52）に含めることができるセッション終了の理由が含まれています。登録はExpert Reviewポリシー[RFC5226]に従います。エキスパートレビューアーは、登録リクエストに次の情報が含まれていることを確認します。
o That the value follows the Terminate-Reason ABNF, i.e., be a token.
o 値がTerminate-Reason ABNFに従うこと、つまりトークンであること。
o That the specification provide a definition of what procedures are to be followed when a client receives this redirect reason.
o この仕様は、クライアントがこのリダイレクト理由を受け取ったときに実行される手順の定義を提供すること。
o A contact person
o 担当者
This specification registers three values:
この仕様は3つの値を登録します。
o Session-Timeout
o セッションタイムアウト
o Server-Admin
o サーバー管理者
o Internal-Error
o 内部エラー
The registry contains the name of the Redirect Reason and the reference.
レジストリには、リダイレクト理由の名前と参照が含まれています。
This registry contains parameters that may be included in the Terminate-Reason header (Section 18.52) in addition to a reason. Registrations are made under the Specification Required policy [RFC5226]. The expert reviewer verifies that the registration request contains the following:
このレジストリには、理由に加えてTerminate-Reasonヘッダー（セクション18.52）に含まれる可能性のあるパラメーターが含まれています。登録は、Specification Requiredポリシー[RFC5226]に基づいて行われます。専門家レビューアは、登録リクエストに以下が含まれていることを確認します。
o A parameter name.
o パラメータ名。
o A parameter following the syntax allowed by the RTSP 2.0 specification.
o RTSP 2.0仕様で許可されている構文に従うパラメーター。
o A reference to the specification.
o 仕様への参照。
o A contact person.
o 担当者。
This specification registers:
この仕様は以下を登録します。
o time
o 時間
o user-msg
o user-msg
The registry contains the name of the Terminate Reason and the reference.
レジストリには、終了理由の名前と参照が含まれています。
The RTP-Info header (Section 18.45) carries one or more parameter value pairs with information about a particular point in the RTP stream. RTP extensions or new usages may need new types of information. As RTP information that could be needed is likely to be generic enough, and to maximize the interoperability, new registration is made under the Specification Required policy.
RTP-Infoヘッダー（セクション18.45）は、RTPストリームの特定のポイントに関する情報を含む1つ以上のパラメーター値のペアを伝送します。 RTP拡張または新しい使用法では、新しいタイプの情報が必要になる場合があります。必要になる可能性のあるRTP情報は十分に汎用的であり、相互運用性を最大化する可能性が高いので、新規登録は仕様要求ポリシーの下で行われます。
Registrations for new RTP-Info values follow the policy of Specification Required [RFC5226]. The expert reviewer verifies that the registration request contains the following information.
新しいRTP-Info値の登録は、Specification Required [RFC5226]のポリシーに従います。専門家レビューアは、登録リクエストに次の情報が含まれていることを確認します。
o An ABNF definition that meets the "generic-param" definition.
o 「generic-param」定義を満たすABNF定義。
o A reference to the specification.
o 仕様への参照。
o A contact person for the registration.
o 登録の担当者。
This specification registers the following parameter value pairs:
この仕様は、次のパラメーター値のペアを登録します。
o url
o url
o ssrc
o ssrc
o seq
o シーケンス
o rtptime
o rtptime
The registry contains the name of the parameter and the reference.
レジストリには、パラメータの名前と参照が含まれています。
Seek-Style policy defines how the RTSP agent seeks in media content when given a position within the media content. New seek policies may be registered; however, a large number of these will complicate implementation substantially. The impact of unknown policies is that the server will not honor the unknown and will use the server default policy instead.
Seek-Styleポリシーは、RTSPエージェントがメディアコンテンツ内の位置を指定されたときに、メディアコンテンツ内でシークする方法を定義します。新しいシークポリシーを登録できます。ただし、これらの数が多いと、実装が大幅に複雑になります。不明なポリシーの影響は、サーバーが不明なポリシーを受け入れず、代わりにサーバーのデフォルトポリシーを使用することです。
Registrations of new Seek-Style policies follow the Specification Required policy [RFC5226]. The expert reviewer verifies that the registration request fulfills the following requirements:
新しいSeek-Styleポリシーの登録は、Specification Requiredポリシー[RFC5226]に従います。エキスパートレビューアーは、登録リクエストが次の要件を満たしていることを確認します。
o Has an ABNF definition of the Seek-Style policy name that meets "Seek-S-value-ext" definition.
o 「Seek-S-value-ext」の定義を満たすSeek-Styleポリシー名のABNF定義があります。
o Includes a short description.
o 短い説明が含まれています。
o Lists a contact person for the registration.
o 登録の担当者をリストします。
o Includes a description of which headers shall be included in the request and response, when it should be sent, and any affect it has on the server-client state.
o 要求と応答に含まれるヘッダー、送信するタイミング、およびサーバーとクライアントの状態への影響についての説明が含まれています。
This specification registers four values (Name - Short Description):
この仕様は4つの値（名前-短い説明）を登録します。
o RAP - Using the closest Random Access Point prior to or at the requested start position.
o RAP-要求された開始位置の前またはその位置で最も近いランダムアクセスポイントを使用します。
o CoRAP - Conditional Random Access Point is like RAP, but only if the RAP is closer prior to the requested start position than current pause point.
o CoRAP-条件付きランダムアクセスポイントはRAPに似ていますが、RAPが要求された開始位置の前に現在の一時停止ポイントよりも近い場合のみです。
o First-Prior - The first-prior policy will start delivery with the media unit that has a playout time first prior to the requested start position.
o First-Prior-first-priorポリシーは、要求された開始位置の前に最初にプレイアウト時間があるメディアユニットから配信を開始します。
o Next - The next media units after the provided start position.
o 次-指定された開始位置の次のメディアユニット。
The registry contains the name of the Seek-Style policy, the description, and the reference.
レジストリには、シークスタイルポリシーの名前、説明、および参照が含まれています。
The transport header (Section 18.54) contains a number of parameters that have possibilities for future extensions. Therefore, registries for these are defined below.
トランスポートヘッダー（セクション18.54）には、将来の拡張の可能性があるいくつかのパラメーターが含まれています。したがって、これらのレジストリは以下に定義されています。
A Transport Protocol specification consists of a transport protocol identifier, representing some combination of transport protocols, and any number of transport header parameters required or optional to use with the identified protocol specification. This registry contains the identifiers used by registered transport protocol identifiers.
トランスポートプロトコル仕様は、トランスポートプロトコルのいくつかの組み合わせを表すトランスポートプロトコル識別子と、識別されたプロトコル仕様で使用するために必要または任意の数のトランスポートヘッダーパラメーターで構成されます。このレジストリには、登録されているトランスポートプロトコル識別子によって使用される識別子が含まれています。
A registration for the parameter transport protocol identifier follows the Specification Required policy [RFC5226]. The expert reviewer verifies that the registration request fulfills the following requirements:
パラメータトランスポートプロトコル識別子の登録は、Specification Requiredポリシー[RFC5226]に従います。エキスパートレビューアーは、登録リクエストが次の要件を満たしていることを確認します。
o A contact person or organization with address and email.
o 連絡先または組織のアドレスと電子メール。
o A value definition that follows the ABNF syntax definition of "transport-id" Section 20.2.3.
o 「transport-id」セクション20.2.3のABNF構文定義に続く値の定義。
o A descriptive text that explains how the registered values are used in RTSP, which underlying transport protocols are used, and any required Transport header parameters.
o 登録された値がRTSPでどのように使用されるか、基になるトランスポートプロトコルが使用される方法、および必要なトランスポートヘッダーパラメーターを説明する説明テキスト。
The registry contains the protocol ID string and the reference.
レジストリには、プロトコルID文字列と参照が含まれています。
This specification registers the following values:
この仕様は、次の値を登録します。
RTP/AVP: Use of the RTP [RFC3550] protocol for media transport in combination with the "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551] over UDP. The usage is explained in RFC 7826, Appendix C.1.
RTP / AVP：メディアトランスポート用のRTP [RFC3550]プロトコルとUDPを介した「最小制御のオーディオおよびビデオ会議のRTPプロファイル」[RFC3551]の組み合わせ。使用方法はRFC 7826の付録C.1で説明されています。
RTP/AVP/UDP: the same as RTP/AVP.
RTP / AVP / UDP：RTP / AVPと同じ。
RTP/AVPF: Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended RTP Profile for RTCP-based Feedback (RTP/AVPF)" [RFC4585] over UDP. The usage is explained in RFC 7826, Appendix C.1.
RTP / AVPF：メディアトランスポート用のRTP [RFC3550]プロトコルとUDPを介した「RTCPベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF）」[RFC4585]の組み合わせ。使用方法はRFC 7826の付録C.1で説明されています。
RTP/AVPF/UDP: the same as RTP/AVPF.
RTP / AVPF / UDP：RTP / AVPFと同じです。
RTP/SAVP: Use of the RTP [RFC3550] protocol for media transport in combination with the "The Secure Real-time Transport Protocol (SRTP)" [RFC3711] over UDP. The usage is explained in RFC 7826, Appendix C.1.
RTP / SAVP：UDP上の「セキュアリアルタイムトランスポートプロトコル（SRTP）」[RFC3711]と組み合わせたメディアトランスポート用のRTP [RFC3550]プロトコルの使用。使用法はRFC 7826の付録C.1で説明されています。
RTP/SAVP/UDP: the same as RTP/SAVP.
RTP / SAVP / UDP：RTP / SAVPと同じです。
RTP/SAVPF: Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] over UDP. The usage is explained in RFC 7826, Appendix C.1.
RTP / SAVPF：メディア転送にRTP [RFC3550]プロトコルを使用し、「リアルタイム転送制御プロトコル（RTCP）ベースの拡張セキュアRTPプロファイル（RTP）ベースのフィードバック（RTP / SAVPF）」[RFC5124]とUDPを組み合わせて使用します。使用方法はRFC 7826の付録C.1で説明されています。
RTP/SAVPF/UDP: the same as RTP/SAVPF.
RTP / SAVPF / UDP：RTP / SAVPFと同じです。
RTP/AVP/TCP: Use of the RTP [RFC3550] protocol for media transport in combination with the "RTP profile for audio and video conferences with minimal control" [RFC3551] over TCP. The usage is explained in RFC 7826, Appendix C.2.2.
RTP / AVP / TCP：メディアトランスポート用のRTP [RFC3550]プロトコルとTCPを介した「最小限の制御によるオーディオおよびビデオ会議のRTPプロファイル」[RFC3551]の組み合わせ。使用法はRFC 7826の付録C.2.2で説明されています。
RTP/AVPF/TCP: Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)" [RFC4585] over TCP. The usage is explained in RFC 7826, Appendix C.2.2.
RTP / AVPF / TCP：メディアトランスポート用のRTP [RFC3550]プロトコルと「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック（RTP / AVPF）の拡張RTPプロファイル」[RFC4585]を組み合わせたTCPの使用。使用法はRFC 7826の付録C.2.2で説明されています。
RTP/SAVP/TCP: Use of the RTP [RFC3550] protocol for media transport in combination with the "The Secure Real-time Transport Protocol (SRTP)" [RFC3711] over TCP. The usage is explained in RFC 7826, Appendix C.2.2.
RTP / SAVP / TCP：メディアトランスポートにRTP [RFC3550]プロトコルを使用し、TCP上の「セキュアリアルタイムトランスポートプロトコル（SRTP）」[RFC3711]と組み合わせて使用します。使用法はRFC 7826の付録C.2.2で説明されています。
RTP/SAVPF/TCP: Use of the RTP [RFC3550] protocol for media transport in combination with the "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ SAVPF)" [RFC5124] over TCP. The usage is explained in RFC 7826, Appendix C.2.2.
RTP / SAVPF / TCP：メディアトランスポート用のRTP [RFC3550]プロトコルと「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」[RFC5124]を組み合わせたTCPの使用。使用法はRFC 7826の付録C.2.2で説明されています。
The Transport Mode is a Transport header (Section 18.54) parameter. It is used to identify the general mode of media transport. The PLAY value registered defines a PLAYBACK mode, where media flows from server to client.
トランスポートモードは、トランスポートヘッダー（セクション18.54）パラメータです。メディア転送の一般的なモードを識別するために使用されます。登録されたPLAY値は、メディアがサーバーからクライアントに流れるPLAYBACKモードを定義します。
A registration for the transport parameter mode follows the Standards Action policy [RFC5226]. The registration request needs to meet the following requirements:
トランスポートパラメータモードの登録は、標準アクションポリシー[RFC5226]に従います。登録リクエストは次の要件を満たす必要があります。
o A value definition that follows the ABNF "token" definition Section 20.2.3.
o ABNFの「トークン」定義セクション20.2.3に従う値の定義。
o Text that explains how the registered value is used in RTSP.
o 登録された値がRTSPでどのように使用されるかを説明するテキスト。
This specification registers one value:
この仕様は1つの値を登録します。
PLAY: See RFC 7826.
再生：RFC 7826を参照してください。
The registry contains the transport mode value and the reference.
レジストリには、トランスポートモードの値と参照が含まれています。
Transport Parameters are different parameters used in a Transport header's transport specification (Section 18.54) to provide additional information required beyond the transport protocol identifier to establish a functioning transport.
トランスポートパラメーターは、機能するトランスポートを確立するためにトランスポートプロトコル識別子以外に必要な追加情報を提供するためにトランスポートヘッダーのトランスポート仕様（セクション18.54）で使用されるさまざまなパラメーターです。
A registration for parameters that may be included in the Transport header follows the Specification Required policy [RFC5226]. The expert reviewer verifies that the registration request fulfills the following requirements:
Transportヘッダーに含まれる可能性のあるパラメーターの登録は、Specification Requiredポリシー[RFC5226]に従います。エキスパートレビューアーは、登録リクエストが次の要件を満たしていることを確認します。
o A Transport Parameter Name following the "token" ABNF definition.
o 「トークン」ABNF定義に従うトランスポートパラメータ名。
o A value definition, if the parameter takes a value, that follows the ABNF definition of "trn-par-value" Section 20.2.3.
o パラメータが値をとる場合の値の定義は、「trn-par-value」セクション20.2.3のABNF定義に従います。
o Text that explains how the registered value is used in RTSP.
o 登録された値がRTSPでどのように使用されるかを説明するテキスト。
This specification registers all the transport parameters defined in Section 18.54. This is a copy of that list:
この仕様は、セクション18.54で定義されているすべてのトランスポートパラメータを登録します。これはそのリストのコピーです：
o unicast
o ユニキャスト
o multicast
o マルチキャスト
o interleaved
o インターリーブ
o ttl
o ttl
o layers
o レイヤー
o ssrc
o ssrc
o mode
o モード
o dest_addr
o dest_addr
o src_addr
o src_addr
o setup
o セットアップ
o connection
o 接続
o RTCP-mux
o RTCP-mux
o MIKEY
o MIKEY
The registry contains the transport parameter name and the reference.
レジストリには、トランスポートパラメータ名と参照が含まれています。
This specification updates two URI schemes: one previously registered, "rtsp", and one missing in the registry, "rtspu" (previously only defined in RTSP 1.0 [RFC2326]). One new URI scheme, "rtsps", is also registered. These URI schemes are registered in an existing registry ("Uniform Resource Identifier (URI) Schemes") not created by this memo. Registrations follow [RFC7595].
この仕様は、2つのURIスキームを更新します。1つは以前に登録された「rtsp」、もう1つはレジストリに欠落している「rtspu」です（以前はRTSP 1.0 [RFC2326]でのみ定義されていました）。 1つの新しいURIスキームである「rtsps」も登録されています。これらのURIスキームは、このメモでは作成されていない既存のレジストリ（「Uniform Resource Identifier（URI）スキーム」）に登録されています。登録は[RFC7595]に従います。
URI scheme name: rtsp
URIスキーム名：rtsp
Status: Permanent
ステータス：永久
URI scheme syntax: See Section 20.2.1 of RFC 7826.
URIスキームの構文：RFC 7826のセクション20.2.1を参照してください。
URI scheme semantics: The rtsp scheme is used to indicate resources accessible through the usage of the Real-Time Streaming Protocol (RTSP). RTSP allows different operations on the resource identified by the URI, but the primary purpose is the streaming delivery of the resource to a client. However, the operations that are currently defined are DESCRIBE, GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, SETUP, SET_PARAMETER, and TEARDOWN.
URIスキームのセマンティクス：rtspスキームは、リアルタイムストリーミングプロトコル（RTSP）の使用を通じてアクセス可能なリソースを示すために使用されます。 RTSPは、URIで識別されるリソースに対してさまざまな操作を許可しますが、主な目的は、クライアントへのリソースのストリーミング配信です。ただし、現在定義されている操作は、DESCRIBE、GET_PARAMETER、OPTIONS、PLAY、PLAY_NOTIFY、PAUSE、REDIRECT、SETUP、SET_PARAMETER、およびTEARDOWNです。
Encoding considerations: IRIs in this scheme are defined and need to be encoded as RTSP URIs when used within RTSP. That encoding is done according to RFC 3987.
エンコードに関する考慮事項：このスキームのIRIは定義されており、RTSP内で使用する場合はRTSP URIとしてエンコードする必要があります。そのエンコードはRFC 3987に従って行われます。
Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 2326), RTSP 2.0 (RFC 7826).
このURIスキーム名を使用するアプリケーション/プロトコル：RTSP 1.0（RFC 2326）、RTSP 2.0（RFC 7826）。
Interoperability considerations: The extensions in the URI syntax performed between RTSP 1.0 and 2.0 can create interoperability issues. The changes are:
相互運用性に関する考慮事項：RTSP 1.0と2.0の間で実行されるURI構文の拡張により、相互運用性の問題が発生する可能性があります。変更点は次のとおりです。
Support for IPv6 literals in the host part and future IP literals through a mechanism as defined in RFC 3986.
RFC 3986で定義されたメカニズムによるホスト部分のIPv6リテラルおよび将来のIPリテラルのサポート。
A new relative format to use in RTSP elements that is not required to start with "/".
「/」で始める必要のない、RTSP要素で使用する新しい相対形式。
The above changes should have no impact on interoperability as discussed in detail in Section 4.2 of RFC 7826.
RFC 7826のセクション4.2で詳細に説明されているように、上記の変更は相互運用性に影響を与えません。
Security considerations: All the security threats identified in Section 7 of RFC 3986 also apply to this scheme. They need to be reviewed and considered in any implementation utilizing this scheme.
セキュリティに関する考慮事項：RFC 3986のセクション7で特定されているすべてのセキュリティの脅威は、このスキームにも適用されます。これらは、このスキームを利用するすべての実装で確認および検討する必要があります。
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
連絡先：Magnus Westerlund、magnus.westerlund @ ericsson.com
Author/Change controller: IETF
作成者/変更コントローラ：IETF
References: RFC 2326, RFC 3986, RFC 3987, and RFC 7826
参照：RFC 2326、RFC 3986、RFC 3987、およびRFC 7826
URI scheme name: rtsps
URIスキーム名：rtsps
Status: Permanent
ステータス：永久
URI scheme syntax: See Section 20.2.1 of RFC 7826.
URIスキームの構文：RFC 7826のセクション20.2.1を参照してください。
URI scheme semantics: The rtsps scheme is used to indicate resources accessible through the usage of the Real-Time Streaming Protocol (RTSP) over TLS. RTSP allows different operations on the resource identified by the URI, but the primary purpose is the streaming delivery of the resource to a client. However, the operations that are currently defined are DESCRIBE, GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT, SETUP, SET_PARAMETER, and TEARDOWN.
URIスキームのセマンティクス：rtspsスキームは、TLSを介したリアルタイムストリーミングプロトコル（RTSP）の使用を通じてアクセス可能なリソースを示すために使用されます。 RTSPは、URIで識別されるリソースに対してさまざまな操作を許可しますが、主な目的は、クライアントへのリソースのストリーミング配信です。ただし、現在定義されている操作は、DESCRIBE、GET_PARAMETER、OPTIONS、PLAY、PLAY_NOTIFY、PAUSE、REDIRECT、SETUP、SET_PARAMETER、およびTEARDOWNです。
Encoding considerations: IRIs in this scheme are defined and need to be encoded as RTSP URIs when used within RTSP. That encoding is done according to RFC 3987.
エンコードに関する考慮事項：このスキームのIRIは定義されており、RTSP内で使用する場合はRTSP URIとしてエンコードする必要があります。そのエンコードはRFC 3987に従って行われます。
Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 2326), RTSP 2.0 (RFC 7826).
このURIスキーム名を使用するアプリケーション/プロトコル：RTSP 1.0（RFC 2326）、RTSP 2.0（RFC 7826）。
Interoperability considerations: The "rtsps" scheme was never officially defined for RTSP 1.0; however, it has seen widespread use in actual deployments of RTSP 1.0. Therefore, this section discusses the believed changes between the unspecified RTSP 1.0 "rtsps" scheme and RTSP 2.0 definition. The extensions in the URI syntax performed between RTSP 1.0 and 2.0 can create interoperability issues. The changes are:
相互運用性に関する考慮事項：「rtsps」スキームは、RTSP 1.0に対して公式に定義されたことはありません。ただし、RTSP 1.0の実際の展開で広く使用されています。したがって、このセクションでは、未指定のRTSP 1.0 "rtsps"スキームとRTSP 2.0定義の間の信頼できる変更について説明します。 RTSP 1.0と2.0の間で実行されるURI構文の拡張により、相互運用性の問題が発生する可能性があります。変更点は次のとおりです。
Support for IPv6 literals in the host part and future IP literals through a mechanism as defined by RFC 3986.
RFC 3986で定義されているメカニズムによるホスト部分のIPv6リテラルおよび将来のIPリテラルのサポート。
A new relative format to use in RTSP elements that is not required to start with "/".
「/」で始める必要のない、RTSP要素で使用する新しい相対形式。
The above changes should have no impact on interoperability as discussed in detail in Section 4.2 of RFC 7826.
RFC 7826のセクション4.2で詳細に説明されているように、上記の変更は相互運用性に影響を与えません。
Security considerations: All the security threats identified in Section 7 of RFC 3986 also apply to this scheme. They need to be reviewed and considered in any implementation utilizing this scheme.
セキュリティに関する考慮事項：RFC 3986のセクション7で特定されているすべてのセキュリティの脅威は、このスキームにも適用されます。これらは、このスキームを利用するすべての実装で確認および検討する必要があります。
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
連絡先：Magnus Westerlund、magnus.westerlund @ ericsson.com
Author/Change controller: IETF
作成者/変更コントローラ：IETF
References: RFC 2326, RFC 3986, RFC 3987, and RFC 7826
参照：RFC 2326、RFC 3986、RFC 3987、およびRFC 7826
URI scheme name: rtspu
URIスキーム名：rtspu
Status: Permanent
ステータス：永久
URI scheme syntax: See Section 3.2 of RFC 2326.
URIスキームの構文：RFC 2326のセクション3.2をご覧ください。
URI scheme semantics: The rtspu scheme is used to indicate resources accessible through the usage of the Real-Time Streaming Protocol (RTSP) over unreliable datagram transport. RTSP allows different operations on the resource identified by the URI, but the primary purpose is the streaming delivery of the resource to a client. However, the operations that are currently defined are DESCRIBE, GET_PARAMETER, OPTIONS, REDIRECT,PLAY, PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER, and TEARDOWN.
URIスキームのセマンティクス：rtspuスキームは、信頼性の低いデータグラムトランスポートを介したリアルタイムストリーミングプロトコル（RTSP）の使用を通じてアクセス可能なリソースを示すために使用されます。 RTSPは、URIで識別されるリソースに対してさまざまな操作を許可しますが、主な目的は、クライアントへのリソースのストリーミング配信です。ただし、現在定義されている操作は、DESCRIBE、GET_PARAMETER、OPTIONS、REDIRECT、PLAY、PLAY_NOTIFY、PAUSE、SETUP、SET_PARAMETER、およびTEARDOWNです。
Encoding considerations: This scheme is not intended to be used with characters outside the US-ASCII repertoire.
エンコーディングに関する考慮事項：このスキームは、US-ASCIIレパートリー外の文字で使用することを意図していません。
Applications/protocols that use this URI scheme name: RTSP 1.0 (RFC 2326).
このURIスキーム名を使用するアプリケーション/プロトコル：RTSP 1.0（RFC 2326）。
Interoperability considerations: The definition of the transport mechanism of RTSP over UDP has interoperability issues. That makes the usage of this scheme problematic.
相互運用性に関する考慮事項：RTSP over UDPのトランスポートメカニズムの定義には、相互運用性の問題があります。そのため、このスキームの使用には問題があります。
Security considerations: All the security threats identified in Section 7 of RFC 3986 also apply to this scheme. They need to be reviewed and considered in any implementation utilizing this scheme.
セキュリティに関する考慮事項：RFC 3986のセクション7で特定されているすべてのセキュリティの脅威は、このスキームにも適用されます。これらは、このスキームを利用するすべての実装で確認および検討する必要があります。
Contact: Magnus Westerlund, magnus.westerlund@ericsson.com
連絡先：Magnus Westerlund、magnus.westerlund @ ericsson.com
Author/Change controller: IETF
作成者/変更コントローラ：IETF
References: RFC 2326
参照：RFC 2326
This specification defines three SDP [RFC4566] attributes that have been registered by IANA.
この仕様は、IANAによって登録された3つのSDP [RFC4566]属性を定義しています。
SDP Attribute ("att-field"):
SDP属性（ "att-field"）：
Attribute name: range Long form: Media Range Attribute Type of name: att-field Type of attribute: both session and media level Subject to charset: No Purpose: RFC 7826 Reference: RFC 2326, RFC 7826 Values: See ABNF definition.
属性名：範囲長い形式：メディア範囲属性名前のタイプ：att-field属性のタイプ：セッションとメディアレベルの両方文字セットの対象：いいえ目的：RFC 7826リファレンス：RFC 2326、RFC 7826値：ABNF定義を参照してください。
Attribute name: control Long form: RTSP control URI Type of name: att-field Type of attribute: both session and media level Subject to charset: No Purpose: RFC 7826 Reference: RFC 2326, RFC 7826 Values: Absolute or Relative URIs.
属性名：control長い形式：RTSPコントロールURI名前のタイプ：att-field属性のタイプ：セッションとメディアレベルの両方charsetの対象：いいえ目的：RFC 7826リファレンス：RFC 2326、RFC 7826値：絶対URIまたは相対URI。
Attribute name: mtag Long form: Message Tag Type of name: att-field Type of attribute: both session and media level Subject to charset: No Purpose: RFC 7826 Reference: RFC 7826 Values: See ABNF definition
属性名：mtag長形式：メッセージタグ名前のタイプ：att-field属性のタイプ：セッションとメディアレベルの両方charsetの対象：いいえ目的：RFC 7826リファレンス：RFC 7826値：ABNF定義を参照
Type name: text
タイプ名：テキスト
Subtype name: parameters
サブタイプ名：パラメータ
Required parameters:
必須パラメーター：
Optional parameters: charset: The charset parameter is applicable to the encoding of the parameter values. The default charset is UTF-8, if the 'charset' parameter is not present.
オプションのパラメーター：charset：charsetパラメーターは、パラメーター値のエンコードに適用できます。 'charset'パラメータが存在しない場合、デフォルトの文字セットはUTF-8です。
Encoding considerations: 8bit Security considerations: This format may carry any type of parameters. Some can have security requirements, like privacy, confidentiality, or integrity requirements. The format has no built-in security protection. For the usage, the transport can be protected between server and client using TLS. However, care must be taken to consider if the proxies are also trusted with the parameters in case hop-by-hop security is used. If stored as a file in a file system, the necessary precautions need to be taken in relation to the parameter requirements including object security such as S/MIME [RFC5751].
エンコーディングに関する考慮事項：8ビットセキュリティに関する考慮事項：この形式では、任意のタイプのパラメーターを使用できます。プライバシー、機密性、整合性などのセキュリティ要件を持つものもあります。この形式には、組み込みのセキュリティ保護機能はありません。使用方法については、TLSを使用してサーバーとクライアントの間でトランスポートを保護できます。ただし、ホップバイホップのセキュリティが使用されている場合に備えて、プロキシがパラメータで信頼されているかどうかを考慮するように注意する必要があります。ファイルシステムにファイルとして保存する場合、S / MIME [RFC5751]などのオブジェクトセキュリティを含むパラメータ要件に関して、必要な予防策を講じる必要があります。
Interoperability considerations: This media type was mentioned as a fictional example in [RFC2326], but was not formally specified. This has resulted in usage of this media type that may not match its formal definition.
相互運用性に関する考慮事項：このメディアタイプは、[RFC2326]で架空の例として言及されましたが、正式には指定されていませんでした。このため、このメディアタイプが正式な定義と一致しない可能性があります。
Published specification: RFC 7826, Appendix F.
公開された仕様：RFC 7826、付録F。
Applications that use this media type: Applications that use RTSP and have additional parameters they like to read and set using the RTSP GET_PARAMETER and SET_PARAMETER methods.
このメディアタイプを使用するアプリケーション：RTSPを使用し、RTSP GET_PARAMETERメソッドとSET_PARAMETERメソッドを使用して読み取りと設定を行う追加のパラメーターがあるアプリケーション。
Additional information:
追加情報：
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information: Magnus Westerlund (magnus.westerlund@ericsson.com)
詳細について連絡する人とメールアドレス：Magnus Westerlund（magnus.westerlund@ericsson.com）
Intended usage: Common
使用目的：一般
Restrictions on usage: None
使用上の制限：なし
Author: Magnus Westerlund (magnus.westerlund@ericsson.com)
Change controller: IETF
コントローラの変更：IETF
Addition Notes:
追加メモ：
[FIPS180-4] National Institute of Standards and Technology (NIST), "Federal Information Processing Standards Publication: Secure Hash Standard (SHS)", DOI 10.6028/NIST.FIPS.180-4, August 2015, <http://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.
[FIPS180-4]米国国立標準技術研究所（NIST）、「Federal Information Processing Standards Publication：Secure Hash Standard（SHS）」、DOI 10.6028 / NIST.FIPS.180-4、2015年8月、<http：// nvlpubs .nist.gov / nistpubs / FIPS / NIST.FIPS.180-4.pdf>。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<http://www.rfc-editor.org/info/rfc768>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, DOI 10.17487/RFC2616, June 1999, <http://www.rfc-editor.org/info/rfc2616>.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、DOI 10.17487 / RFC2616、1999年6月、<http://www.rfc-editor.org/info/rfc2616>。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, DOI 10.17487/RFC2617, June 1999, <http://www.rfc-editor.org/info/rfc2617>.
[RFC2617] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP Authentication：Basic and Digest Access Authentication」 、RFC 2617、DOI 10.17487 / RFC2617、1999年6月、<http://www.rfc-editor.org/info/rfc2617>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<http://www.rfc-editor.org/info/rfc2818>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <http://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、 <http://www.rfc-editor.org/info/rfc3550>。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <http://www.rfc-editor.org/info/rfc3551>.
[RFC3551] Schulzrinne、H。およびS. Casner、「Minimal Controlを使用したオーディオおよびビデオ会議のRTPプロファイル」、STD 65、RFC 3551、DOI 10.17487 / RFC3551、2003年7月、<http：//www.rfc-editor。 org / info / rfc3551>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<http://www.rfc-editor.org/info/ rfc3629>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <http://www.rfc-editor.org/info/rfc3711>.
[RFC3711]バウアー、M。、マクルー、D。、ナスルンド、M。、カララ、E。、およびK.ノーマン、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004、<http://www.rfc-editor.org/info/rfc3711>。
[RFC3830] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K. Norrman, "MIKEY: Multimedia Internet KEYing", RFC 3830, DOI 10.17487/RFC3830, August 2004, <http://www.rfc-editor.org/info/rfc3830>.
[RFC3830] Arkko、J.、Carrara、E.、Lindholm、F.、Naslund、M.、and K. Norrman、 "MIKEY：Multimedia Internet KEYing"、RFC 3830、DOI 10.17487 / RFC3830、August 2004、<http： //www.rfc-editor.org/info/rfc3830>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<http：/ /www.rfc-editor.org/info/rfc3986>。
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, DOI 10.17487/RFC3987, January 2005, <http://www.rfc-editor.org/info/rfc3987>.
[RFC3987] Duerst、M。およびM. Suignard、「Internationalized Resource Identifiers（IRIs）」、RFC 3987、DOI 10.17487 / RFC3987、2005年1月、<http://www.rfc-editor.org/info/rfc3987>。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, DOI 10.17487/RFC4086, June 2005, <http://www.rfc-editor.org/info/rfc4086>.
[RFC4086] Eastlake 3rd、D.、Schiller、J.、and S. Crocker、 "Randomness Requirements for Security"、BCP 106、RFC 4086、DOI 10.17487 / RFC4086、June 2005、<http：//www.rfc-editor .org / info / rfc4086>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<http://www.rfc-editor.org/info/rfc4291>。
[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <http://www.rfc-editor.org/info/rfc7595>.
[RFC7595] Thaler、D.、Ed。、Hansen、T。、およびT. Hardie、「URIスキームのガイドラインと登録手順」、BCP 35、RFC 7595、DOI 10.17487 / RFC7595、2015年6月、<http：// www.rfc-editor.org/info/rfc7595>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<http://www.rfc-editor.org/ info / rfc4566>。
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July 2006, <http://www.rfc-editor.org/info/rfc4571>.
[RFC4571] Lazzaro、J。、「コネクション型トランスポートを介したフレーミングリアルタイムトランスポートプロトコル（RTP）およびRTP制御プロトコル（RTCP）パケット」、RFC 4571、DOI 10.17487 / RFC4571、2006年7月、<http：// www .rfc-editor.org / info / rfc4571>。
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, July 2006, <http://www.rfc-editor.org/info/rfc4585>.
[RFC4585] Ott、J.、Wenger、S.、Sato、N.、Burmeister、C。、およびJ. Rey、「リアルタイムトランスポートコントロールプロトコル（RTCP）ベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF） "、RFC 4585、DOI 10.17487 / RFC4585、2006年7月、<http://www.rfc-editor.org/info/rfc4585>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。
[RFC4738] Ignjatic, D., Dondeti, L., Audet, F., and P. Lin, "MIKEY-RSA-R: An Additional Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 4738, DOI 10.17487/RFC4738, November 2006, <http://www.rfc-editor.org/info/rfc4738>.
[RFC4738] Ignjatic、D.、Dondeti、L.、Audet、F。、およびP. Lin、「MIKEY-RSA-R：マルチメディアインターネットキーイング（MIKEY）でのキー配布の追加モード」、RFC 4738、DOI 10.17487 / RFC4738、2006年11月、<http://www.rfc-editor.org/info/rfc4738>。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <http://www.rfc-editor.org/info/rfc5124>.
[RFC5124] Ott、J。およびE. Carrara、「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<http ：//www.rfc-editor.org/info/rfc5124>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <http://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<http://www.rfc-editor.org/info/rfc5322>。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <http://www.rfc-editor.org/info/rfc5646>.
[RFC5646]フィリップス、A。、エド。 M.デイビス編、「言語を識別するためのタグ」、BCP 47、RFC 5646、DOI 10.17487 / RFC5646、2009年9月、<http://www.rfc-editor.org/info/rfc5646>。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <http://www.rfc-editor.org/info/rfc5751>.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、DOI 10.17487 / RFC5751、2010年1月、<http：//www.rfc- editor.org/info/rfc5751>。
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010, <http://www.rfc-editor.org/info/rfc5761>.
[RFC5761] Perkins、C。およびM. Westerlund、「Multiplexing RTP Data and Control Packets on a Single Port」、RFC 5761、DOI 10.17487 / RFC5761、2010年4月、<http://www.rfc-editor.org/info / rfc5761>。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, <http://www.rfc-editor.org/info/rfc5888>.
[RFC5888] Camarillo、G。およびH. Schulzrinne、「セッション記述プロトコル（SDP）グループ化フレームワーク」、RFC 5888、DOI 10.17487 / RFC5888、2010年6月、<http://www.rfc-editor.org/info/ rfc5888>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「Media Type Specifications and Registration Procedures」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<http：//www.rfc- editor.org/info/rfc6838>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<http://www.rfc-editor.org/info/rfc7231 >。
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 10.17487/RFC7232, June 2014, <http://www.rfc-editor.org/info/rfc7232>.
[RFC7232]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Conditional Requests」、RFC 7232、DOI 10.17487 / RFC7232、2014年6月、<http://www.rfc-editor.org/info/rfc7232> 。
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Range Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014, <http://www.rfc-editor.org/info/rfc7233>.
[RFC7233] Fielding、R.、Ed。、Lafon、Y.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Range Requests"、RFC 7233、DOI 10.17487 / RFC7233、June 2014、<http://www.rfc-editor.org/info/rfc7233>。
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", RFC 7234, DOI 10.17487/RFC7234, June 2014, <http://www.rfc-editor.org/info/rfc7234>.
[RFC7234] Fielding、R.、Ed。、Nottingham、M.、Ed。、and J. Reschke、Ed。、 "Hypertext Transfer Protocol（HTTP / 1.1）：Caching"、RFC 7234、DOI 10.17487 / RFC7234、June 2014 、<http://www.rfc-editor.org/info/rfc7234>。
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Authentication", RFC 7235, DOI 10.17487/RFC7235, June 2014, <http://www.rfc-editor.org/info/rfc7235>.
[RFC7235]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Authentication」、RFC 7235、DOI 10.17487 / RFC7235、2014年6月、<http://www.rfc-editor.org/info/rfc7235>。
[RFC7615] Reschke, J., "HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields", RFC 7615, DOI 10.17487/RFC7615, September 2015, <http://www.rfc-editor.org/info/rfc7615>.
[RFC7615] Reschke、J。、「HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields」、RFC 7615、DOI 10.17487 / RFC7615、2015年9月、<http://www.rfc-editor.org/info/ rfc7615>。
[RFC7616] Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP Digest Access Authentication", RFC 7616, DOI 10.17487/RFC7616, September 2015, <http://www.rfc-editor.org/info/rfc7616>.
[RFC7616] Shekh-Yusef、R.、Ed。、Ahrens、D。、およびS. Bremer、「HTTP Digest Access Authentication」、RFC 7616、DOI 10.17487 / RFC7616、2015年9月、<http：//www.rfc- editor.org/info/rfc7616>。
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <http://www.rfc-editor.org/info/rfc7617>.
[RFC7617] Reschke、J。、「The 'Basic' HTTP Authentication Scheme」、RFC 7617、DOI 10.17487 / RFC7617、2015年9月、<http://www.rfc-editor.org/info/rfc7617>。
[RFC7825] Goldberg, J., Westerlund, M., and T. Zeng, "A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by Real-Time Streaming Protocol (RTSP)", RFC 7825, DOI 10.17487/RFC7825, December 2016, <http://www.rfc-editor.org/info/rfc7825>.
[RFC7825] Goldberg、J.、Westerlund、M。、およびT. Zeng、「リアルタイムストリーミングプロトコル（RTSP）によって制御されるメディアのネットワークアドレス変換（NAT）トラバーサルメカニズム」、RFC 7825、DOI 10.17487 / RFC7825、 2016年12月、<http://www.rfc-editor.org/info/rfc7825>。
[RTP-CIRCUIT-BREAKERS] Perkins, C. and V. Singh, "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions", Work in Progress, draft-ietf-avtcore-rtp-circuit-breakers-13, February 2016.
[RTP-CIRCUIT-BREAKERS]パーキンス、C。およびV.シン、「マルチメディア輻輳制御：ユニキャストRTPセッション用のサーキットブレーカー」、作業中、draft-ietf-avtcore-rtp-circuit-breakers-13、2016年2月。
[SMPTE-TC] Society of Motion Picture and Television Engineers, "ST 12-1:2008 For Television -- Time and Control Code", DOI 10.5594/SMPTE.ST12-1.2008, February 2008, <http://ieeexplore.ieee.org/servlet/ opac?punumber=7289818>.
[SMPTE-TC] Society of Motion Picture and Television Engineers、「ST 12-1：2008 For Television-Time and Control Code」、DOI 10.5594 / SMPTE.ST12-1.2008、2008年2月、<http://ieeexplore.ieee .org / servlet / opac？punumber = 7289818>。
[TS-26234] 3rd Generation Partnership Project (3GPP), "Transparent end-to-end Packet-switched Streaming Service (PSS); Protocols and codecs", Technical Specification 26.234, Release 13, September 2015, <http://www.3gpp.org/DynaReport/26234.htm>.
[TS-26234] 3rd Generation Partnership Project（3GPP）、「Transparent end-to-end Packet-switched Streaming Service（PSS）; Protocols and codecs」、技術仕様26.234、リリース13、2015年9月、<http：// www .3gpp.org / DynaReport / 26234.htm>。
[ISO.13818-6.1995] International Organization for Standardization, "Information technology -- Generic coding of moving pictures and associated audio information - part 6: Extension for DSM-CC", ISO Draft Standard 13818-6:1998, October 1998, <http://www.iso.org/iso/home/store/catalogue_tc/ catalogue_detail.htm?csnumber=25039>.
[ISO.13818-6.1995]国際標準化機構、「情報技術-動画および関連するオーディオ情報の一般的なコーディング-パート6：DSM-CCの拡張」、ISOドラフト標準13818-6：1998、1998年10月、< http://www.iso.org/iso/home/store/catalogue_tc/ catalogue_detail.htm？csnumber = 25039>。
[ISO.8601.2000] International Organization for Standardization, "Data elements and interchange formats - Information interchange - Representation of dates and times", ISO/IEC Standard 8601, December 2000.
[ISO.8601.2000]国際標準化機構、「データ要素と交換形式-情報交換-日付と時刻の表現」、ISO / IEC標準8601、2000年12月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<http://www.rfc-editor.org/info/rfc791>。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <http://www.rfc-editor.org/info/rfc1123>.
[RFC1123] Braden、R。、編、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、DOI 10.17487 / RFC1123、1989年10月、<http://www.rfc-editor.org/info / rfc1123>。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, DOI 10.17487/RFC2068, January 1997, <http://www.rfc-editor.org/info/rfc2068>.
[RFC2068] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」、RFC 2068、DOI 10.17487 / RFC2068、January 1997、<http://www.rfc-editor.org/info/rfc2068>。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, DOI 10.17487/RFC2326, April 1998, <http://www.rfc-editor.org/info/rfc2326>.
[RFC2326] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「Real Time Streaming Protocol（RTSP）」、RFC 2326、DOI 10.17487 / RFC2326、1998年4月、<http：//www.rfc-editor。 org / info / rfc2326>。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, DOI 10.17487/RFC2663, August 1999, <http://www.rfc-editor.org/info/rfc2663>.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、DOI 10.17487 / RFC2663、1999年8月、<http://www.rfc-editor.org/info / rfc2663>。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <http://www.rfc-editor.org/info/rfc2974>.
[RFC2974] Handley、M.、Perkins、C。、およびE. Whelan、「Session Announcement Protocol」、RFC 2974、DOI 10.17487 / RFC2974、2000年10月、<http://www.rfc-editor.org/info/ rfc2974>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<http://www.rfc-editor.org / info / rfc3264>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <http://www.rfc-editor.org/info/rfc3339>.
[RFC3339]クライン、G、およびC.ニューマン、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<http://www.rfc-editor.org/info/rfc3339 >。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, <http://www.rfc-editor.org/info/rfc4145>.
[RFC4145] Yon、D。、およびG. Camarillo、「セッション記述プロトコル（SDP）におけるTCPベースのメディアトランスポート」、RFC 4145、DOI 10.17487 / RFC4145、2005年9月、<http：//www.rfc-editor。 org / info / rfc4145>。
[RFC4567] Arkko, J., Lindholm, F., Naslund, M., Norrman, K., and E. Carrara, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, DOI 10.17487/RFC4567, July 2006, <http://www.rfc-editor.org/info/rfc4567>.
[RFC4567] Arkko、J.、Lindholm、F.、Naslund、M.、Norrman、K.、and E. Carrara、 "Key Management Extensions for Session Description Protocol（SDP）and Real Time Streaming Protocol（RTSP）"、RFC 4567、DOI 10.17487 / RFC4567、2006年7月、<http://www.rfc-editor.org/info/rfc4567>。
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. Hakenberg, "RTP Retransmission Payload Format", RFC 4588, DOI 10.17487/RFC4588, July 2006, <http://www.rfc-editor.org/info/rfc4588>.
[RFC4588]レイ、J。、レオン、D。、宮崎、A。、ヴァルサ、V。、およびR.ハケンバーグ、「RTP Retransmission Payload Format」、RFC 4588、DOI 10.17487 / RFC4588、2006年7月、<http：/ /www.rfc-editor.org/info/rfc4588>。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, <http://www.rfc-editor.org/info/rfc4855>.
[RFC4855] Casner、S。、「RTP Payload Formatsのメディアタイプ登録」、RFC 4855、DOI 10.17487 / RFC4855、2007年2月、<http://www.rfc-editor.org/info/rfc4855>。
[RFC4856] Casner, S., "Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences", RFC 4856, DOI 10.17487/RFC4856, February 2007, <http://www.rfc-editor.org/info/rfc4856>.
[RFC4856] Casner、S。、「オーディオおよびビデオ会議のRTPプロファイルでのペイロード形式のメディアタイプ登録」、RFC 4856、DOI 10.17487 / RFC4856、2007年2月、<http://www.rfc-editor.org/ info / rfc4856>。
[RFC5104] Wenger, S., Chandra, U., Westerlund, M., and B. Burman, "Codec Control Messages in the RTP Audio-Visual Profile with Feedback (AVPF)", RFC 5104, DOI 10.17487/RFC5104, February 2008, <http://www.rfc-editor.org/info/rfc5104>.
[RFC5104] Wenger、S.、Chandra、U.、Westerlund、M。、およびB. Burman、「フィードバック付きのRTPオーディオビジュアルプロファイルのコーデック制御メッセージ（AVPF）」、RFC 5104、DOI 10.17487 / RFC5104、2月2008、<http://www.rfc-editor.org/info/rfc5104>。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, DOI 10.17487/RFC5245, April 2010, <http://www.rfc-editor.org/info/rfc5245>.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、DOI 10.17487 / RFC5245、2010年4月、<http：// www .rfc-editor.org / info / rfc5245>。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, DOI 10.17487/RFC5389, October 2008, <http://www.rfc-editor.org/info/rfc5389>.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、DOI 10.17487 / RFC5389、2008年10月、<http：// www.rfc-editor.org/info/rfc5389>。
[RFC5583] Schierl, T. and S. Wenger, "Signaling Media Decoding Dependency in the Session Description Protocol (SDP)", RFC 5583, DOI 10.17487/RFC5583, July 2009, <http://www.rfc-editor.org/info/rfc5583>.
[RFC5583] Schierl、T。およびS. Wenger、「Signaling Media Decoding Dependency in the Session Description Protocol（SDP）」、RFC 5583、DOI 10.17487 / RFC5583、2009年7月、<http://www.rfc-editor.org / info / rfc5583>。
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, <http://www.rfc-editor.org/info/rfc5905>.
[RFC5905] Mills、D.、Martin、J.、Ed。、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、DOI 10.17487 / RFC5905、2010年6月、 <http://www.rfc-editor.org/info/rfc5905>。
[RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, "Computing TCP's Retransmission Timer", RFC 6298, DOI 10.17487/RFC6298, June 2011, <http://www.rfc-editor.org/info/rfc6298>.
[RFC6298] Paxson、V.、Allman、M.、Chu、J。、およびM. Sargent、「Computing TCP's Retransmission Timer」、RFC 6298、DOI 10.17487 / RFC6298、2011年6月、<http：//www.rfc- editor.org/info/rfc6298>。
[Stevens98] Stevens, W., Fenner, B., and A. Rudoff, "Unix Networking Programming, Volume 1: The Sockets Networking API (3rd Edition)", 1998.
[Stevens98] Stevens、W.、Fenner、B.、and A. Rudoff、 "Unix Networking Programming、Volume 1：The Sockets Networking API（3rd Edition）"、1998。
This section contains several different examples trying to illustrate possible ways of using RTSP. The examples can also help with the understanding of how functions of RTSP work. However, remember that these are examples and the normative and syntax descriptions in the other sections take precedence. Please also note that many of the examples have been broken into several lines, where following lines start with whitespace as allowed by the syntax.
このセクションには、RTSPの使用方法を示すためのいくつかの異なる例が含まれています。これらの例は、RTSPの機能がどのように機能するかを理解するのにも役立ちます。ただし、これらは例であり、他のセクションの規範と構文の説明が優先されることに注意してください。また、例の多くはいくつかの行に分割されていることに注意してください。次の行は、構文で許可されている空白で始まります。
This is an example of media-on-demand streaming of media stored in a container file. For the purposes of this example, a container file is a storage entity in which multiple continuous media types pertaining to the same end-user presentation are present. In effect, the container file represents an RTSP presentation, with each of its components being RTSP-controlled media streams. Container files are a widely used means to store such presentations. While the components are transported as independent streams, it is desirable to maintain a common context for those streams at the server end.
これは、コンテナファイルに格納されているメディアのオンデマンドストリーミングの例です。この例では、コンテナファイルは、同じエンドユーザープレゼンテーションに関連する複数の連続メディアタイプが存在するストレージエンティティです。実際には、コンテナファイルはRTSPプレゼンテーションを表し、その各コンポーネントはRTSP制御のメディアストリームです。コンテナファイルは、そのようなプレゼンテーションを保存するために広く使用されている手段です。コンポーネントは独立したストリームとして転送されますが、これらのストリームの共通のコンテキストをサーバー側で維持することが望まれます。
This enables the server to keep a single storage handle open easily. It also allows treating all the streams equally in case of any prioritization of streams by the server.
これにより、サーバーは単一のストレージハンドルを簡単に開いたままにできます。また、サーバーによるストリームの優先順位付けの場合に、すべてのストリームを同等に処理することもできます。
It is also possible that the presentation author may wish to prevent selective retrieval of the streams by the client in order to preserve the artistic effect of the combined media presentation. Similarly, in such a tightly bound presentation, it is desirable to be able to control all the streams via a single control message using an aggregate URI.
プレゼンテーションの作成者が、結合されたメディアプレゼンテーションの芸術的効果を維持するために、クライアントによるストリームの選択的な取得を防止することを希望する場合もあります。同様に、そのような緊密にバインドされたプレゼンテーションでは、集約URIを使用して単一の制御メッセージを介してすべてのストリームを制御できることが望ましい。
The following is an example of using a single RTSP session to control multiple streams. It also illustrates the use of aggregate URIs. In a container file, it is also desirable not to write any URI parts that are not kept when the container is distributed, like the host and most of the path element. Therefore, this example also uses the "*" and relative URI in the delivered SDP.
以下は、単一のRTSPセッションを使用して複数のストリームを制御する例です。また、集約URIの使用法も示しています。コンテナーファイルでは、ホストやほとんどのパス要素のように、コンテナーの配布時に保持されないURI部分を記述しないことも望ましいです。したがって、この例でも、配信されたSDPで「*」と相対URIを使用しています。
Also, this presentation description (SDP) is not cacheable, as the Expires header is set to an equal value with date indicating immediate expiration of its validity.
また、このプレゼンテーションの説明（SDP）はキャッシュできません。Expiresヘッダーが同じ値に設定されており、日付の有効期限がすぐに切れることを示しているためです。
Client C requests a presentation from media server M. The movie is stored in a container file. The client has obtained an RTSP URI to the container file.
クライアントCがメディアサーバーMにプレゼンテーションを要求します。映画はコンテナファイルに保存されます。クライアントはコンテナファイルへのRTSP URIを取得しました。
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:32 +0000
Content-Type: application/sdp
Content-Length: 271
Content-Base: rtsp://example.com/twister.3gp/
Expires: Fri, 20 Dec 2013 12:20:32 +0000
v=0
o=- 2890844256 2890842807 IN IP4 198.51.100.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
c=IN IP4 0.0.0.0
a=control: *
a=range:npt=00:00:00-00:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
m=video 0 RTP/AVP 26
a=control: trackID=4
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: npt, smpte, clock
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast; ssrc=93CB001E;
dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="198.51.100.5:9000"/"198.51.100.5:9001"
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:20:33 +0000
Date: Fri, 20 Dec 2013 10:20:33 +0000
Accept-Ranges: npt
Media-Properties: Random-Access=0.02, Immutable, Unlimited
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Session: OccldOFFq23KwjYpAnBbUr
Accept-Ranges: npt, smpte, clock
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast; ssrc=A813FC13;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003";
src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:20:33 +0000
Date: Fri, 20 Dec 2013 10:20:33 +0000
Accept-Range: NPT
Media-Properties: Random-Access=0.8, Immutable, Unlimited
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=30-
Seek-Style: RAP
Session: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:34 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30-634.10
Seek-Style: RAP
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889
C->M: PAUSE rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 5
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
# Pause happens 0.87 seconds after starting to play M->C: RTSP/2.0 200 OK
CSeq: 5
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:35 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30.87-634.10
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 6
User-Agent: PhonyClient/1.2
Range: npt=30.87-634.10
Seek-Style: Next
Session: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK
CSeq: 6
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:22:13 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30.87-634.10
Seek-Style: Next
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12555;rtptime=6330012,
url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=55021;rtptime=3132889
C->M: TEARDOWN rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 7
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK
CSeq: 7
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:31:53 +0000
This example is basically the example above (Appendix A.1), but now utilizing pipelining to speed up the setup. It requires only two round-trip times until the media starts flowing. First of all, the session description is retrieved to determine what media resources need to be set up. In the second step, one sends the necessary SETUP requests and the PLAY request to initiate media delivery.
この例は基本的に上記の例（付録A.1）ですが、パイプラインを利用してセットアップを高速化しています。メディアが流れ始めるまでに必要な往復時間は2回だけです。まず、セッションの説明を取得して、セットアップが必要なメディアリソースを決定します。 2番目のステップでは、メディア配信を開始するために必要なSETUP要求とPLAY要求を送信します。
Client C requests a presentation from media server M. The movie is stored in a container file. The client has obtained an RTSP URI to the container file.
クライアントCがメディアサーバーMにプレゼンテーションを要求します。映画はコンテナファイルに保存されます。クライアントはコンテナファイルへのRTSP URIを取得しました。
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:32 +0000
Content-Type: application/sdp
Content-Length: 271
Content-Base: rtsp://example.com/twister.3gp/
Expires: Fri, 20 Dec 2013 12:20:32 +0000
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
c=IN IP4 0.0.0.0
a=control: *
a=range:npt=00:00:00-00:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
m=video 0 RTP/AVP 26
a=control: trackID=4
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8000"/":8001"
Accept-Ranges: npt, smpte, clock
Pipelined-Requests: 7654
C->M: SETUP rtsp://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP;unicast;dest_addr=":8002"/":8003"
Accept-Ranges: npt, smpte, clock
Pipelined-Requests: 7654
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=0-
Seek-Style: RAP
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;
dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="198.51.100.5:9000"/"198.51.100.5:9001";
ssrc=93CB001E
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:20:32 +0000
Date: Fri, 20 Dec 2013 10:20:32 +0000
Accept-Ranges: npt
Pipelined-Requests: 7654
Media-Properties: Random-Access=0.2, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/AVP;unicast;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003;
src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
ssrc=A813FC13
Session: OccldOFFq23KwjYpAnBbUr
Expires: Sat, 21 Dec 2013 10:20:32 +0000
Date: Fri, 20 Dec 2013 10:20:32 +0000
Accept-Range: NPT
Pipelined-Requests: 7654
Media-Properties: Random-Access=0.8, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:20:32 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=0-623.10
Seek-Style: RAP
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889
Pipelined-Requests: 7654
This example is basically the above example (Appendix A.2), but now including establishment of SRTP crypto contexts to get a secured media delivery. First of all, the client attempts to fetch this insecurely, but the server redirects to a URI indicating a requirement on using a secure connection for the RTSP messages. The client establishes a TCP/TLS connection, and the session description is retrieved to determine what media resources need to be set up. In the this session description, secure media (SRTP) is indicated. In the next step, the client sends the necessary SETUP requests including MIKEY messages. This is pipelined with a PLAY request to initiate media delivery.
この例は基本的に上記の例（付録A.2）ですが、安全なメディア配信を取得するためのSRTP暗号コンテキストの確立が含まれています。最初に、クライアントはこれを安全にフェッチしようとしますが、サーバーは、RTSPメッセージに安全な接続を使用する必要があることを示すURIにリダイレクトします。クライアントはTCP / TLS接続を確立し、セッションの説明を取得して、セットアップが必要なメディアリソースを決定します。このセッションの説明では、セキュアメディア（SRTP）が示されています。次のステップで、クライアントはMIKEYメッセージを含む必要なSETUP要求を送信します。これは、メディア配信を開始するPLAYリクエストでパイプライン処理されます。
Client C requests a presentation from media server M. The movie is stored in a container file. The client has obtained an RTSP URI to the container file.
クライアントCがメディアサーバーMにプレゼンテーションを要求します。映画はコンテナファイルに保存されます。クライアントはコンテナファイルへのRTSP URIを取得しました。
Note: The MIKEY messages below are not valid MIKEY messages and are Base64-encoded random data to represent where the MIKEY messages would go.
注：以下のMIKEYメッセージは有効なMIKEYメッセージではなく、MIKEYメッセージの送信先を表すBase64エンコードのランダムデータです。
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 301 Moved Permanently
CSeq: 1
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:25:32 +0000
Location: rtsps://example.com/twister.3gp
C->M: Establish TCP/TLS connection and verify server's certificate that represents example.com. Used for all below RTSP messages.
C-> M：TCP / TLS接続を確立し、example.comを表すサーバーの証明書を確認します。以下のすべてのRTSPメッセージに使用されます。
C->M: DESCRIBE rtsps://example.com/twister.3gp RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:25:33 +0000
Content-Type: application/sdp
Content-Length: 271
Content-Base: rtsps://example.com/twister.3gp/
Expires: Fri, 20 Dec 2013 12:25:33 +0000
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.5
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
c=IN IP4 0.0.0.0
a=control: *
a=range:npt=00:00:00-00:10:34.10
t=0 0
m=audio 0 RTP/SAVP 0
a=control: trackID=1
m=video 0 RTP/SAVP 26
a=control: trackID=4
C->M: SETUP rtsps://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/SAVP;unicast;dest_addr=":8000"/":8001";
MIKEY=VGhpcyBpcyB0aGUgZmlyc3Qgc3RyZWFtcyBNSUtFWSBtZXNzYWdl
Accept-Ranges: npt, smpte, clock
Pipelined-Requests: 7654
C->M: SETUP rtsps://example.com/twister.3gp/trackID=4 RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/SAVP;unicast;dest_addr=":8002"/":8003";
MIKEY=TUlLRVkgZm9yIHN0cmVhbSB0d2lzdGVyLjNncC90cmFja0lEPTQ=
Accept-Ranges: npt, smpte, clock
Pipelined-Requests: 7654
C->M: PLAY rtsps://example.com/twister.3gp/ RTSP/2.0
CSeq: 5
User-Agent: PhonyClient/1.2
Range: npt=0-
Seek-Style: RAP
Pipelined-Requests: 7654
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Transport: RTP/SAVP;unicast;
dest_addr="192.0.2.53:8000"/"192.0.2.53:8001";
src_addr="198.51.100.5:9000"/"198.51.100.5:9001";
ssrc=93CB001E;
MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD0x
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:25:34 +0000
Date: Fri, 20 Dec 2013 10:25:34 +0000
Accept-Ranges: npt
Pipelined-Requests: 7654
Media-Properties: Random-Access=0.2, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Transport: RTP/SAVP;unicast;
dest_addr="192.0.2.53:8002"/"192.0.2.53:8003;
src_addr="198.51.100.5:9002"/"198.51.100.5:9003";
ssrc=A813FC13;
MIKEY=TUlLRVkgUmVzcG9uc2UgdHdpc3Rlci4zZ3AvdHJhY2tJRD00
Session: OccldOFFq23KwjYpAnBbUr
Expires: Fri, 20 Dec 2013 12:25:34 +0000
Date: Fri, 20 Dec 2013 10:25:34 +0000
Accept-Range: NPT
Pipelined-Requests: 7654
Media-Properties: Random-Access=0.8, Immutable, Unlimited
M->C: RTSP/2.0 200 OK
CSeq: 5
Server: PhonyServer/1.0
Date: Fri, 20 Dec 2013 10:25:34 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=0-623.10
Seek-Style: RAP
RTP-Info: url="rtsps://example.com/twister.3gp/trackID=4"
ssrc=0D12F123:seq=12345;rtptime=3450012,
url="rtsps://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889;
Pipelined-Requests: 7654
An alternative example of media on demand with a few more tweaks is the following. Client C requests a movie distributed from two different media servers A (audio.example.com) and V (video.example.com). The media description is stored on a web server W. The media description contains descriptions of the presentation and all its streams, including the codecs that are available and the protocol stack.
いくつかの微調整を加えたオンデマンドメディアの代替例は次のとおりです。クライアントCは、2つの異なるメディアサーバーA（audio.example.com）とV（video.example.com）から配信された映画をリクエストします。メディアの説明は、WebサーバーWに格納されます。メディアの説明には、利用可能なコーデックやプロトコルスタックなど、プレゼンテーションとそのすべてのストリームの説明が含まれます。
In this example, the client is only interested in the last part of the movie.
この例では、クライアントは映画の最後の部分だけに関心があります。
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
W->C: HTTP/1.1 200 OK
Date: Wed, 23 Jan 2013 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 278
Expires: Thu, 24 Jan 2013 15:35:06 GMT
v=0
o=- 2890844526 2890842807 IN IP4 198.51.100.5
s=RTSP Session
e=adm@example.com
c=IN IP4 0.0.0.0
a=range:npt=00:00:00-01:49:34
t=0 0
m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;dest_addr=":3056"/":3057",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, smpte, clock
A->C: RTSP/2.0 200 OK
CSeq: 1
Session: OccldOFFq23KwjYpAnBbUr
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
src_addr="198.51.100.5:5000"/"198.51.100.5:5001"
Date: Wed, 23 Jan 2013 15:35:12 +0000
Server: PhonyServer/1.0
Expires: Thu, 24 Jan 2013 15:35:12 +0000
Cache-Control: public
Accept-Ranges: npt, smpte
Media-Properties: Random-Access=0.02, Immutable, Unlimited
C->V: SETUP rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3058"/"192.0.2.53:3059",
RTP/AVP/TCP;unicast;interleaved=0-1
Accept-Ranges: npt, smpte, clock
V->C: RTSP/2.0 200 OK
CSeq: 1
Session: P5it3pMo6xHkjUcDrNkBjf
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3058"/"192.0.2.53:3059";
src_addr="198.51.100.5:5002"/"198.51.100.5:5003"
Date: Wed, 23 Jan 2013 15:35:12 +0000
Server: PhonyServer/1.0
Cache-Control: public
Expires: Thu, 24 Jan 2013 15:35:12 +0000
Accept-Ranges: npt, smpte
Media-Properties: Random-Access=1.2, Immutable, Unlimited
C->V: PLAY rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: P5it3pMo6xHkjUcDrNkBjf
Range: smpte=0:10:00-
V->C: RTSP/2.0 200 OK
CSeq: 2
Session: P5it3pMo6xHkjUcDrNkBjf
Range: smpte=0:10:00-1:49:23
Seek-Style: First-Prior
RTP-Info: url="rtsp://video.example.com/twister/video"
ssrc=A17E189D:seq=12312232;rtptime=78712811
Server: PhonyServer/2.0
Date: Wed, 23 Jan 2013 15:35:13 +0000
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
Range: smpte=0:10:00-
A->C: RTSP/2.0 200 OK
CSeq: 2
Session: OccldOFFq23KwjYpAnBbUr
Range: smpte=0:10:00-1:49:23
Seek-Style: First-Prior
RTP-Info: url="rtsp://audio.example.com/twister/audio.en"
ssrc=3D124F01:seq=876655;rtptime=1032181
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:35:13 +0000
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: OccldOFFq23KwjYpAnBbUr
A->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: P5it3pMo6xHkjUcDrNkBjf
V->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/2.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Even though the audio and video track are on two different servers that may start at slightly different times and may drift with respect to each other over time, the client can perform initial synchronization of the two media using RTP-Info and Range received in the PLAY responses. If the two servers are time synchronized, the RTCP packets can also be used to maintain synchronization.
オーディオトラックとビデオトラックが2つの異なるサーバー上にあり、わずかに異なる時間に開始し、時間の経過とともに互いにドリフトする可能性がありますが、クライアントは、PLAYで受信したRTP情報と範囲を使用して2つのメディアの初期同期を実行できます反応。 2つのサーバーが時間同期されている場合、RTCPパケットを使用して同期を維持することもできます。
Some RTSP servers may treat all files as though they are "container
files", yet other servers may not support such a concept. Because of
this, clients needs to use the rules set forth in the session
description for Request-URIs rather than assuming that a consistent
URI may always be used throughout. Below is an example of how a
multi-stream server might expect a single-stream file to be served: C->S: DESCRIBE rtsp://foo.example.com/test.wav RTSP/2.0
Accept: application/x-rtsp-mh, application/sdp
CSeq: 1
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 1
Content-base: rtsp://foo.example.com/test.wav/
Content-type: application/sdp
Content-length: 163
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Expires: Thu, 24 Jan 2013 15:36:52 +0000
v=0
o=- 872653257 872653257 IN IP4 192.0.2.5
s=mu-law wave file
i=audio test
c=IN IP4 0.0.0.0
t=0 0
a=control: *
m=audio 0 RTP/AVP 0
a=control:streamid=0
C->S: SETUP rtsp://foo.example.com/test.wav/streamid=0 RTSP/2.0
Transport: RTP/AVP/UDP;unicast;
dest_addr=":6970"/":6971";mode="PLAY"
CSeq: 2
User-Agent: PhonyClient/1.2
Accept-Ranges: npt, smpte, clock
S->C: RTSP/2.0 200 OK
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:6970"/"192.0.2.53:6971";
src_addr="198.51.100.5:6970"/"198.51.100.5:6971";
mode="PLAY";ssrc=EAB98712
CSeq: 2
Session: NYkqQYKk0bb12BY3goyoyO
Expires: Thu, 24 Jan 2013 15:36:52 +0000
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Accept-Ranges: npt
Media-Properties: Random-Access=0.5, Immutable, Unlimited
C->S: PLAY rtsp://foo.example.com/test.wav/ RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: NYkqQYKk0bb12BY3goyoyO
S->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Session: NYkqQYKk0bb12BY3goyoyO
Range: npt=0-600
Seek-Style: RAP
RTP-Info: url="rtsp://foo.example.com/test.wav/streamid=0"
ssrc=0D12F123:seq=981888;rtptime=3781123
Note the different URI in the SETUP command and then the switch back to the aggregate URI in the PLAY command. This makes complete sense when there are multiple streams with aggregate control, but it is less than intuitive in the special case where the number of streams is one. However, the server has declared the aggregated control URI in the SDP; therefore, this is legal.
SETUPコマンドの別のURIに注意してから、PLAYコマンドの集約URIに切り替えます。これは、集約制御を使用する複数のストリームがある場合に完全に意味がありますが、ストリームの数が1つである特殊なケースでは直感的とは言えません。ただし、サーバーはSDPで集約コントロールURIを宣言しています。したがって、これは合法です。
In this case, it is also required that servers accept implementations that use the non-aggregated interpretation and use the individual media URI, like this:
この場合、次のように、サーバーが非集約解釈を使用し、個々のメディアURIを使用する実装を受け入れることも必要です。
C->S: PLAY rtsp://example.com/test.wav/streamid=0 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Session: NYkqQYKk0bb12BY3goyoyO
The media server M chooses the multicast address and port. Here, it is assumed that the web server only contains a pointer to the full description, while the media server M maintains the full description.
メディアサーバーMは、マルチキャストアドレスとポートを選択します。ここで、メディアサーバーＭが完全な記述を維持する一方で、ウェブサーバーは完全な記述へのポインタのみを含むと仮定される。
C->W: GET /sessions.html HTTP/1.1
Host: www.example.com
W->C: HTTP/1.1 200 OK
Content-Type: text/html
<html>
...
<a href "rtsp://live.example.com/concert/audio">
Streamed Live Music performance </a>
...
</html>
C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 1
Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: 183
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Supported: play.basic
v=0
o=- 2890844526 2890842807 IN IP4 192.0.2.5
s=RTSP Session
t=0 0
m=audio 3456 RTP/AVP 0
c=IN IP4 233.252.0.54/16
a=control: rtsp://live.example.com/concert/audio
a=range:npt=0-
C->M: SETUP rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 2
Transport: RTP/AVP;multicast;
dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16
Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Transport: RTP/AVP;multicast;
dest_addr="233.252.0.54:3456"/"233.252.0.54:3457";ttl=16
;ssrc=4D12AB92/0DF876A3
Session: qHj4jidpmF6zy9v9tNbtxr
Accept-Ranges: npt, clock
Media-Properties: No-Seeking, Time-Progressing, Time-Duration=0
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/2.0
CSeq: 3
Session: qHj4jidpmF6zy9v9tNbtxr
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 3
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Session: qHj4jidpmF6zy9v9tNbtxr
Seek-Style: Next
Range:npt=1256-
RTP-Info: url="rtsp://live.example.com/concert/audio"
ssrc=0D12F123:seq=1473; rtptime=80000
This example illustrates how the client and server determine their capability to support a special feature, in this case, "play.scale". The server, through the client request and the included Supported header, learns that the client supports RTSP 2.0 and also supports the playback time scaling feature of RTSP. The server's response contains the following feature-related information to the client; it supports the basic media delivery functions (play.basic), the extended functionality of time scaling of content (play.scale), and one "example.com" proprietary feature (com.example.flight). The client also learns the methods supported (Public header) by the server for the indicated resource.
この例は、クライアントとサーバーが特別な機能（この場合は "play.scale"）をサポートする機能をどのように決定するかを示しています。サーバーは、クライアント要求と含まれているSupportedヘッダーを介して、クライアントがRTSP 2.0をサポートし、RTSPの再生時間スケーリング機能もサポートしていることを学習します。サーバーの応答には、クライアントに対する次の機能関連情報が含まれています。基本的なメディア配信機能（play.basic）、コンテンツの時間スケーリングの拡張機能（play.scale）、および1つの「example.com」独自の機能（com.example.flight）をサポートしています。クライアントは、示されたリソースについてサーバーがサポートするメソッド（パブリックヘッダー）も学習します。
C->S: OPTIONS rtsp://media.example.com/movie/twister.3gp RTSP/2.0
CSeq: 1
Supported: play.basic, play.scale
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 1
Public:OPTIONS,SETUP,PLAY,PAUSE,TEARDOWN,DESCRIBE,GET_PARAMETER
Allow: OPTIONS, SETUP, PLAY, PAUSE, TEARDOWN, DESCRIBE
Server: PhonyServer/2.0
Supported: play.basic, play.scale, com.example.flight
When the client sends its SETUP request, it tells the server that it requires support of the play.scale feature for this session by including the Require header.
クライアントがSETUP要求を送信すると、Requireヘッダーを含めることにより、このセッションのplay.scale機能のサポートが必要であることをサーバーに通知します。
C->S: SETUP rtsp://media.example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 3
User-Agent: PhonyClient/1.2
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057",
RTP/AVP/TCP;unicast;interleaved=0-1
Require: play.scale
Accept-Ranges: npt, smpte, clock
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 3
Session: OccldOFFq23KwjYpAnBbUr
Transport: RTP/AVP/UDP;unicast;
dest_addr="192.0.2.53:3056"/"192.0.2.53:3057";
src_addr="198.51.100.5:5000"/"198.51.100.5:5001"
Server: PhonyServer/2.0
Accept-Ranges: npt, smpte
Media-Properties: Random-Access=0.8, Immutable, Unlimited
The RTSP session state machine describes the behavior of the protocol from RTSP session initialization through RTSP session termination. It is probably easiest to think of this as the server's state and then view the client as needing to track what it believes the server's state will be based on sent or received RTSP messages. Thus, in most cases, the state tables below can be read as: if the client does X, and assuming it fulfills any prerequisite(s), the (server) state will move to the new state and the indicated response will returned. However, there are also server-to-client notifications or requests, where the action describes what notification or request will occur, its requisites, what new state will result after the server has received the response, as well as describing the client's response to the action.
RTSPセッションステートマシンは、RTSPセッションの初期化からRTSPセッションの終了までのプロトコルの動作を記述します。これをサーバーの状態と見なし、クライアントがサーバーの状態が送信または受信したRTSPメッセージに基づいていると考えるものを追跡する必要があると見なすのがおそらく最も簡単です。したがって、ほとんどの場合、以下の状態テーブルは次のように読み取ることができます。クライアントがXを実行し、それが前提条件を満たしていると仮定すると、（サーバー）状態は新しい状態に移行し、示された応答が返されます。ただし、サーバーからクライアントへの通知または要求もあり、アクションは通知または要求の発生内容、その必要条件、サーバーが応答を受信した後に発生する新しい状態、およびクライアントへのクライアントの応答を記述します。アクション。
The State machine is defined on a per-session basis, which is uniquely identified by the RTSP session identifier. The session may contain one or more media streams depending on state. If a single media stream is part of the session, it is in non-aggregated control. If two or more are part of the session, it is in aggregated control.
ステートマシンはセッションごとに定義され、RTSPセッション識別子によって一意に識別されます。セッションには、状態に応じて1つ以上のメディアストリームが含まれる場合があります。単一のメディアストリームがセッションの一部である場合、それは集約されない制御下にあります。 2つ以上がセッションの一部である場合は、集約された制御下にあります。
The below state machine is an informative description of the protocol's behavior. In case of ambiguity with the earlier parts of this specification, the description in the earlier parts take precedence.
以下のステートマシンは、プロトコルの動作を説明するものです。この仕様の以前の部分があいまいな場合は、以前の部分の説明が優先されます。
The state machine contains three states, described below. For each state, there exists a table that shows which requests and events are allowed and whether they will result in a state change.
状態マシンには、以下に説明する3つの状態が含まれています。状態ごとに、どの要求とイベントが許可され、それらが状態の変化をもたらすかどうかを示すテーブルがあります。
Init: Initial state, no session exists.
Init：初期状態。セッションは存在しません。
Ready: Session is ready to start playing.
準備完了：セッションは再生を開始する準備ができています。
Play: Session is playing, i.e., sending media-stream data in the direction S->C.
再生：セッションは再生中です。つまり、メディアストリームデータをS-> Cの方向に送信しています。
This representation of the state machine needs more than its state to work. A small number of variables are also needed, and they are explained below.
状態マシンのこの表現は、動作するためにその状態以上のものを必要とします。少数の変数も必要です。以下で説明します。
NRM: The number of media streams that are part of this session.
NRM：このセッションの一部であるメディアストリームの数。
RP: Resume point, the point in the presentation time line at which a request to continue playing will resume from. A time format for the variable is not mandated.
RP：再開ポイント。再生を続行する要求が再開されるプレゼンテーションタイムラインのポイント。変数の時間形式は必須ではありません。
To make the state tables more compact, a number of abbreviations are used, which are explained below.
状態テーブルをよりコンパクトにするために、以下で説明するいくつかの省略形が使用されています。
IFI: IF Implemented.
IFI：IF実装済み。
md: Media PP: Pause Point, the point in the presentation timeline at which the presentation was paused.
md：メディアPP：一時停止ポイント。プレゼンテーションが一時停止されたプレゼンテーションタイムラインのポイント。
Prs: Presentation, the complete multimedia presentation.
Prs：プレゼンテーション、完全なマルチメディアプレゼンテーション。
RedP: Redirect Point, the point in the presentation timeline at which a REDIRECT was specified to occur.
RedP：リダイレクトポイントは、REDIRECTが発生するように指定されたプレゼンテーションタイムラインのポイントです。
SES: Session.
SES：セッション。
This section contains a table for each state. The table contains all the requests and events on which this state is allowed to act. The events that are method names are, unless noted, requests with the given method in the direction client to server (C->S). In some cases, there exists one or more requisites. The response column tells what type of response actions should be performed. Possible actions that are requested for an event include: response codes, e.g., 200, headers that need to be included in the response, setting of state variables, or settings of other session-related parameters. The new state column tells which state the state machine changes to.
このセクションには、各州の表が含まれています。テーブルには、この状態が動作できるすべてのリクエストとイベントが含まれています。メソッド名であるイベントは、特に明記しない限り、クライアントからサーバーへの方向（C-> S）で指定されたメソッドを使用した要求です。場合によっては、1つ以上の必要条件が存在します。応答列は、実行する必要がある応答アクションのタイプを示します。イベントに対して要求される可能性のあるアクションには、応答コード（200など）、応答に含める必要があるヘッダー、状態変数の設定、または他のセッション関連パラメーターの設定が含まれます。新しい状態列は、状態マシンがどの状態に変化するかを示します。
The response to a valid request meeting the requisites is normally a 2xx (SUCCESS) unless otherwise noted in the response column. The exceptions need to be given a response according to the response column. If the request does not meet the requisite, is erroneous, or some other type of error occurs, the appropriate response code is to be sent. If the response code is a 4xx, the session state is unchanged. A response code of 3rr will result in that the session being ended and its state changed to Init. A response code of 304 results in no state change. However, there are restrictions to when a 3rr response may be used. A 5xx response does not result in any change of the session state, except if the error is not possible to recover from. An unrecoverable error results in the ending of the session. In the general case, if it can't be determined whether or not it was an unrecoverable error, the client will be required to test. In the case that the next request after a 5xx is responded to with a 454 (Session Not Found), the client knows that the session has ended. For any request message that cannot be responded to within the time defined in Section 10.4, a 100 response must be sent.
要件を満たしている有効な要求への応答は、応答列に特に明記されていない限り、通常2xx（成功）です。例外には、応答列に従って応答を与える必要があります。要求が要件を満たしていない場合、エラーがある場合、またはその他のタイプのエラーが発生した場合は、適切な応答コードが送信されます。応答コードが4xxの場合、セッション状態は変更されません。応答コードが3rrの場合、セッションが終了し、その状態がInitに変わります。応答コード304の場合、状態は変化しません。ただし、3rr応答を使用できる場合には制限があります。 5xx応答は、エラーが回復できない場合を除いて、セッション状態の変更にはなりません。回復不能なエラーが発生すると、セッションが終了します。一般的なケースでは、それが回復不可能なエラーであるかどうかを判断できない場合、クライアントはテストする必要があります。 5xxの後の次の要求が454（セッションが見つかりません）で応答された場合、クライアントはセッションが終了したことを認識しています。セクション10.4で定義された時間内に応答できない要求メッセージの場合、100応答を送信する必要があります。
The server will time out the session after the period of time specified in the SETUP response, if no activity from the client is detected. Therefore, there exists a timeout event for all states except Init.
クライアントからのアクティビティが検出されない場合、サーバーはSETUP応答で指定された期間が経過するとセッションをタイムアウトします。したがって、Initを除くすべての状態のタイムアウトイベントが存在します。
In the case that NRM = 1, the presentation URI is equal to the media URI or a specified presentation URI. For NRM > 1, the presentation URI needs to be other than any of the media that are part of the session. This applies to all states.
NRM = 1の場合、プレゼンテーションURIはメディアURIまたは指定されたプレゼンテーションURIと同じです。 NRM> 1の場合、プレゼンテーションURIは、セッションの一部であるメディア以外のものである必要があります。これはすべての州に適用されます。
+---------------+-----------------+---------------------------------+
| Event | Prerequisite | Response |
+---------------+-----------------+---------------------------------+
| DESCRIBE | Needs REDIRECT | 3rr, Redirect |
| | | |
| DESCRIBE | | 200, Session description |
| | | |
| OPTIONS | Session ID | 200, Reset session timeout |
| | | timer |
| | | |
| OPTIONS | | 200 |
| | | |
| SET_PARAMETER | Valid parameter | 200, change value of parameter |
| | | |
| GET_PARAMETER | Valid parameter | 200, return value of parameter |
+---------------+-----------------+---------------------------------+
Table 9: Non-State-Machine Changing Events
表9：非状態マシン変更イベント
The methods in Table 9 do not have any effect on the state machine or the state variables. However, some methods do change other session-related parameters, for example, SET_PARAMETER, which will set the parameter(s) specified in its body. Also, all of these methods that allow the Session header will also update the keep-alive timer for the session.
表9のメソッドは、ステートマシンまたは状態変数に影響を与えません。ただし、一部のメソッドは、本体で指定されたパラメーターを設定するSET_PARAMETERなど、他のセッション関連パラメーターを変更します。また、Sessionヘッダーを許可するこれらすべてのメソッドは、セッションのキープアライブタイマーも更新します。
+------------------+----------------+-----------+-------------------+
| Action | Requisite | New State | Response |
+------------------+----------------+-----------+-------------------+
| SETUP | | Ready | NRM=1, RP=0.0 |
| | | | |
| SETUP | Needs Redirect | Init | 3rr Redirect |
| | | | |
| S -> C: REDIRECT | No Session hdr | Init | Terminate all SES |
+------------------+----------------+-----------+-------------------+
Table 10: State: Init
表10：状態：Init
The initial state of the state machine (Table 10) can only be left by processing a correct SETUP request. As seen in the table, the two state variables are also set by a correct request. This table also shows that a correct SETUP can in some cases be redirected to another URI or server by a 3rr response.
ステートマシンの初期状態（表10）は、正しいSETUP要求を処理することによってのみ残すことができます。表に示されているように、2つの状態変数も正しい要求によって設定されます。この表は、正しいSETUPが3rr応答によって別のURIまたはサーバーにリダイレクトされる場合があることも示しています。
+-------------+------------------------+---------+------------------+
| Action | Requisite | New | Response |
| | | State | |
+-------------+------------------------+---------+------------------+
| SETUP | New URI | Ready | NRM +=1 |
| | | | |
| SETUP | URI Setup prior | Ready | Change transport |
| | | | param |
| | | | |
| TEARDOWN | Prs URI, | Init | No session hdr, |
| | | | NRM = 0 |
| | | | |
| TEARDOWN | md URI,NRM=1 | Init | No Session hdr, |
| | | | NRM = 0 |
| | | | |
| TEARDOWN | md URI,NRM>1 | Ready | Session hdr, NRM |
| | | | -= 1 |
| | | | |
| PLAY | Prs URI, No range | Play | Play from RP |
| | | | |
| PLAY | Prs URI, Range | Play | According to |
| | | | range |
| | | | |
| PLAY | md URI, NRM=1, Range | Play | According to |
| | | | range |
| | | | |
| PLAY | md URI, NRM=1 | Play | Play from RP |
| | | | |
| PAUSE | Prs URI | Ready | Return PP |
| | | | |
| SC:REDIRECT | Terminate-Reason | Ready | Set RedP |
| | | | |
| SC:REDIRECT | No Terminate-Reason | Init | Session is |
| | time parameter | | removed |
| | | | |
| Timeout | | Init | |
| | | | |
| RedP | | Init | TEARDOWN of |
| reached | | | session |
+-------------+------------------------+---------+------------------+
Table 11: State: Ready
表11：状態：準備完了
In the Ready state (Table 11), some of the actions depend on the number of media streams (NRM) in the session, i.e., aggregated or non-aggregated control. A SETUP request in the Ready state can either add one more media stream to the session or, if the media stream (same URI) already is part of the session, change the transport parameters. TEARDOWN depends on both the Request-URI and the number of media streams within the session. If the Request-URI is the presentation URI, the whole session is torn down. If a media URI is used in the TEARDOWN request and more than one media exists in the session, the session will remain and a session header is returned in the response. If only a single media stream remains in the session when performing a TEARDOWN with a media URI, the session is removed. The number of media streams remaining after tearing down a media stream determines the new state.
準備完了状態（表11）では、一部のアクションは、セッション内のメディアストリーム（NRM）の数、つまり集約されたコントロールまたは集約されていないコントロールに依存します。準備完了状態のSETUP要求は、セッションに1つ以上のメディアストリームを追加するか、メディアストリーム（同じURI）がすでにセッションの一部である場合は、トランスポートパラメータを変更することができます。 TEARDOWNは、Request-URIとセッション内のメディアストリームの数の両方に依存します。 Request-URIがプレゼンテーションURIの場合、セッション全体が破棄されます。 TEARDOWNリクエストでメディアURIが使用され、セッションに複数のメディアが存在する場合、セッションは残り、セッションヘッダーが応答で返されます。メディアURIを使用してTEARDOWNを実行したときに、セッションにメディアストリームが1つしか残っていない場合、セッションは削除されます。メディアストリームを破棄した後に残っているメディアストリームの数によって、新しい状態が決まります。
+----------------+-----------------------+--------+-----------------+
| Action | Requisite | New | Response |
| | | State | |
+----------------+-----------------------+--------+-----------------+
| PAUSE | Prs URI | Ready | Set RP to |
| | | | present point |
| | | | |
| End of media | All media | Play | Set RP = End of |
| | | | media |
| | | | |
| End of range | | Play | Set RP = End of |
| | | | range |
| | | | |
| PLAY | Prs URI, No range | Play | Play from |
| | | | present point |
| | | | |
| PLAY | Prs URI, Range | Play | According to |
| | | | range |
| | | | |
| SC:PLAY_NOTIFY | | Play | 200 |
| | | | |
| SETUP | New URI | Play | 455 |
| | | | |
| SETUP | md URI | Play | 455 |
| | | | |
| SETUP | md URI, IFI | Play | Change |
| | | | transport param.|
| | | | |
| TEARDOWN | Prs URI | Init | No session hdr |
| | | | |
| TEARDOWN | md URI,NRM=1 | Init | No Session hdr, |
| | | | NRM=0 |
| | | | |
| TEARDOWN | md URI | Play | 455 |
| | | | |
| SC:REDIRECT | Terminate Reason with | Play | Set RedP |
| | Time parameter | | |
| | | | |
| SC:REDIRECT | | Init | Session is |
| | | | removed |
| | | | |
| RedP reached | | Init | TEARDOWN of |
| | | | session |
| | | | |
| Timeout | | Init | Stop Media |
| | | | playout |
+----------------+-----------------------+--------+-----------------+
Table 12: State: Play
The Play state table (Table 12) contains a number of requests that need a presentation URI (labeled as Prs URI) to work on (i.e., the presentation URI has to be used as the Request-URI). This is due to the exclusion of non-aggregated stream control in sessions with more than one media stream.
Play状態テーブル（表12）には、プレゼンテーションURI（Prs URIとラベルが付けられている）が機能する必要があるいくつかの要求が含まれています（つまり、プレゼンテーションURIをRequest-URIとして使用する必要があります）。これは、複数のメディアストリームとのセッションで非集約ストリーム制御が除外されているためです。
To avoid inconsistencies between the client and server, automatic state transitions are avoided. This can be seen at, for example, an "End of media" event when all media has finished playing but the session still remains in Play state. An explicit PAUSE request needs to be sent to change the state to Ready. It may appear that there exist automatic transitions in "RedP reached" and "PP reached". However, they are requested and acknowledged before they take place. The time at which the transition will happen is known by looking at the Terminate-Reason header's time parameter and Range header, respectively. If the client sends a request close in time to these transitions, it needs to be prepared for receiving error messages, as the state may or may not have changed.
クライアントとサーバー間の不整合を回避するために、自動状態遷移は回避されます。これは、たとえば、すべてのメディアの再生が終了したが、セッションがまだ再生状態のままである「メディアの終了」イベントで確認できます。状態を準備完了に変更するには、明示的なPAUSE要求を送信する必要があります。 「RedPに達しました」と「PPに達しました」に自動遷移が存在するように見えるかもしれません。ただし、それらは発生する前に要求され、確認されます。遷移が発生する時間は、Terminate-Reasonヘッダーの時間パラメーターとRangeヘッダーをそれぞれ調べることでわかります。クライアントがこれらの遷移に間に合うように要求を送信する場合、状態が変化したかどうかにかかわらず、エラーメッセージを受信する準備をする必要があります。
This section defines how certain combinations of protocols, profiles, and lower transports are used. This includes the usage of the Transport header's source and destination address parameters: "src_addr" and "dest_addr".
このセクションでは、プロトコル、プロファイル、下位トランスポートの特定の組み合わせがどのように使用されるかを定義します。これには、トランスポートヘッダーの送信元と宛先のアドレスパラメーター「src_addr」と「dest_addr」の使用が含まれます。
This section defines the interaction of RTSP with respect to the RTP protocol [RFC3550]. It also defines any necessary media-transport signaling with regard to RTP.
このセクションはRTPプロトコル[RFC3550]に関してRTSPの相互作用を定義します。また、RTPに関して必要なメディア転送シグナリングも定義します。
The available RTP profiles and lower-layer transports are described below along with rules on signaling the available combinations.
使用可能なRTPプロファイルと下位層のトランスポートを、使用可能な組み合わせのシグナリングに関するルールと共に以下で説明します。
The usage of the "RTP Profile for Audio and Video Conferences with Minimal Control" [RFC3551] when using RTP for media transport over different lower-layer transport protocols is defined below in regard to RTSP.
さまざまな下位層のトランスポートプロトコルを介したメディアトランスポートにRTPを使用する場合の、「最小限の制御でのオーディオおよびビデオ会議のRTPプロファイル」[RFC3551]の使用法は、RTSPに関して以下で定義されています。
One such case is defined within this document: the use of embedded (interleaved) binary data as defined in Section 14. The usage of this method is indicated by including the "interleaved" parameter.
このようなケースの1つは、このドキュメントで定義されています。セクション14で定義されている埋め込み（インターリーブ）バイナリデータの使用です。このメソッドの使用法は、「インターリーブ」パラメーターを含めることで示されます。
When using embedded binary data, "src_addr" and "dest_addr" MUST NOT be used. This addressing and multiplexing is used as defined with use of channel numbers and the interleaved parameter.
埋め込みバイナリデータを使用する場合、「src_addr」および「dest_addr」を使用してはなりません（MUST NOT）。このアドレス指定と多重化は、チャネル番号とインターリーブパラメータを使用して定義されたとおりに使用されます。
This part describes the sending of RTP [RFC3550] over lower-transport-layer UDP [RFC768] according to the profile "RTP Profile for Audio and Video Conferences with Minimal Control" defined in [RFC3551]. Implementations of RTP/AVP/UDP MUST implement RTCP (Appendix C.1.6). This profile requires one or two unidirectional or bidirectional UDP flows per media stream. The first UDP flow is for RTP and the second is for RTCP. Multiplexing of RTP and RTCP (Appendix C.1.6.4) MAY be used, in which case, a single UDP flow is used for both parts. Embedding of RTP data with the RTSP messages, in accordance with Section 14, SHOULD NOT be performed when RTSP messages are transported over unreliable transport protocols, like UDP [RFC768].
この部分は、[RFC3551]で定義された「最小制御のオーディオおよびビデオ会議のRTPプロファイル」プロファイルに従って、下位トランスポート層UDP [RFC768]を介したRTP [RFC3550]の送信について説明します。 RTP / AVP / UDPの実装は、RTCPを実装する必要があります（付録C.1.6）。このプロファイルでは、メディアストリームごとに1つまたは2つの単方向または双方向のUDPフローが必要です。最初のUDPフローはRTP用で、2番目はRTCP用です。 RTPとRTCPの多重化（付録C.1.6.4）を使用できます。その場合、単一のUDPフローが両方の部分に使用されます。セクション14に従って、RTSPメッセージでのRTPデータの埋め込みは、RTSPメッセージがUDP [RFC768]のような信頼性の低いトランスポートプロトコルを介してトランスポートされる場合は実行すべきではありません。
The RTP/UDP and RTCP/UDP flows can be established using the Transport header's "src_addr" and "dest_addr" parameters.
RTP / UDPおよびRTCP / UDPフローは、トランスポートヘッダーの「src_addr」および「dest_addr」パラメーターを使用して確立できます。
In RTSP PLAY mode, the transmission of RTP packets from client to server is unspecified. The behavior in regard to such RTP packets MAY be defined in future.
RTSP PLAYモードでは、クライアントからサーバーへのRTPパケットの送信は指定されていません。そのようなRTPパケットに関する動作は将来定義されるかもしれません。
The "src_addr" and "dest_addr" parameters are used in the following way for media delivery and playback mode, i.e., Mode=PLAY:
「src_addr」および「dest_addr」パラメータは、メディア配信および再生モード、つまりMode = PLAYに対して次のように使用されます。
o The "src_addr" and "dest_addr" parameters MUST contain either 1 or 2 address specifications. Note that two address specifications MAY be provided even if RTP and RTCP multiplexing is negotiated.
o 「src_addr」および「dest_addr」パラメータには、1つまたは2つのアドレス指定を含める必要があります。 RTPとRTCPの多重化がネゴシエートされる場合でも、2つのアドレス指定が提供される場合があることに注意してください。
o Each address specification for RTP/AVP/UDP or RTP/AVP/TCP MUST contain either:
o RTP / AVP / UDPまたはRTP / AVP / TCPの各アドレス指定には、次のいずれかが含まれている必要があります。
* both an address and a port number, or
* アドレスとポート番号の両方、または
* a port number without an address.
* アドレスのないポート番号。
o The first address specification given in either of the parameters applies to the RTP stream. The second specification, if present, applies to the RTCP stream, unless in the case RTP and RTCP multiplexing is negotiated where both RTP and RTCP will use the first specification.
o いずれかのパラメーターで指定された最初のアドレス指定は、RTPストリームに適用されます。 RTPとRTCPの両方が最初の仕様を使用する場合にRTPとRTCPの多重化がネゴシエートされる場合を除いて、2番目の仕様が存在する場合は、RTCPストリームに適用されます。
o The RTP/UDP packets from the server to the client MUST be sent to the address and port given by the first address specification of the "dest_addr" parameter.
o サーバーからクライアントへのRTP / UDPパケットは、「dest_addr」パラメーターの最初のアドレス指定で指定されたアドレスとポートに送信する必要があります。
o The RTCP/UDP packets from the server to the client MUST be sent to the address and port given by the second address specification of the "dest_addr" parameter, unless RTP and RTCP multiplexing has been negotiated, in which case RTCP MUST be sent to the first address specification. If no second pair is specified and RTP and RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent.
o サーバーからクライアントへのRTCP / UDPパケットは、「dest_addr」パラメータの2番目のアドレス指定で指定されたアドレスとポートに送信する必要があります。ただし、RTPとRTCPの多重化がネゴシエートされていない場合は、RTCPを最初のアドレス指定。 2番目のペアが指定されておらず、RTPとRTCPの多重化がネゴシエートされていない場合、RTCPを送信してはならない（MUST NOT）。
o The RTCP/UDP packets from the client to the server MUST be sent to the address and port given by the second address specification of the "src_addr" parameter, unless RTP and RTCP multiplexing has been negotiated, in which case RTCP MUST be sent to the first address specification. If no second pair is specified and RTP and RTCP multiplexing has not been negotiated, RTCP MUST NOT be sent.
o クライアントからサーバーへのRTCP / UDPパケットは、RTPとRTCPの多重化がネゴシエートされていない限り、「src_addr」パラメータの2番目のアドレス指定で指定されたアドレスとポートに送信する必要があります。最初のアドレス指定。 2番目のペアが指定されておらず、RTPとRTCPの多重化がネゴシエートされていない場合、RTCPを送信してはならない（MUST NOT）。
o The RTP/UDP packets from the client to the server MUST be sent to the address and port given by the first address specification of the "src_addr" parameter.
o クライアントからサーバーへのRTP / UDPパケットは、「src_addr」パラメーターの最初のアドレス指定で指定されたアドレスとポートに送信する必要があります。
o RTP and RTCP packets SHOULD be sent from the corresponding receiver port, i.e., RTCP packets from the server should be sent from the "src_addr" parameters second address port pair, unless RTP and RTCP multiplexing has been negotiated in which case the first address port pair is used.
o RTPパケットとRTCPパケットは対応する受信ポートから送信する必要があります。つまり、サーバーからのRTCPパケットは、「src_addr」パラメータの2番目のアドレスポートのペアから送信する必要があります。使用されている。
The RTP profile "Extended RTP Profile for RTCP-based Feedback (RTP/ AVPF)" [RFC4585] MAY be used as RTP profiles in sessions using RTP. All that is defined for AVP MUST also apply for AVPF.
RTPプロファイル「RTPベースのフィードバック用の拡張RTPプロファイル（RTP / AVPF）」[RFC4585]は、RTPを使用するセッションでRTPプロファイルとして使用できます。 AVPに定義されているものはすべてAVPFにも適用する必要があります。
The usage of AVPF is indicated by the media initialization protocol used. In the case of SDP, it is indicated by media lines ("m=") containing the profile RTP/AVPF. That SDP MAY also contain further AVPF-related SDP attributes configuring the AVPF session regarding reporting interval and feedback messages to be used [RFC4585]. This configuration MUST be followed.
AVPFの使用は、使用されるメディア初期化プロトコルによって示されます。 SDPの場合は、プロファイルRTP / AVPFを含むメディア行（ "m ="）で示されます。そのSDPは、レポート間隔と使用するフィードバックメッセージに関するAVPFセッションを構成するAVPF関連のSDP属性をさらに含む場合があります[RFC4585]。この構成に従う必要があります。
The RTP profile "The Secure Real-time Transport Protocol (SRTP)" [RFC3711] is an RTP profile (SAVP) that MAY be used in RTSP sessions using RTP. All that is defined for AVP MUST also apply for SAVP.
RTPプロファイル「Secure Real-time Transport Protocol（SRTP）」[RFC3711]は、RTPを使用するRTSPセッションで使用できるRTPプロファイル（SAVP）です。 AVPに定義されているものはすべてSAVPにも適用する必要があります。
The usage of SRTP requires that a security context be established. The default key-management unless otherwise signaled SHALL be MIKEY in RSA-R mode as defined in Appendix C.1.4.1 and not according to the procedure defined in "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)" [RFC4567]. The reason is that RFC 4567 sends the initial MIKEY message in SDP, thus, both requiring the usage of the DESCRIBE method and forcing the server to keep state for clients performing DESCRIBE in anticipation that they might require key management.
SRTPを使用するには、セキュリティコンテキストを確立する必要があります。付録C.1.4.1で定義されているRSA-RモードのMIKEYは、「セッション記述プロトコル（SDP）およびリアルタイムストリーミングプロトコルのキー管理拡張機能（ RTSP）」[RFC4567]。その理由は、RFC 4567が最初のMIKEYメッセージをSDPで送信するため、DESCRIBEメソッドを使用する必要があり、DESCRIBEを実行するクライアントがキー管理を必要とする可能性があると予測して、サーバーに状態を維持させることです。
MIKEY is selected as the default method for establishing SRTP cryptographic context within an RTSP session as it can be embedded in the RTSP messages while still ensuring confidentiality of content of the keying material, even when using hop-by-hop TLS security for the RTSP messages. This method also supports pipelining of the RTSP messages.
RTSPメッセージにホップバイホップTLSセキュリティを使用している場合でも、キーマテリアルのコンテンツの機密性を確保しながら、RTSPメッセージに埋め込むことができるため、RTSPセッション内でSRTP暗号コンテキストを確立するデフォルトの方法としてMIKEYが選択されています。このメソッドは、RTSPメッセージのパイプライン処理もサポートします。
This method for using MIKEY [RFC3830] to establish the SRTP cryptographic context is initiated in the client's SETUP request, and the server's response to the SETUP carries the MIKEY response. This ensures that the crypto context establishment happens simultaneously with the establishment of the media stream being protected. By using MIKEY's RSA-R mode [RFC4738] the client can be the initiator and still allow the server to set the parameters in accordance with the actual media stream.
MIKEY [RFC3830]を使用してSRTP暗号化コンテキストを確立するこの方法は、クライアントのSETUP要求で開始され、SETUPに対するサーバーの応答はMIKEY応答を伝達します。これにより、暗号化コンテキストの確立が、保護されているメディアストリームの確立と同時に行われることが保証されます。 MIKEYのRSA-Rモード[RFC4738]を使用することにより、クライアントはイニシエーターになり、サーバーが実際のメディアストリームに従ってパラメーターを設定できるようになります。
The SRTP cryptographic context establishment is done according to the following process:
SRTP暗号化コンテキストの確立は、次のプロセスに従って行われます。
1. The client determines that SAVP or SAVPF shall be used from the media-description format, e.g., SDP. If no other key-management method is explicitly signaled, then MIKEY SHALL be used as defined herein. The use of SRTP with RTSP is only defined with MIKEY with keys established as defined in this section. Future documents may define how an RTSP implementation treats SDP that indicates some other key mechanism to be used. The need for such specification includes [RFC4567], which is not defined for use in RTSP 2.0 within this document.
1. クライアントは、SAVPまたはSAVPFがメディア記述フォーマット（SDPなど）から使用されることを決定します。他のキー管理方法が明示的に通知されない場合、ここで定義されているようにMIKEYを使用する必要があります。 RTSPでのSRTPの使用は、このセクションで定義されているように確立されたキーを持つMIKEYでのみ定義されます。今後のドキュメントでは、RTSP実装がSDPをどのように処理するかを定義し、他のいくつかの主要なメカニズムの使用を示します。このような仕様の必要性には、[RFC4567]が含まれます。これは、このドキュメント内のRTSP 2.0で使用するために定義されていません。
2. The client SHALL establish a TLS connection for RTSP messages, directly or hop-by-hop with the server. If hop-by-hop TLS security is used, the User method SHALL be indicated in the Accept-Credentials header. Note that using hop-by-hop does allow the proxy to insert itself as a man in the middle. This can also occur in the MIKEY exchange by the proxy providing one of its certificates rather than the server's in the Connection-Credentials header. Therefore, the client SHALL validate the server certificate.
2. クライアントは、サーバーと直接またはホップバイホップで、RTSPメッセージのTLS接続を確立する必要があります（SHALL）。ホップバイホップのTLSセキュリティが使用される場合、UserメソッドはAccept-Credentialsヘッダーで示される必要があります。ホップバイホップを使用すると、プロキシが中間に人間として自分自身を挿入できるようになることに注意してください。これは、Connection-Credentialsヘッダーのサーバーではなく、証明書の1つを提供するプロキシによるMIKEY交換でも発生する可能性があります。したがって、クライアントはサーバー証明書を検証する必要があります（SHALL）。
3. The client retrieves the server's certificate from a direct TLS connection or hop-by-hop from a Connection-Credentials header. The client then checks that the server certificate is valid and belongs to the server.
3. クライアントは、直接TLS接続からサーバーの証明書を取得するか、Connection-Credentialsヘッダーからホップバイホップで取得します。次に、クライアントはサーバー証明書が有効であり、サーバーに属していることを確認します。
4. The client forms the MIKEY Initiator message using RSA-R mode in unicast mode as specified in [RFC4738]. The client SHOULD use the same certificate for TLS and MIKEY to enable the server to bind the two together. The client's certificate SHALL be included in the MIKEY message. The client SHALL indicate its SRTP capabilities in the message.
4. クライアントは、[RFC4738]で指定されているように、ユニキャストモードでRSA-Rモードを使用してMIKEYイニシエーターメッセージを形成します。クライアントは、TLSとMIKEYに同じ証明書を使用して、サーバーが2つをバインドできるようにする必要があります（SHOULD）。クライアントの証明書はMIKEYメッセージに含まれる必要があります。クライアントは、メッセージでSRTP機能を示す必要があります（SHALL）。
5. The MIKEY message from the previous step is base64-encoded [RFC4648] and becomes the value of the MIKEY parameter that is included in the transport specification(s) that specifies an SRTP-based profile (SAVP, SAVPF) in the SETUP request.
5. 前のステップからのMIKEYメッセージはbase64でエンコードされた[RFC4648]であり、SETUP要求でSRTPベースのプロファイル（SAVP、SAVPF）を指定するトランスポート仕様に含まれるMIKEYパラメータの値になります。
6. Any proxy encountering the MIKEY parameter SHALL forward it without modification. A proxy that is required to understand the Transport specifications will need to understand SAVP/SAVPF with MIKEY to enable the default keying for SRTP-protected media streams. If such a proxy does not support SAVP/SAVPF with MIKEY, it will discard the whole transport specification. Most types of proxies can easily support SAVP and SAVPF with MIKEY. If a client encounters a proxy not supporting SAVP/SAVPF with MIKEY, the client should attempt bypassing that proxy.
6. MIKEYパラメータを検出したプロキシは、変更せずに転送する必要があります。トランスポート仕様を理解するために必要なプロキシは、SRTPで保護されたメディアストリームのデフォルトのキーイングを有効にするために、MIKEYを備えたSAVP / SAVPFを理解する必要があります。そのようなプロキシがMIKEYでSAVP / SAVPFをサポートしない場合、トランスポート仕様全体が破棄されます。ほとんどのタイプのプロキシは、MIKEYを使用してSAVPおよびSAVPFを簡単にサポートできます。クライアントがMIKEYでSAVP / SAVPFをサポートしていないプロキシを検出した場合、クライアントはそのプロキシをバイパスする必要があります。
7. The server, upon receiving the SETUP request, will need to decide upon the transport specification to use, if multiple are included by the client. In the determination of which transport specifications are supported and preferred, the server SHOULD decode the MIKEY message to take the embedded SRTP parameters into account. If all transport spec require SRTP but no MIKEY parameter or other supported keying method is included, the server SHALL respond with 403 (Forbidden).
7. クライアントは、SETUP要求を受信すると、複数のトランスポート仕様が含まれている場合、使用するトランスポート仕様を決定する必要があります。どのトランスポート仕様がサポートされ、優先されるかを決定する際に、サーバーはMIKEYメッセージをデコードして、埋め込まれたSRTPパラメータを考慮に入れる必要があります（SHOULD）。すべてのトランスポート仕様がSRTPを必要とするが、MIKEYパラメータや他のサポートされているキーイング方法が含まれていない場合、サーバーは403（禁止）で応答する必要があります（SHALL）。
8. Upon generating a response, the following outcomes can occur:
8. 応答を生成すると、次の結果が発生する可能性があります。
* A transport spec not using SRTP and MIKEY is selected. Thus, the response will not contain any MIKEY parameters.
* SRTPおよびMIKEYを使用しないトランスポート仕様が選択されています。したがって、応答にはMIKEYパラメータが含まれません。
* A transport spec using SRTP and MIKEY is selected but an error is encountered in the MIKEY processing. In this case, an RTSP error response code of 466 (Key Management Error) SHALL be used. A MIKEY message describing the error MAY be included.
* SRTPおよびMIKEYを使用するトランスポート仕様が選択されていますが、MIKEY処理でエラーが発生しました。この場合、466（キー管理エラー）のRTSPエラー応答コードを使用する必要があります。エラーを説明するMIKEYメッセージが含まれる場合があります。
* A transport spec using SRTP and MIKEY is selected and a MIKEY response message can be created. The server SHOULD use the same certificate for TLS and in MIKEY to enable the client to bind the two together. If a different certificate is used, it SHALL be included in the MIKEY message. It is RECOMMENDED that the envelope key-cache type be set to 'Cache' and that a single envelope key is reused for all MIKEY messages to the client. That message is included in the MIKEY parameter part of the single selected transport specification in the SETUP response. The server will set the SRTP parameters as preferred for this media stream within the supported range by the client.
* SRTPとMIKEYを使用するトランスポート仕様が選択され、MIKEY応答メッセージを作成できます。サーバーはTLSとMIKEYで同じ証明書を使用して、クライアントが2つをバインドできるようにする必要があります（SHOULD）。別の証明書を使用する場合は、MIKEYメッセージに含める必要があります。エンベロープキーキャッシュタイプを「キャッシュ」に設定し、クライアントへのすべてのMIKEYメッセージに単一のエンベロープキーを再利用することをお勧めします。そのメッセージは、SETUP応答で選択された単一のトランスポート指定のMIKEYパラメータ部分に含まれています。サーバーは、クライアントがサポートする範囲内で、このメディアストリームの優先としてSRTPパラメータを設定します。
9. The server transmits the SETUP response back to the client.
9. サーバーはSETUP応答をクライアントに送信します。
10. The client receives the SETUP response and, if the response code indicates a successful request, it decodes the MIKEY message and establishes the SRTP cryptographic context from the parameters in the MIKEY response.
10. クライアントはSETUP応答を受信し、応答コードが要求の成功を示している場合は、MIKEYメッセージをデコードし、MIKEY応答のパラメーターからSRTP暗号化コンテキストを確立します。
In the above method, the client's certificate may be self signed in cases where the client's identity is not necessary to authenticate and the security goal is only to ensure that the RTSP signaling client is the same as the one receiving the SRTP security context.
上記の方法では、クライアントのIDが認証に必要なく、セキュリティの目標が、RTSPシグナリングクライアントがSRTPセキュリティコンテキストを受信するクライアントと同じであることを確認することだけである場合、クライアントの証明書は自己署名される場合があります。
The RTP profile "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)" [RFC5124] is an RTP profile (SAVPF) that MAY be used in RTSP sessions using RTP. All that is defined for AVPF MUST also apply for SAVPF.
RTPプロファイル「リアルタイム転送制御プロトコル（RTCP）ベースのフィードバック用の拡張セキュアRTPプロファイル（RTP / SAVPF）」[RFC5124]は、RTPを使用するRTSPセッションで使用できるRTPプロファイル（SAVPF）です。 AVPFに定義されているものはすべて、SAVPFにも適用する必要があります。
The usage of SRTP requires that a cryptographic context be established. The default mechanism for establishing that security association is to use MIKEY[RFC3830] with RTSP as defined in Appendix C.1.4.1.
SRTPを使用するには、暗号化コンテキストを確立する必要があります。セキュリティアソシエーションを確立するためのデフォルトのメカニズムは、付録C.1.4.1で定義されているように、RTSPでMIKEY [RFC3830]を使用することです。
RTCP has several usages when RTP is implemented for media transport as explained below. Thus, RTCP MUST be supported if an RTSP agent handles RTP.
以下で説明するように、RTPがメディア転送に実装されている場合、RTCPにはいくつかの使用法があります。したがって、RTSPエージェントがRTPを処理する場合、RTCPをサポートする必要があります。
RTCP provides media synchronization and clock-drift compensation. The initial media synchronization is available from RTP-Info header. However, to be able to handle any clock drift between the media streams, RTCP is needed.
RTCPは、メディア同期とクロックドリフト補償を提供します。最初のメディア同期は、RTP-Infoヘッダーから利用できます。ただし、メディアストリーム間のクロックドリフトを処理できるようにするには、RTCPが必要です。
RTCP traffic from the RTSP client to the RTSP server MUST function as keep-alive. This requires an RTSP server supporting RTP to use the received RTCP packets as indications that the client desires the related RTSP session to be kept alive.
RTSPクライアントからRTSPサーバーへのRTCPトラフィックは、キープアライブとして機能する必要があります。これには、RTPをサポートするRTSPサーバーが、受信したRTCPパケットを、クライアントが関連するRTSPセッションの存続を望んでいることを示すものとして使用する必要があります。
RTCP Receiver reports and any additional feedback from the client MUST be used to adapt the bitrate used over the transport for all cases when RTP is sent over UDP. An RTP sender without reserved resources MUST NOT use more than its fair share of the available resources. This can be determined by comparing on short-to-medium terms (some seconds) the used bitrate and adapting it so that the RTP sender sends at a bitrate comparable to what a TCP sender would achieve on average over the same path.
RTPがUDP経由で送信されるすべての場合に、RTCPレシーバーレポートとクライアントからの追加のフィードバックを使用して、トランスポートで使用されるビットレートを適合させる必要があります。予約されたリソースのないRTP送信者は、利用可能なリソースの公平なシェア以上のものを使用してはなりません。これは、使用されたビットレートを中程度の条件（数秒）で比較し、RTP送信者が同じパスでTCP送信者が平均して達成するものに匹敵するビットレートで送信するようにそれを適応させることによって決定できます。
To ensure that the implementation's adaptation mechanism has a well-defined outer envelope, all implementations using a non-congestion-controlled unicast transport protocol, like UDP, MUST implement "Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions" [RTP-CIRCUIT-BREAKERS].
実装の適応メカニズムに明確に定義された外部エンベロープがあることを保証するために、UDPなどの非輻輳制御のユニキャストトランスポートプロトコルを使用するすべての実装は、「マルチメディア輻輳制御：ユニキャストRTPセッションの回路ブレーカー」を実装する必要があります[RTP-CIRCUIT-ブレーカーズ]。
RTSP can be used to negotiate the usage of RTP and RTCP multiplexing as described in [RFC5761]. This allows servers and client to reduce the amount of resources required for the session by only requiring one underlying transport stream per media stream instead of two when using RTP and RTCP. This lessens the server-port consumption and also the necessary state and keep-alive work when operating across NATs [RFC2663].
RTSPは、[RFC5761]で説明されているように、RTPおよびRTCP多重化の使用をネゴシエートするために使用できます。これにより、サーバーとクライアントは、RTPとRTCPを使用するときに、メディアストリームごとに2つではなく1つの基になるトランスポートストリームのみを必要とすることで、セッションに必要なリソースの量を削減できます。これにより、サーバーポートの消費量が減り、NAT全体で動作する場合に必要な状態とキープアライブ作業も軽減されます[RFC2663]。
Content must be prepared with some consideration for RTP and RTCP multiplexing, mainly ensuring that the RTP payload types used do not collide with the ones used for RTCP packet types. This option likely needs explicit support from the content unless the RTP payload types can be remapped by the server and that is correctly reflected in the session description. Beyond that, support of this feature should come at little cost and much gain.
コンテンツは、RTPおよびRTCPの多重化を考慮して準備する必要があります。主に、使用されるRTPペイロードタイプがRTCPパケットタイプに使用されるタイプと衝突しないようにします。このオプションは、RTPペイロードタイプがサーバーによって再マッピングされ、セッションの説明に正しく反映されない限り、コンテンツからの明示的なサポートを必要とする可能性があります。それ以上に、この機能のサポートはほとんどコストと利益をもたらさないはずです。
It is recommended that, if the content and server support RTP and RTCP multiplexing, this is indicated in the session description, for example, using the SDP attribute "a=rtcp-mux". If the SDP message contains the "a=rtcp-mux" attribute for a media stream, the server MUST support RTP and RTCP multiplexing. If indicated or otherwise desired by the client, it can include the Transport parameter "RTCP-mux" in any transport specification where it desires to use "RTCP-mux". The server will indicate if it supports "RTCP-mux". Servers and Clients SHOULD support RTP and RTCP multiplexing.
コンテンツとサーバーがRTPおよびRTCP多重化をサポートしている場合、これは、たとえばSDP属性 "a = rtcp-mux"を使用して、セッションの説明に示されることをお勧めします。 SDPメッセージにメディアストリームの「a = rtcp-mux」属性が含まれている場合、サーバーはRTPおよびRTCP多重化をサポートする必要があります。クライアントによって示されるか、そうでなければ望まれる場合、「RTCP-mux」を使用したいトランスポート仕様にトランスポートパラメータ「RTCP-mux」を含めることができます。サーバーは、「RTCP-mux」をサポートするかどうかを示します。サーバーとクライアントは、RTPとRTCPの多重化をサポートする必要があります（SHOULD）。
For capability exchange, an RTSP feature tag for RTP and RTCP multiplexing is defined: "setup.rtp.rtcp.mux".
機能交換のために、RTPおよびRTCP多重化のためのRTSP機能タグが定義されています： "setup.rtp.rtcp.mux"。
To minimize the risk of negotiation failure while using RTP and RTCP multiplexing, some recommendations are here provided. If the session description includes explicit indication of support ("a=rtcp-mux" in SDP), then an RTSP agent can safely create a SETUP request with a transport specification with only a single "dest_addr" parameter address specification. If no such explicit indication is provided, then even if the feature tag "setup.rtp.rtcp.mux" is provided in a Supported header by the RTSP server or the feature tag included in the Required header in the SETUP request, the media resource may not support RTP and RTCP multiplexing. Thus, to maximize the probability of successful negotiation, the RTSP agent is recommended to include two "dest_addr" parameter address specifications in the first or first set (if pipelining is used) of SETUP request(s) for any media resource aggregate. That way, the RTSP server can accept RTP and RTCP multiplexing and only use the first address specification or, if not, use both specifications. The RTSP agent, after having received the response for a successful negotiation of the usage of RTP and RTCP multiplexing, can then release the resources associated with the second address specification.
RTPおよびRTCP多重化の使用中にネゴシエーションが失敗するリスクを最小限に抑えるために、ここではいくつかの推奨事項を示します。セッションの説明にサポートの明示的な指示（SDPの「a = rtcp-mux」）が含まれている場合、RTSPエージェントは、単一の「dest_addr」パラメーターアドレス指定のみのトランスポート指定でSETUP要求を安全に作成できます。そのような明示的な指示が提供されない場合、機能タグ「setup.rtp.rtcp.mux」がRTSPサーバーによってサポートされるヘッダーで提供されるか、またはSETUP要求の必須ヘッダーに含まれる機能タグであったとしても、メディアリソースRTPおよびRTCP多重化をサポートしない場合があります。したがって、ネゴシエーションが成功する確率を最大にするために、RTSPエージェントは、メディアリソース集合体のSETUP要求の最初または最初のセット（パイプラインが使用されている場合）に2つの「dest_addr」パラメーターアドレス指定を含めることをお勧めします。このようにして、RTSPサーバーはRTPおよびRTCP多重化を受け入れ、最初のアドレス指定のみを使用するか、そうでない場合は両方の指定を使用できます。 RTSPエージェントは、RTPおよびRTCP多重化の使用のネゴシエーションの成功に対する応答を受け取った後、2番目のアドレス指定に関連付けられたリソースを解放できます。
Transport of RTP over TCP can be done in two ways: over independent TCP connections using [RFC4571] or interleaved in the RTSP connection. In both cases, the protocol MUST be "rtp" and the lower-layer MUST be TCP. The profile may be any of the above specified ones: AVP, AVPF, SAVP, or SAVPF.
RTP over TCPの転送は、[RFC4571]を使用する独立したTCP接続を介して、またはRTSP接続でインターリーブして、2つの方法で実行できます。どちらの場合も、プロトコルは「rtp」でなければならず、下位層はTCPでなければなりません。プロファイルは、AVP、AVPF、SAVP、またはSAVPFの上記で指定されたもののいずれかです。
The use of embedded (interleaved) binary data transported on the RTSP connection is possible as specified in Section 14. When using this declared combination of interleaved binary data, the RTSP messages MUST be transported over TCP. TLS may or may not be used. If TLS is used, both RTSP messages and the binary data will be protected by TLS.
セクション14で指定されているように、RTSP接続で転送される埋め込み（インターリーブ）バイナリデータの使用が可能です。この宣言されたインターリーブバイナリデータの組み合わせを使用する場合、RTSPメッセージはTCP経由で転送する必要があります。 TLSは使用される場合と使用されない場合があります。 TLSを使用する場合、RTSPメッセージとバイナリデータの両方がTLSによって保護されます。
One should, however, consider that this will result in all media streams going through any proxy. Using independent TCP connections can avoid that issue.
ただし、これにより、すべてのメディアストリームが任意のプロキシを通過することになります。独立したTCP接続を使用すると、この問題を回避できます。
In this section, the sending of RTP [RFC3550] over lower-layer transport TCP [RFC793] according to "Framing Real-time Transport Protocol (RTP) and RTP Control Protocol (RTCP) Packets over Connection-Oriented Transport" [RFC4571] is described. This section adapts the guidelines for using RTP over TCP within SIP/SDP [RFC4145] to work with RTSP.
このセクションでは、「コネクション型トランスポートを介したフレーミングリアルタイムトランスポートプロトコル（RTP）およびRTP制御プロトコル（RTCP）パケット」[RFC4571]に従って、下位層のトランスポートTCP [RFC793]を介してRTP [RFC3550]を送信します。説明。このセクションでは、RTSPと連携するためにSIP / SDP [RFC4145]内でRTP over TCPを使用するためのガイドラインを採用しています。
A client codes the support of RTP over independent TCP by specifying an RTP/AVP/TCP transport option without an interleaved parameter in the Transport line of a SETUP request. This transport option MUST include the "unicast" parameter.
クライアントは、SETUP要求のトランスポート行でインターリーブされたパラメーターなしでRTP / AVP / TCPトランスポートオプションを指定することにより、独立したTCPを介したRTPのサポートをコーディングします。このトランスポートオプションには、「ユニキャスト」パラメーターを含める必要があります。
If the client wishes to use RTP with RTCP, two address specifications need to be included in the "dest_addr" parameter. If the client wishes to use RTP without RTCP, one address specification is included in the "dest_addr" parameter. If the client wishes to multiplex RTP and RTCP on a single transport flow (see Appendix C.1.6.4), one or two address specifications are included in the "dest_addr" parameter in addition to the "RTCP-mux" transport parameter. Two address specifications are allowed to facilitate successful negotiation when the server or content can't support RTP and RTCP multiplexing. Ordering rules of dest_addr ports follow the rules for RTP/AVP/UDP.
クライアントがRTCPでRTPを使用したい場合、「dest_addr」パラメーターに2つのアドレス指定を含める必要があります。クライアントがRTCPなしでRTPを使用したい場合、1つのアドレス指定が「dest_addr」パラメーターに含まれます。クライアントが単一のトランスポートフローでRTPとRTCPを多重化する場合（付録C.1.6.4を参照）、「RTCP-mux」トランスポートパラメーターに加えて「dest_addr」パラメーターに1つまたは2つのアドレス指定が含まれます。サーバーまたはコンテンツがRTPおよびRTCP多重化をサポートできない場合、ネゴシエーションを成功させるために2つのアドレス指定が許可されています。 dest_addrポートの順序付け規則は、RTP / AVP / UDPの規則に従います。
If the client wishes to play the active role in initiating the TCP connection, it MAY set the setup parameter (see Section 18.54) on the Transport line to be "active", or it MAY omit the setup parameter, as active is the default. If the client signals the active role, the ports in the address specifications in the "dest_addr" parameter MUST be set to 9 (the discard port).
クライアントがTCP接続を開始する際にアクティブな役割を果たしたい場合は、トランスポートラインのセットアップパラメータ（セクション18.54を参照）を「アクティブ」に設定するか、デフォルトがアクティブであるため、セットアップパラメータを省略できます（MAY）。クライアントがアクティブな役割を通知する場合、「dest_addr」パラメーターのアドレス指定のポートを9（廃棄ポート）に設定する必要があります。
If the client wishes to play the passive role in TCP connection initiation, it MUST set the setup parameter on the Transport line to be "passive". If the client is able to assume the active or the passive role, it MUST set the setup parameter on the Transport line to be "actpass". In either case, the "dest_addr" parameter's address specification port value for RTP MUST be set to the TCP port number on which the client is expecting to receive the TCP connection for RTP, and the "dest_addr" address specification port value for RTCP MUST be set to the TCP port number on which the client is expecting to receive the TCP connection for RTCP. In the case that the client wishes to multiplex RTP and RTCP on a single transport flow, the "RTCP-mux" parameter is included and one or two "dest_addr" parameter address specifications are included, as mentioned earlier in this section.
クライアントがTCP接続の開始でパッシブの役割を果たしたい場合は、トランスポートラインのセットアップパラメータを「パッシブ」に設定する必要があります。クライアントがアクティブまたはパッシブの役割を引き受けることができる場合は、トランスポートラインのセットアップパラメータを「actpass」に設定する必要があります。どちらの場合も、RTPの「dest_addr」パラメータのアドレス指定ポート値は、クライアントがRTPのTCP接続を受信することを期待しているTCPポート番号に設定する必要があり、RTCPの「dest_addr」アドレス指定ポート値はクライアントがRTCPのTCP接続を受信することを期待しているTCPポート番号に設定します。このセクションで前述したように、クライアントが単一のトランスポートフローでRTPとRTCPを多重化する場合は、「RTCP-mux」パラメーターが含まれ、1つまたは2つの「dest_addr」パラメーターアドレス指定が含まれます。
Upon receipt of a non-interleaved RTP/AVP/TCP SETUP request, if a server decides to accept this requested option, the 2xx reply MUST contain a Transport option that specifies RTP/AVP/TCP (without using the interleaved parameter and using the unicast parameter). The "dest_addr" parameter value MUST be echoed from the parameter value in the client request unless the destination address (only port) was not provided; in which case, the server MAY include the source address of the RTSP TCP connection with the port number unchanged.
インターリーブされていないRTP / AVP / TCP SETUP要求を受信すると、サーバーがこの要求されたオプションを受け入れることを決定した場合、2xx応答には、RTP / AVP / TCPを指定するトランスポートオプションが含まれている必要があります（インターリーブパラメーターを使用せず、ユニキャストを使用しませんパラメータ）。 「dest_addr」パラメーター値は、宛先アドレス（ポートのみ）が提供されない限り、クライアント要求のパラメーター値からエコーする必要があります。その場合、サーバーは、ポート番号を変更せずに、RTSP TCP接続のソースアドレスを含めることができます。
In addition, the server reply MUST set the setup parameter on the Transport line, to indicate the role the server will play in the connection setup. Permissible values are "active" (if a client set setup to "passive" or "actpass") and "passive" (if a client set setup to "active" or "actpass").
さらに、サーバー応答は、トランスポート行にセットアップパラメータを設定して、接続セットアップでサーバーが果たす役割を示す必要があります。許容値は、「アクティブ」（クライアントが「パッシブ」または「actpass」に設定を設定した場合）および「パッシブ」（クライアントが「アクティブ」または「actpass」に設定を設定した場合）です。
If a server sets setup to "passive", the "src_addr" in the reply MUST indicate the ports on which the server is willing to receive a TCP connection for RTP and (if the client requested a TCP connection for RTCP by specifying two "dest_addr" address specifications) a TCP/ RTCP connection. If a server sets setup to "active", the ports specified in "src_addr" address specifications MUST be set to 9. The server MAY use the "ssrc" parameter, following the guidance in Section 18.54. The server sets only one address specification in the case that the client has indicated only a single address specification or in case RTP and RTCP multiplexing was requested and accepted by the server. Port ordering for "src_addr" follows the rules for RTP/AVP/UDP.
サーバーがセットアップを「パッシブ」に設定する場合、応答の「src_addr」は、サーバーがRTPのTCP接続を受信する用意があるポートを示す必要があります（クライアントが2つの「dest_addrを指定してRTCPのTCP接続を要求した場合"アドレス指定）TCP / RTCP接続。サーバーがセットアップを「アクティブ」に設定する場合、「src_addr」アドレス指定で指定されたポートを9に設定する必要があります。サーバーは、セクション18.54のガイダンスに従って、「ssrc」パラメーターを使用できます（MAY）。クライアントが単一のアドレス指定のみを示した場合、またはRTPおよびRTCP多重化がサーバーによって要求されて受け入れられた場合、サーバーは1つのアドレス指定のみを設定します。 「src_addr」のポートの順序は、RTP / AVP / UDPのルールに従います。
Servers MUST support taking the passive role and MAY support taking the active role. Servers with a public IP address take the passive role, thus enabling clients behind NATs and firewalls a better chance of successful connect to the server by actively connecting outwards. Therefore, the clients are RECOMMENDED to take the active role.
サーバーは受動的な役割をサポートする必要があり、能動的な役割をサポートする場合があります。パブリックIPアドレスを持つサーバーはパッシブな役割を担うため、NATおよびファイアウォールの背後にあるクライアントは、積極的に外部に接続することでサーバーに接続できる可能性が高くなります。したがって、クライアントは積極的な役割を果たすことをお勧めします。
After sending (receiving) a 2xx reply for a SETUP method for a non-interleaved RTP/AVP/TCP media stream, the active party SHOULD initiate the TCP connection as soon as possible. The client MUST NOT send a PLAY request prior to the establishment of all the TCP connections negotiated using SETUP for the session. In case the server receives a PLAY request in a session that has not yet established all the TCP connections, it MUST respond using the 464 (Data Transport Not Ready Yet) (Section 17.4.28) error code.
インターリーブされていないRTP / AVP / TCPメディアストリームのSETUPメソッドに対する2xx応答を送信（受信）した後、アクティブパーティはTCP接続をできるだけ早く開始する必要があります（SHOULD）。クライアントは、セッションのSETUPを使用してネゴシエートされたすべてのTCP接続の確立前に、PLAY要求を送信してはなりません（MUST NOT）。サーバーがすべてのTCP接続をまだ確立していないセッションでPLAY要求を受信した場合、サーバーは464（データ転送の準備ができていません）（セクション17.4.28）エラーコードを使用して応答する必要があります。
Once the PLAY request for a media resource transported over non-interleaved RTP/AVP/TCP occurs, media begins to flow from server to client over the RTP TCP connection, and RTCP packets flow bidirectionally over the RTCP TCP connection. Unless RTP and RTCP multiplexing has been negotiated; in which case, RTP and RTCP will flow over a common TCP connection. As in the RTP/UDP case, client-to-server traffic on an RTP-only TCP session is unspecified by this memo. The packets that travel on these connections MUST be framed using the protocol defined in [RFC4571], not by the framing defined for interleaving RTP over the RTSP connection defined in Section 14.
非インターリーブRTP / AVP / TCPを介して転送されるメディアリソースに対するPLAY要求が発生すると、RTP TCP接続を介してメディアがサーバーからクライアントに流れ始め、RTCPパケットがRTCP TCP接続を介して双方向に流れます。 RTPとRTCPの多重化がネゴシエートされていない限り。その場合、RTPとRTCPは共通のTCP接続を介して流れます。 RTP / UDPの場合と同様に、RTPのみのTCPセッションでのクライアントからサーバーへのトラフィックは、このメモでは指定されていません。これらの接続で移動するパケットは、セクション14で定義されたRTSP接続でRTPをインターリーブするために定義されたフレーミングではなく、[RFC4571]で定義されたプロトコルを使用してフレーム化する必要があります。
A successful PAUSE request for media being transported over RTP/AVP/ TCP pauses the flow of packets over the connections, without closing the connections. A successful TEARDOWN request signals that the TCP connections for RTP and RTCP are to be closed by the RTSP client as soon as possible.
RTP / AVP / TCPを介して転送されるメディアのPAUSE要求が成功すると、接続を閉じることなく、接続を介したパケットのフローが一時停止します。 TEARDOWN要求が成功すると、RTPおよびRTCPのTCP接続がRTSPクライアントによってできるだけ早く閉じられることが通知されます。
Subsequent SETUP requests using a URI already set up in an RTSP session using an RTP/AVP/TCP transport specification may be ambiguous in the following way: does the client wish to open up a new TCP connection for RTP or RTCP for the URI, or does the client wish to continue using the existing TCP connections? The client SHOULD use the "connection" parameter (defined in Section 18.54) on the Transport line to make its intention clear (by setting "connection" to "new" if new connections are needed, and by setting "connection" to "existing" if the existing connections are to be used). After a 2xx reply for a SETUP request for a new connection, parties should close the preexisting connections, after waiting a suitable period for any stray RTP or RTCP packets to arrive.
RTP / AVP / TCPトランスポート仕様を使用してRTSPセッションで既に設定されているURIを使用する後続のSETUP要求は、次のようにあいまいになる可能性があります。クライアントが、URIのRTPまたはRTCPの新しいTCP接続を開くことを望んでいるか、またはクライアントは既存のTCP接続を引き続き使用しますか？クライアントは、トランスポートラインの「接続」パラメータ（セクション18.54で定義）を使用して意図を明確にする必要があります（新しい接続が必要な場合は「接続」を「新規」に設定し、「接続」を「既存」に設定することによって）既存の接続を使用する場合）。新しい接続のSETUP要求に対する2xx応答の後、迷惑なRTPまたはRTCPパケットが到着するまで適切な期間待機した後、当事者は既存の接続を閉じる必要があります。
The usage of SRTP, i.e., either SAVP or SAVPF profiles, requires that a security association be established. The default mechanism for establishing that security association is to use MIKEY[RFC3830] with RTSP as defined Appendix C.1.4.1.
SRTP、つまりSAVPまたはSAVPFプロファイルを使用するには、セキュリティアソシエーションを確立する必要があります。セキュリティアソシエーションを確立するためのデフォルトのメカニズムは、付録C.1.4.1で定義されているように、RTSPでMIKEY [RFC3830]を使用することです。
Below, a rewritten version of the example "Media on Demand" (Appendix A.1) shows the use of RTP/AVP/TCP non-interleaved:
以下の例の「Media on Demand」（付録A.1）の書き直されたバージョンは、インターリーブされていないRTP / AVP / TCPの使用を示しています。
C->M: DESCRIBE rtsp://example.com/twister.3gp RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:52 +0000
Content-Type: application/sdp
Content-Length: 227
Content-Base: rtsp://example.com/twister.3gp/
Expires: Thu, 24 Jan 2013 15:36:52 +0000
v=0
o=- 2890844256 2890842807 IN IP4 198.51.100.34
s=RTSP Session
i=An Example of RTSP Session Usage
e=adm@example.com
c=IN IP4 0.0.0.0
a=control: *
a=range:npt=00:00:00-00:10:34.10
t=0 0
m=audio 0 RTP/AVP 0
a=control: trackID=1
C->M: SETUP rtsp://example.com/twister.3gp/trackID=1 RTSP/2.0
CSeq: 2
User-Agent: PhonyClient/1.2
Require: play.basic
Transport: RTP/AVP/TCP;unicast;dest_addr=":9"/":9";
setup=active;connection=new
Accept-Ranges: npt, smpte, clock
M->C: RTSP/2.0 200 OK
CSeq: 2
Server: PhonyServer/1.0
Transport: RTP/AVP/TCP;unicast;
dest_addr=":9"/":9";
src_addr="198.51.100.5:53478"/"198.51.100:54091";
setup=passive;connection=new;ssrc=93CB001E
Session: OccldOFFq23KwjYpAnBbUr
Expires: Thu, 24 Jan 2013 15:36:52 +0000
Date: Wed, 23 Jan 2013 15:36:52 +0000
Accept-Ranges: npt
Media-Properties: Random-Access=0.8, Immutable, Unlimited
C->M: TCP Connection Establishment x2
C-> M：TCP接続確立x2
C->M: PLAY rtsp://example.com/twister.3gp/ RTSP/2.0
CSeq: 4
User-Agent: PhonyClient/1.2
Range: npt=30-
Session: OccldOFFq23KwjYpAnBbUr
M->C: RTSP/2.0 200 OK
CSeq: 4
Server: PhonyServer/1.0
Date: Wed, 23 Jan 2013 15:36:54 +0000
Session: OccldOFFq23KwjYpAnBbUr
Range: npt=30-623.10
Seek-Style: First-Prior
RTP-Info: url="rtsp://example.com/twister.3gp/trackID=1"
ssrc=4F312DD8:seq=54321;rtptime=2876889
RTSP allows media clients to control selected, non-contiguous sections of media presentations, rendering those streams with an RTP media layer [RFC3550]. Two cases occur, the first is when a new PLAY request replaces an old ongoing request and the new request results in a jump in the media. This should produce continuous media stream at the RTP layer. A client may also immediately follow a completed PLAY request with a new PLAY request. This will result in some gap in the media layer. The below text will look into both cases.
RTSPを使用すると、メディアクライアントは、メディアプレゼンテーションの選択された非連続セクションを制御し、RTPメディアレイヤー[RFC3550]でこれらのストリームをレンダリングできます。 2つのケースが発生します。1つ目は、新しいPLAYリクエストが古い進行中のリクエストを置き換え、新しいリクエストがメディアにジャンプする場合です。これにより、RTPレイヤーで連続メディアストリームが生成されます。クライアントは、完了したPLAY要求の直後に新しいPLAY要求を続けることもできます。これにより、メディアレイヤーにギャップが生じます。以下のテキストは、両方のケースを調べます。
A PLAY request that replaces an ongoing PLAY request allows the media layer rendering the RTP stream to do so continuously without being affected by jumps in media-clock time. The RTP timestamps for the new media range are set so that they become continuous with the previous media range in the previous request. The RTP sequence number for the first packet in the new range will be the next following the last packet in the previous range, i.e., monotonically increasing. The goal is to allow the media-rendering layer to work without interruption or reconfiguration across the jumps in media clock. This should be possible in all cases of replaced PLAY requests for media that has random access properties. In this case, care is needed to align frames or similar media-dependent structures.
進行中のPLAY要求に取って代わるPLAY要求により、RTPストリームをレンダリングするメディアレイヤーが、メディアクロック時間のジャンプの影響を受けずに継続的にそれを行うことができます。新しいメディア範囲のRTPタイムスタンプは、前のリクエストの前のメディア範囲と連続するように設定されます。新しい範囲の最初のパケットのRTPシーケンス番号は、前の範囲の最後のパケットの次、つまり単調に増加します。目標は、メディアレンダリングレイヤーが、メディアクロックのジャンプ全体で中断または再構成することなく機能できるようにすることです。これは、ランダムアクセスプロパティを持つメディアのPLAYリクエストが置き換えられたすべての場合に可能です。この場合、フレームまたは同様のメディア依存構造を揃えるには注意が必要です。
In cases where jumps in media-clock time are a result of RTSP signaling operations arriving after a completed PLAY operation, the request timing will result in that media becoming non-continuous. The server becomes unable to send the media so that it arrives timely and still carries timestamps to make the media stream continuous. In these situations, the server will produce RTP streams where there are gaps in the RTP timeline for the media. If the media has frame structure, aligning the timestamp for the next frame with the previous structure reduces the burden to render this media. The gap should represent the time the server hasn't been serving media, e.g., the time between the end of the media stream or a PAUSE request and the new PLAY request. In these cases, the RTP sequence number would normally be monotonically increasing across the gap.
メディアクロック時間のジャンプが、PLAY操作の完了後に到着するRTSPシグナリング操作の結果である場合、リクエストタイミングにより、そのメディアは不連続になります。サーバーはメディアを送信できなくなるため、タイムリーに到着し、タイムスタンプを保持してメディアストリームを継続させます。これらの状況では、サーバーはメディアのRTPタイムラインにギャップがあるRTPストリームを生成します。メディアにフレーム構造がある場合、次のフレームのタイムスタンプを前の構造に合わせると、このメディアをレンダリングする負担が軽減されます。ギャップは、サーバーがメディアを提供していない時間を表す必要があります。たとえば、メディアストリームの終了またはPAUSEリクエストと新しいPLAYリクエストの間の時間です。これらの場合、RTPシーケンス番号は通常、ギャップ全体で単調増加します。
For RTSP sessions with media that lacks random access properties, such as live streams, any media-clock jump is commonly the result of a correspondingly long pause of delivery. The RTP timestamp will have increased in direct proportion to the duration of the paused delivery. Note also that in this case the RTP sequence number should be the next packet number. If not, the RTCP packet loss reporting will indicate as loss all packets not received between the point of pausing and later resuming. This may trigger congestion avoidance mechanisms. An allowed exception from the above recommendation on monotonically increasing RTP sequence number is live media streams, likely being relayed. In this case, when the client resumes delivery, it will get the media that is currently being delivered to the server itself. For this type of basic delivery of live streams to multiple users over unicast, individual rewriting of RTP sequence numbers becomes quite a burden. For solutions that already cache media or perform time shifting, the rewriting should impose only a minor burden.
ライブストリームなどのランダムアクセスプロパティを欠くメディアとのRTSPセッションの場合、メディアクロックのジャンプは通常、対応する長い配信の一時停止の結果です。 RTPタイムスタンプは、一時停止された配信の期間に正比例して増加します。この場合、RTPシーケンス番号は次のパケット番号でなければならないことにも注意してください。そうでない場合、RTCPパケット損失レポートは、一時停止したポイントと後で再開するポイントの間に受信されなかったすべてのパケットを損失として示します。これにより、輻輳回避メカニズムがトリガーされる場合があります。単調に増加するRTPシーケンス番号に関する上記の推奨事項から許可される例外は、おそらく中継されているライブメディアストリームです。この場合、クライアントが配信を再開すると、現在サーバー自体に配信されているメディアが取得されます。ユニキャストを介して複数のユーザーにライブストリームを配信するこのタイプの基本的な配信では、RTPシーケンス番号の個別の書き換えが非常に負担になります。すでにメディアをキャッシュしている、またはタイムシフトを実行しているソリューションの場合、書き換えはわずかな負担にすぎません。
The goal when handling jumps in media-clock time is that the provided stream is continuous without gaps in RTP timestamp or sequence number. However, when delivery has been halted for some reason, the RTP timestamp, when resuming, MUST represent the duration that the delivery was halted. An RTP sequence number MUST generally be the next number, i.e., monotonically increasing modulo 65536. For media resources with the properties Time-Progressing and Time-Duration=0.0, the server MAY create RTP media streams with RTP sequence number jumps in them due to the client first halting delivery and later resuming it (PAUSE and then later PLAY). However, servers utilizing this exception must take into consideration the resulting RTCP receiver reports that likely contain loss reports for all the packets that were a part of the discontinuity. A client cannot rely on the fact that a server will align when resuming play, even if it is RECOMMENDED. The RTP-Info header will provide information on how the server acts in each case.
メディアクロック時間のジャンプを処理するときの目標は、提供されるストリームがRTPタイムスタンプまたはシーケンス番号のギャップなしで連続的であることです。ただし、何らかの理由で配信が停止された場合、RTPタイムスタンプは、再開時に、配信が停止された期間を表す必要があります。 RTPシーケンス番号は通常、次の番号である必要があります。つまり、65536を法として単調に増加します。プロパティTime-ProgressingおよびTime-Duration = 0.0のメディアリソースの場合、サーバーは、RTPシーケンス番号がジャンプするRTPメディアストリームを作成できますクライアントは最初に配信を停止し、後で再開します（一時停止してから後で再生します）。ただし、この例外を利用するサーバーは、不連続性の一部であったすべてのパケットの損失レポートが含まれている可能性のある結果のRTCP受信者レポートを考慮する必要があります。クライアントは、たとえそれが推奨されていても、再生を再開するときにサーバーが整列するという事実に依存することはできません。 RTP-Infoヘッダーは、各ケースでのサーバーの動作に関する情報を提供します。
One cannot assume that the RTSP client can communicate with the RTP media agent, as the two may be independent processes. If the RTP timestamp shows the same gap as the NPT, the media agent will assume that there is a pause in the presentation. If the jump in NPT is large enough, the RTP timestamp may roll over and the media agent may believe later packets to be duplicates of packets just played out. Having the RTP timestamp jump will also affect the RTCP measurements based on this.
2つは独立したプロセスである可能性があるため、RTSPクライアントがRTPメディアエージェントと通信できるとは限りません。 RTPタイムスタンプがNPTと同じギャップを示している場合、メディアエージェントはプレゼンテーションに一時停止があると想定します。 NPTのジャンプが十分に大きい場合、RTPタイムスタンプがロールオーバーし、メディアエージェントが後のパケットを、再生されたばかりのパケットの複製であると信じることがあります。 RTPタイムスタンプのジャンプがあると、これに基づくRTCP測定にも影響します。
As an example, assume an RTP timestamp frequency of 8000 Hz, a packetization interval of 100 ms, and an initial sequence number and timestamp of zero.
例として、8000 HzのRTPタイムスタンプ頻度、100 msのパケット化間隔、およびゼロの初期シーケンス番号とタイムスタンプを想定します。
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 4
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 4
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0
The ensuing RTP data stream is depicted below:
次のRTPデータストリームを以下に示します。
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
. . .
S -> C: RTP packet - seq = 49, rtptime = 39200, NPT time = 14.9s
Upon the completion of the requested delivery, the server sends a PLAY_NOTIFY.
要求された配信が完了すると、サーバーはPLAY_NOTIFYを送信します。
S->C: PLAY_NOTIFY rtsp://example.com/fizzle RTSP/2.0
CSeq: 5
Notify-Reason: end-of-stream
Request-Status: cseq=4 status=200 reason="OK"
Range: npt=-15
RTP-Info:url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=49;rtptime=39200
Session: ymIqLXufHkMHGdtENdblWK
C->S: RTSP/2.0 200 OK
CSeq: 5
User-Agent: PhonyClient/1.2
Upon the completion of the play range, the client follows up with a request to PLAY from a new NPT.
プレイ範囲が完了すると、クライアントは新しいNPTからのPLAYリクエストをフォローアップします。
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 6
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=18-20
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 6
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=18-20
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=50;rtptime=40100
The ensuing RTP data stream is depicted below:
次のRTPデータストリームを以下に示します。
S->C: RTP packet - seq = 50, rtptime = 40100, NPT time = 18s
S->C: RTP packet - seq = 51, rtptime = 40900, NPT time = 18.1s
. . .
S->C: RTP packet - seq = 69, rtptime = 55300, NPT time = 19.9s
In this example, first, NPT 10 through 15 are played, then the client requests the server to skip ahead and play NPT 18 through 20. The first segment is presented as RTP packets with sequence numbers 0 through 49 and timestamps 0 through 39,200. The second segment consists of RTP packets with sequence numbers 50 through 69, with timestamps 40,100 through 55,200. While there is a gap in the NPT, there is no gap in the sequence-number space of the RTP data stream.
この例では、最初にNPT 10〜15が再生され、次にクライアントがサーバーにスキップしてNPT 18〜20を再生するように要求します。最初のセグメントは、シーケンス番号0〜49およびタイムスタンプ0〜39,200のRTPパケットとして提示されます。 2番目のセグメントは、シーケンス番号が50〜69、タイムスタンプが40,100〜55,200のRTPパケットで構成されています。 NPTにはギャップがありますが、RTPデータストリームのシーケンス番号スペースにはギャップがありません。
The RTP timestamp gap is present in the above example due to the time it takes to perform the second play request, in this case, 12.5 ms (100/8000).
上記の例では、RTPタイムスタンプギャップは、2番目の再生要求の実行にかかる時間（この場合は12.5 ms（100/8000））が原因で存在します。
During a PAUSE/PLAY interaction in an RTSP session, the duration of time for which the RTP transmission was halted MUST be reflected in the RTP timestamp of each RTP stream. The duration can be calculated for each RTP stream as the time elapsed from when the last RTP packet was sent before the PAUSE request was received and when the first RTP packet was sent after the subsequent PLAY request was received. The duration includes all latency incurred and processing time required to complete the request.
RTSPセッションでのPAUSE / PLAY対話中、RTP送信が停止された期間は、各RTPストリームのRTPタイムスタンプに反映される必要があります。各RTPストリームの継続時間は、PAUSE要求が受信される前に最後のRTPパケットが送信されてから、次のPLAY要求が受信されてから最初のRTPパケットが送信されるまでの経過時間として計算できます。期間には、発生したすべての遅延と、リクエストを完了するために必要な処理時間が含まれます。
RFC 3550 [RFC3550] states that: "the RTP timestamp for each unit [packet] would be related to the wallclock time at which the unit becomes current on the virtual presentation timeline".
RFC 3550 [RFC3550]は次のように述べています：「各ユニット[パケット]のRTPタイムスタンプは、ユニットが仮想プレゼンテーションタイムライン上で最新になるウォールクロック時間に関連しているでしょう」。
In order to satisfy the requirements of [RFC3550], the RTP timestamp space needs to increase continuously with real time. While this is not optimal for stored media, it is required for RTP and RTCP to function as intended. Using a continuous RTP timestamp space allows the same timestamp model for both stored and live media and allows better opportunity to integrate both types of media under a single control.
[RFC3550]の要件を満たすために、RTPタイムスタンプスペースはリアルタイムで継続的に増加する必要があります。これは保存されたメディアには最適ではありませんが、RTPおよびRTCPが意図したとおりに機能するために必要です。継続的なRTPタイムスタンプスペースを使用すると、保存されているメディアとライブメディアの両方で同じタイムスタンプモデルが可能になり、単一の制御下で両方のタイプのメディアを統合する機会が増えます。
As an example, assume a clock frequency of 8000 Hz, a packetization interval of 100 ms, and an initial sequence number and timestamp of zero.
例として、8000 Hzのクロック周波数、100 msのパケット化間隔、ゼロの初期シーケンス番号とタイムスタンプを想定します。
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 4
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15
User-Agent: PhonyClient/1.2
ユーザーエージェント：PhonyClient / 1.2
S->C: RTSP/2.0 200 OK
CSeq: 4
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=0;rtptime=0
The ensuing RTP data stream is depicted below:
次のRTPデータストリームを以下に示します。
S -> C: RTP packet - seq = 0, rtptime = 0, NPT time = 10s
S -> C: RTP packet - seq = 1, rtptime = 800, NPT time = 10.1s
S -> C: RTP packet - seq = 2, rtptime = 1600, NPT time = 10.2s
S -> C: RTP packet - seq = 3, rtptime = 2400, NPT time = 10.3s
The client then sends a PAUSE request:
次に、クライアントはPAUSE要求を送信します。
C->S: PAUSE rtsp://example.com/fizzle RTSP/2.0
CSeq: 5
Session: ymIqLXufHkMHGdtENdblWK
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 5
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10.4-15
20 seconds elapse and then the client sends a PLAY request. In addition, the server requires 15 ms to process the request:
20秒が経過すると、クライアントはPLAY要求を送信します。さらに、サーバーは要求を処理するために15ミリ秒を必要とします。
C->S: PLAY rtsp://example.com/fizzle RTSP/2.0
CSeq: 6
Session: ymIqLXufHkMHGdtENdblWK
User-Agent: PhonyClient/1.2
S->C: RTSP/2.0 200 OK
CSeq: 6
Session: ymIqLXufHkMHGdtENdblWK
Range: npt=10.4-15
RTP-Info: url="rtsp://example.com/fizzle/audiotrack"
ssrc=0D12F123:seq=4;rtptime=164400
The ensuing RTP data stream is depicted below:
次のRTPデータストリームを以下に示します。
S -> C: RTP packet - seq = 4, rtptime = 164400, NPT time = 10.4s
S -> C: RTP packet - seq = 5, rtptime = 165200, NPT time = 10.5s
S -> C: RTP packet - seq = 6, rtptime = 166000, NPT time = 10.6s
First, NPT 10 through 10.3 is played, then a PAUSE is received by the server. After 20 seconds, a PLAY is received by the server that takes 15 ms to process. The duration of time for which the session was paused is reflected in the RTP timestamp of the RTP packets sent after this PLAY request.
最初に、NPT 10から10.3が再生され、次にサーバーによってPAUSEが受信されます。 20秒後、サーバーがPLAYを受信し、処理に15ミリ秒かかります。セッションが一時停止した期間は、このPLAY要求の後に送信されたRTPパケットのRTPタイムスタンプに反映されます。
A client can use the RTSP Range header and RTP-Info header to map NPT time of a presentation with the RTP timestamp.
クライアントは、RTSP RangeヘッダーとRTP-Infoヘッダーを使用して、プレゼンテーションのNPT時間をRTPタイムスタンプにマップできます。
Note: in RFC 2326 [RFC2326], this matter was not clearly defined and was misunderstood commonly. However, for RTSP 2.0, it is expected that this will be handled correctly and no exception handling will be required.
注：RFC 2326 [RFC2326]では、この問題は明確に定義されておらず、誤解されていました。ただし、RTSP 2.0の場合、これは正しく処理され、例外処理は必要ありません。
Note further: it may be required to reset some of the state to ensure the correct media decoding and the usual jitter-buffer handling when issuing a PLAY request.
さらに注意してください。PLAYリクエストを発行するときに、正しいメディアデコードと通常のジッターバッファー処理を確実にするために、一部の状態をリセットする必要がある場合があります。
For certain data types, tight integration between the RTSP layer and the RTP layer will be necessary. This by no means precludes the above restrictions. Combined RTSP/RTP media clients should use the RTP-Info field to determine whether incoming RTP packets were sent before or after a seek or before or after a PAUSE.
特定のデータタイプでは、RTSPレイヤーとRTPレイヤー間の緊密な統合が必要になります。これは、上記の制限を排除するものではありません。組み合わされたRTSP / RTPメディアクライアントは、RTP-Infoフィールドを使用して、着信RTPパケットがシークの前後に送信されたか、またはポーズの前後に送信されたかを判別する必要があります。
For scaling (see Section 18.46), RTP timestamps should correspond to the rendering timing. For example, when playing video recorded at 30 frames per second at a scale of two and speed (Section 18.50) of one, the server would drop every second frame to maintain and deliver video packets with the normal timestamp spacing of 3,000 per frame, but NPT would increase by 1/15 second for each video frame.
スケーリング（セクション18.46を参照）の場合、RTPタイムスタンプはレンダリングタイミングに対応している必要があります。たとえば、30フレーム/秒で記録されたビデオを2のスケールと速度（セクション18.50）で再生する場合、サーバーは1秒ごとのフレームをドロップして、通常のタイムスタンプ間隔がフレームあたり3,000のビデオパケットを維持および配信しますが、 NPTは、ビデオフレームごとに1/15秒ずつ増加します。
Note: the above scaling puts requirements on the media codec or a media stream to support it. For example, motion JPEG or other non-predictive video coding can easier handle the above example.
注：上記のスケーリングでは、メディアコーデックまたはメディアストリームをサポートするための要件が課されます。たとえば、モーションJPEGまたはその他の非予測的なビデオコーディングは、上記の例を簡単に処理できます。
The client can maintain a correct display of NPT by noting the RTP timestamp value of the first packet arriving after repositioning. The sequence parameter of the RTP-Info (Section 18.45) header provides the first sequence number of the next segment.
クライアントは、再配置後に到着した最初のパケットのRTPタイムスタンプ値を記録することにより、NPTの正しい表示を維持できます。 RTP-Info（セクション18.45）ヘッダーのシーケンスパラメータは、次のセグメントの最初のシーケンス番号を提供します。
For continuous audio, the server SHOULD set the RTP marker bit at the beginning of serving a new PLAY request or at jumps in timeline. This allows the client to perform playout delay adaptation.
連続オーディオの場合、サーバーは、新しいPLAY要求の処理の開始時またはタイムラインのジャンプ時にRTPマーカービットを設定する必要があります（SHOULD）。これにより、クライアントはプレイアウト遅延適応を実行できます。
Note that more than one SSRC MAY be sent in the media stream. If it happens, all sources are expected to be rendered simultaneously.
メディアストリームで複数のSSRCを送信できることに注意してください。この場合、すべてのソースが同時にレンダリングされることが予想されます。
The RTCP BYE message indicates the end of use of a given SSRC. If all sources leave an RTP session, it can, in most cases, be assumed to have ended. Therefore, a client or server MUST NOT send an RTCP BYE message until it has finished using a SSRC. A server SHOULD keep using an SSRC until the RTP session is terminated. Prolonging the use of a SSRC allows the established synchronization context associated with that SSRC to be used to synchronize subsequent PLAY requests even if the PLAY response is late.
RTCP BYEメッセージは、特定のSSRCの使用の終了を示します。すべてのソースがRTPセッションを離れると、ほとんどの場合、RTPセッションは終了したと見なされます。したがって、クライアントまたはサーバーは、SSRCの使用が完了するまでRTCP BYEメッセージを送信してはなりません（MUST NOT）。サーバーは、RTPセッションが終了するまでSSRCを使用し続ける必要があります（SHOULD）。 SSRCの使用を延長すると、そのSSRCに関連付けられた確立済みの同期コンテキストを使用して、PLAY応答が遅れた場合でも後続のPLAY要求を同期できます。
An SSRC collision with the SSRC that transmits media does also have consequences, as it will normally force the media sender to change its SSRC in accordance with the RTP specification [RFC3550]. However, an RTSP server may wait and see if the client changes and thus resolve the conflict to minimize the impact. As media sender, SSRC change will result in a loss of synchronization context and require any receiver to wait for RTCP sender reports for all media requiring synchronization before being able to play out synchronized. Due to these reasons, a client joining a session should take care not to select the same SSRC(s) as the server indicates in the ssrc Transport header parameter. Any SSRC signaled in the Transport header MUST be avoided. A client detecting a collision prior to sending any RTP or RTCP messages SHALL also select a new SSRC.
メディアを送信するSSRCとのSSRC衝突も結果をもたらします。これは、通常、RTP仕様[RFC3550]に従ってメディア送信者にSSRCの変更を強制するためです。ただし、RTSPサーバーは待機して、クライアントが変更されるかどうかを確認し、影響を最小限に抑えるために競合を解決します。メディア送信者として、SSRCの変更により同期コンテキストが失われ、受信者は同期を必要とするすべてのメディアのRTCP送信者レポートを待ってから同期を再生できます。これらの理由により、セッションに参加するクライアントは、サーバーがssrcトランスポートヘッダーパラメーターで示すのと同じSSRCを選択しないように注意する必要があります。トランスポートヘッダーで通知されたSSRCは回避する必要があります。 RTPまたはRTCPメッセージを送信する前に衝突を検出したクライアントも、新しいSSRCを選択する必要があります（SHALL）。
It is the intention that any future protocol or profile regarding media delivery and lower transport should be easy to add to RTSP. This section provides the necessary steps that need to be met.
メディア配信および低トランスポートに関する将来のプロトコルまたはプロファイルは、RTSPに簡単に追加できるはずです。このセクションでは、満たす必要のある必要な手順を示します。
The following things need to be considered when adding a new protocol or profile for use with RTSP:
RTSPで使用する新しいプロトコルまたはプロファイルを追加するときは、次の点を考慮する必要があります。
o The protocol or profile needs to define a name tag representing it. This tag is required to be an ABNF "token" to be possible to use in the Transport header specification.
o プロトコルまたはプロファイルは、それを表す名前タグを定義する必要があります。このタグは、トランスポートヘッダー仕様で使用できるように、ABNF「トークン」である必要があります。
o The useful combinations of protocol, profiles, and lower-layer transport for this extension need to be defined. For each combination, declare the necessary parameters to use in the Transport header.
o この拡張機能のプロトコル、プロファイル、および下位層トランスポートの便利な組み合わせを定義する必要があります。組み合わせごとに、トランスポートヘッダーで使用する必要なパラメーターを宣言します。
o For new media protocols, the interaction with RTSP needs to be addressed. One important factor will be the media synchronization. It may be necessary to have new headers similar to RTP info to carry this information.
o 新しいメディアプロトコルの場合、RTSPとの相互作用に対処する必要があります。重要な要素の1つは、メディアの同期です。この情報を伝えるために、RTP情報と同様の新しいヘッダーが必要になる場合があります。
o Discussion needs to occur regarding congestion control for media, especially if transport without built-in congestion control is used.
o 特に輻輳制御が組み込まれていないトランスポートが使用される場合、メディアの輻輳制御に関して議論する必要があります。
See the IANA Considerations section (Section 22) for information on how to register new attributes.
新しい属性を登録する方法については、IANAの考慮事項セクション（セクション22）を参照してください。
The Session Description Protocol (SDP, [RFC4566]) may be used to describe streams or presentations in RTSP. This description is typically returned in reply to a DESCRIBE request on a URI from a server to a client or received via HTTP from a server to a client.
セッション記述プロトコル（SDP、[RFC4566]）は、RTSPでストリームまたはプレゼンテーションを記述するために使用できます。この説明は、通常、サーバーからクライアントへのURIに対するDESCRIBE要求への応答で返されるか、サーバーからクライアントへHTTP経由で受信されます。
This appendix describes how an SDP file determines the operation of an RTSP session. Thus, it is worth pointing out that the interpretation of the SDP is done in the context of the SDP receiver, which is the one being configured. This is the same as in SAP [RFC2974]; this differs from SDP Offer/Answer [RFC3264] where each SDP is interpreted in the context of the agent providing it.
この付録では、SDPファイルがRTSPセッションの動作を決定する方法について説明します。したがって、SDPの解釈は、構成されているSDPレシーバーのコンテキストで行われることを指摘する価値があります。これはSAP [RFC2974]と同じです。これは、各SDPがそれを提供するエージェントのコンテキストで解釈されるSDP Offer / Answer [RFC3264]とは異なります。
SDP as is provides no mechanism by which a client can distinguish, without human guidance, between several media streams to be rendered simultaneously and a set of alternatives (e.g., two audio streams spoken in different languages). The SDP extension found in "The Session Description Protocol (SDP) Grouping Framework" [RFC5888] provides such functionality to some degree. Appendix D.4 describes the usage of SDP media line grouping for RTSP.
SDPは現状のままでは、クライアントが人間の指導なしに、同時にレンダリングされる複数のメディアストリームと代替のセット（たとえば、異なる言語で話される2つのオーディオストリーム）を区別できるメカニズムを提供していません。 「セッション記述プロトコル（SDP）グループ化フレームワーク」[RFC5888]にあるSDP拡張機能は、このような機能をある程度提供します。付録D.4では、RTSPのSDPメディアライングループの使用法について説明します。
The terms "session-level", "media-level", and other key/attribute names and values used in this appendix are to be used as defined in SDP [RFC4566]:
この付録で使用されている「セッションレベル」、「メディアレベル」、およびその他のキー/属性の名前と値は、SDP [RFC4566]で定義されているとおりに使用されます。
The "a=control" attribute is used to convey the control URI. This attribute is used both for the session and media descriptions. If used for individual media, it indicates the URI to be used for controlling that particular media stream. If found at the session level, the attribute indicates the URI for aggregate control (presentation URI). The session-level URI MUST be different from any media-level URI. The presence of a session-level control attribute MUST be interpreted as support for aggregated control. The control attribute MUST be present on the media level unless the presentation only contains a single media stream; in which case, the attribute MAY be present on the session level only and then also apply to that single media stream.
「a = control」属性は、コントロールURIを伝えるために使用されます。この属性は、セッションとメディアの説明の両方に使用されます。個々のメディアに使用する場合は、その特定のメディアストリームを制御するために使用するURIを示します。セッションレベルで見つかった場合、属性は集約コントロールのURI（プレゼンテーションURI）を示します。セッションレベルのURIは、メディアレベルのURIとは異なる必要があります。セッションレベルの制御属性の存在は、集約された制御のサポートとして解釈されなければなりません（MUST）。プレゼンテーションに単一のメディアストリームしか含まれていない場合を除き、コントロール属性はメディアレベルに存在する必要があります。この場合、属性はセッションレベルにのみ存在し、その単一のメディアストリームにも適用される場合があります。
ABNF for the attribute is defined in Section 20.3.
属性のABNFはセクション20.3で定義されています。
Example:
例：
a=control:rtsp://example.com/foo
This attribute MAY contain either relative or absolute URIs, following the rules and conventions set out in RFC 3986 [RFC3986]. Implementations MUST look for a base URI in the following order:
この属性には、RFC 3986 [RFC3986]で規定されている規則と規則に従って、相対URIまたは絶対URIを含めることができます（MAY）。実装は、次の順序でベースURIを探す必要があります。
1. the RTSP Content-Base field;
1. RTSP Content-Baseフィールド。
2. the RTSP Content-Location field;
2. RTSP Content-Locationフィールド。
3. the RTSP Request-URI.
3. RTSPリクエストURI。
If this attribute contains only an asterisk (*), then the URI MUST be treated as if it were an empty embedded URI; thus, it will inherit the entire base URI.
この属性にアスタリスク（*）のみが含まれる場合、URIは空の埋め込みURIであるかのように処理する必要があります。したがって、ベースURI全体を継承します。
Note: RFC 2326 was very unclear on the processing of relative URIs and several RTSP 1.0 implementations at the point of publishing this document did not perform RFC 3986 processing to determine the resulting URI; instead, simple concatenation is common. To avoid this issue completely, it is recommended to use absolute URIs in the SDP.
注：RFC 2326は相対URIの処理について非常に不明確であり、このドキュメントの公開時点でのいくつかのRTSP 1.0実装は、結果のURIを決定するためのRFC 3986処理を実行しませんでした。代わりに、単純な連結が一般的です。この問題を完全に回避するには、SDPで絶対URIを使用することをお勧めします。
The URI handling for SDPs from container files needs special consideration. For example, let's assume that a container file has the URI: "rtsp://example.com/container.mp4". Let's further assume this URI is the base URI and that there is an absolute media-level URI: "rtsp://example.com/container.mp4/trackID=2". A relative media-level URI that resolves in accordance with RFC 3986 [RFC3986] to the above given media URI is "container.mp4/trackID=2". It is usually not desirable to need to include or modify the SDP stored within the container file with the server local name of the container file. To avoid this, one can modify the base URI used to include a trailing slash, e.g., "rtsp://example.com/container.mp4/". In this case, the relative URI for the media will only need to be "trackID=2". However, this will also mean that using "*" in the SDP will result in the control URI including the trailing slash, i.e., "rtsp://example.com/container.mp4/".
コンテナファイルからのSDPのURI処理には、特別な考慮が必要です。たとえば、コンテナファイルのURIが「rtsp：//example.com/container.mp4」であるとします。さらに、このURIがベースURIであり、絶対的なメディアレベルのURI "rtsp：//example.com/container.mp4/trackID=2"があると仮定しましょう。 RFC 3986 [RFC3986]に従って上記のメディアURIに解決される相対的なメディアレベルのURIは、「container.mp4 / trackID = 2」です。通常、コンテナーファイル内に格納されているSDPを、コンテナーファイルのサーバーローカル名で含めるか変更する必要はありません。これを回避するには、末尾にスラッシュを含めるために使用されるベースURIを変更します（例：「rtsp：//example.com/container.mp4/」）。この場合、メディアの相対URIは「trackID = 2」のみである必要があります。ただし、これは、SDPで「*」を使用すると、末尾のスラッシュを含むコントロールURI（つまり、「rtsp：//example.com/container.mp4/」）になることも意味します。
Note: the usage of TrackID in the above is not a standardized form, but one example out of several similar strings such as TrackID, Track_ID, StreamID that is used by different server vendors to indicate a particular piece of media inside a container file.
注：上記のTrackIDの使用は標準化された形式ではなく、コンテナファイル内の特定のメディアを示すためにさまざまなサーバーベンダーによって使用されるTrackID、Track_ID、StreamIDなどのいくつかの類似した文字列の1つの例です。
The "m=" field is used to enumerate the streams. It is expected that all the specified streams will be rendered with appropriate synchronization. If the session is over multicast, the port number indicated SHOULD be used for reception. The client MAY try to override the destination port, through the Transport header. The servers MAY allow this: the response will indicate whether or not this is allowed. If the session is unicast, the port numbers are the ones RECOMMENDED by the server to the client, about which receiver ports to use; the client MUST still include its receiver ports in its SETUP request. The client MAY ignore this recommendation. If the server has no preference, it SHOULD set the port number value to zero.
「m =」フィールドは、ストリームを列挙するために使用されます。指定されたすべてのストリームが適切な同期でレンダリングされることが期待されています。セッションがマルチキャストを介している場合、示されたポート番号を受信に使用する必要があります（SHOULD）。クライアントは、トランスポートヘッダーを通じて宛先ポートをオーバーライドしようとする場合があります。サーバーはこれを許可することができます：応答はこれが許可されるかどうかを示します。セッションがユニキャストの場合、ポート番号は、サーバーがクライアントに推奨するものであり、どのレシーバーポートを使用するかについてです。クライアントはそのSETUPリクエストにレシーバーポートを含める必要があります。クライアントはこの推奨事項を無視してもよい（MAY）。サーバーに優先順位がない場合は、ポート番号の値をゼロに設定する必要があります（SHOULD）。
The "m=" lines contain information about which transport protocol, profile, and possibly lower-layer are to be used for the media stream. The combination of transport, profile, and lower layer, like RTP/AVP/UDP, needs to be defined for how to be used with RTSP. The currently defined combinations are discussed in Appendix C; further combinations MAY be specified.
"m ="行には、メディアストリームに使用されるトランスポートプロトコル、プロファイル、および場合によっては下位層に関する情報が含まれています。トランスポート、プロファイル、およびRTP / AVP / UDPのような下位層の組み合わせは、RTSPでどのように使用するかを定義する必要があります。現在定義されている組み合わせについては、付録Cで説明します。さらに組み合わせを指定してもよい（MAY）。
Example:
例：
m=audio 0 RTP/AVP 31
m =オーディオ0 RTP / AVP 31
The payload type or types are specified in the "m=" line. In case the payload type is a static payload type from RFC 3551 [RFC3551], no other information may be required. In case it is a dynamic payload type, the media attribute "rtpmap" is used to specify what the media is. The "encoding name" within the "rtpmap" attribute may be one of those specified in [RFC4856], a media type registered with IANA according to [RFC4855], or an experimental encoding as specified in SDP [RFC4566]). Codec-specific parameters are not specified in this field, but rather in the "fmtp" attribute described below.
ペイロードタイプは、「m =」行で指定されます。ペイロードタイプがRFC 3551 [RFC3551]の静的ペイロードタイプである場合、他の情報は必要ありません。ダイナミックペイロードタイプの場合、メディア属性「rtpmap」を使用して、メディアを指定します。 「rtpmap」属性内の「エンコーディング名」は、[RFC4856]で指定されたもの、[RFC4855]に従ってIANAに登録されたメディアタイプ、またはSDP [RFC4566]で指定された実験的なエンコーディングです。コーデック固有のパラメータは、このフィールドではなく、以下で説明する「fmtp」属性で指定されます。
The selection of the RTP payload type numbers used may be required to consider RTP and RTCP Multiplexing [RFC5761], if that is to be supported by the server.
使用されるRTPペイロードタイプ番号の選択は、RTPおよびRTCP多重化[RFC5761]を考慮する必要がある場合があります（サーバーでサポートされる場合）。
Format-specific parameters are conveyed using the "fmtp" media attribute. The syntax of the "fmtp" attribute is specific to the encoding(s) to which the attribute refers. Note that some of the format-specific parameters may be specified outside of the "fmtp" parameters, for example, like the "ptime" attribute for most audio encodings.
フォーマット固有のパラメータは、「fmtp」メディア属性を使用して伝達されます。 「fmtp」属性の構文は、属性が参照するエンコーディングに固有です。たとえば、ほとんどのオーディオエンコーディングの「ptime」属性のように、一部のフォーマット固有のパラメーターは「fmtp」パラメーターの外で指定される場合があります。
The SDP attributes "a=sendrecv", "a=recvonly", and "a=sendonly" provide instructions about the direction the media streams flow within a session. When using RTSP, the SDP can be delivered to a client using either RTSP DESCRIBE or a number of RTSP external methods, like HTTP, FTP, and email. Based on this, the SDP applies to how the RTSP client will see the complete session. Thus, media streams delivered from the RTSP server to the client would be given the "a=recvonly" attribute.
SDP属性「a = sendrecv」、「a = recvonly」、および「a = sendonly」は、セッション内のメディアストリームの流れ方向に関する指示を提供します。 RTSPを使用する場合、RTSP DESCRIBEまたはHTTP、FTP、電子メールなどのいくつかのRTSP外部メソッドを使用して、SDPをクライアントに配信できます。これに基づいて、SDPはRTSPクライアントが完全なセッションを見る方法に適用されます。したがって、RTSPサーバーからクライアントに配信されるメディアストリームには、「a = recvonly」属性が付与されます。
"a=recvonly" in an SDP provided to the RTSP client indicates that media delivery will only occur in the direction from the RTSP server to the client. SDP provided to the RTSP client that lacks any of the directionality attributes ("a=recvonly", "a=sendonly", "a=sendrecv") would be interpreted as having "a=sendrecv". At the time of writing, there exists no RTSP mode suitable for media traffic in the direction from the RTSP client to the server. Thus, all RTSP SDP SHOULD have an "a=recvonly" attribute when using the PLAY mode defined in this document. If future modes are defined for media in the client-to-server direction, then usage of "a=sendonly" or "a=sendrecv" may become suitable to indicate intended media directions.
RTSPクライアントに提供されるSDPの「a = recvonly」は、メディア配信がRTSPサーバーからクライアントへの方向でのみ行われることを示します。方向性属性（「a = recvonly」、「a = sendonly」、「a = sendrecv」）のいずれも欠けているRTSPクライアントに提供されたSDPは、「a = sendrecv」を持つと解釈されます。執筆時点では、RTSPクライアントからサーバーへの方向のメディアトラフィックに適したRTSPモードはありません。したがって、このドキュメントで定義されているPLAYモードを使用する場合、すべてのRTSP SDPに「a = recvonly」属性が必要です。メディアに対してクライアントからサーバーへの方向で将来のモードが定義されている場合、「a = sendonly」または「a = sendrecv」の使用が意図されたメディアの方向を示すのに適している可能性があります。
The "a=range" attribute defines the total time range of the stored session or an individual media. Live sessions that are not seekable can be indicated as specified below; whereas the length of live sessions can be deduced from the "t=" and "r=" SDP parameters.
「a = range」属性は、保存されたセッションまたは個々のメディアの合計時間範囲を定義します。シークできないライブセッションは、以下のように示すことができます。一方、ライブセッションの長さは、 "t ="および "r =" SDPパラメータから推定できます。
The attribute is both a session- and a media-level attribute. For presentations that contain media streams of the same duration, the range attribute SHOULD only be used at the session level. In case of different lengths, the range attribute MUST be given at media level for all media and SHOULD NOT be given at the session level. If the attribute is present at both media level and session level, the media-level values MUST be used.
この属性は、セッションレベルとメディアレベルの両方の属性です。同じ期間のメディアストリームを含むプレゼンテーションの場合、範囲属性はセッションレベルでのみ使用する必要があります（SHOULD）。長さが異なる場合、範囲属性はすべてのメディアのメディアレベルで指定する必要があり、セッションレベルでは指定しないでください。属性がメディアレベルとセッションレベルの両方に存在する場合は、メディアレベルの値を使用する必要があります。
Note: usually one will specify the same length for all media, even if there isn't media available for the full duration on all media. However, that requires that the server accept PLAY requests within that range.
注：通常、すべてのメディアで全期間利用可能なメディアがない場合でも、すべてのメディアに同じ長さを指定します。ただし、そのためには、サーバーがその範囲内のPLAY要求を受け入れる必要があります。
Servers MUST take care to provide RTSP Range (see Section 18.40) values that are consistent with what is presented in the SDP for the content. There is no reason for non dynamic content, like media clips provided on demand to have inconsistent values. Inconsistent values between the SDP and the actual values for the content handled by the server is likely to generate some failure, like 457 "Invalid Range", in case the client uses PLAY requests with a Range header. In case the content is dynamic in length and it is infeasible to provide a correct value in the SDP, the server is recommended to describe this as content that is not seekable (see below). The server MAY override that property in the response to a PLAY request using the correct values in the Range header.
サーバーは、コンテンツのSDPで提示されているものと一致するRTSP範囲（セクション18.40を参照）の値を提供するように注意する必要があります。オンデマンドで提供されるメディアクリップのように、値が一貫していないなど、動的でないコンテンツが存在する理由はありません。 SDPとサーバーが処理するコンテンツの実際の値との間に一貫性のない値があると、クライアントが範囲ヘッダーを指定したPLAYリクエストを使用した場合、457「無効な範囲」などのエラーが発生する可能性があります。コンテンツの長さが動的であり、SDPで正しい値を提供することが不可能である場合、サーバーはこれをシークできないコンテンツとして記述することをお勧めします（以下を参照）。サーバーは、範囲ヘッダーの正しい値を使用して、PLAY要求への応答でそのプロパティをオーバーライドできます。
The unit is specified first, followed by the value range. The units and their values are as defined in Section 4.4.1, Section 4.4.2, and Section 4.4.3 and MAY be extended with further formats. Any open-ended range (start-), i.e., without stop range, is of unspecified duration and MUST be considered as content that is not seekable unless this property is overridden. Multiple instances carrying different clock formats MAY be included at either session or media level.
単位が最初に指定され、その後に値の範囲が続きます。単位とその値は、セクション4.4.1、セクション4.4.2、セクション4.4.3で定義されているとおりであり、さらにフォーマットを拡張できます。オープンエンドの範囲（start-）、つまりストップレンジのない期間は指定されておらず、このプロパティがオーバーライドされない限りシークできないコンテンツと見なす必要があります。異なるクロックフォーマットを伝送する複数のインスタンスは、セッションレベルまたはメディアレベルで含めることができます。
ABNF for the attribute is defined in Section 20.3.
属性のABNFはセクション20.3で定義されています。
Examples:
例：
a=range:npt=0-34.4368
a=range:clock=19971113T211503Z-19971113T220300Z
Non-seekable stream of unknown duration:
a=range:npt=0-
The "t=" field defines when the SDP is valid. For on-demand content, the server SHOULD indicate a stop time value for which it guarantees the description to be valid and a start time that is equal to or before the time at which the DESCRIBE request was received. It MAY also indicate start and stop times of 0, meaning that the session is always available.
「t =」フィールドは、SDPがいつ有効になるかを定義します。オンデマンドコンテンツの場合、サーバーは、説明が有効であることを保証する停止時間の値と、DESCRIBE要求が受信された時間と同じかそれより前の開始時間を示す必要があります（SHOULD）。また、開始時刻と終了時刻が0であることを示す場合があります。つまり、セッションは常に利用可能です。
For sessions that are of live type, i.e., specific start time, unknown stop time, likely not seekable, the "t=" and "r=" field SHOULD be used to indicate the start time of the event. The stop time SHOULD be given so that the live event will have ended at that time, while still not being unnecessary far into the future.
特定の開始時間、不明な停止時間など、ライブタイプのセッションの場合、シークできない可能性があるため、「t =」および「r =」フィールドを使用して、イベントの開始時間を示す必要があります（SHOULD）。停止時間は、ライブイベントがその時点で終了するように指定する必要があります。
In SDP used with RTSP, the "c=" field contains the destination address for the media stream. If a multicast address is specified, the client SHOULD use this address in any SETUP request as destination address, including any additional parameters, such as TTL. For on-demand unicast streams and some multicast streams, the destination address MAY be specified by the client via the SETUP request, thus overriding any specified address. To identify streams without a fixed destination address, where the client is required to specify a destination address, the "c=" field SHOULD be set to a null value. For addresses of type "IP4", this value MUST be "0.0.0.0"; and for type "IP6", this value MUST be "0:0:0:0:0:0:0:0" (can also be written as "::"), i.e., the unspecified address according to RFC 4291 [RFC4291].
RTSPで使用されるSDPでは、「c =」フィールドにメディアストリームの宛先アドレスが含まれます。マルチキャストアドレスが指定されている場合、クライアントは、TTLなどの追加パラメーターを含め、このアドレスを任意のSETUP要求で宛先アドレスとして使用する必要があります。オンデマンドのユニキャストストリームと一部のマルチキャストストリームの場合、宛先アドレスはSETUP要求を介してクライアントによって指定される場合があり、指定されたアドレスを上書きします。クライアントが宛先アドレスを指定する必要がある固定宛先アドレスのないストリームを識別するには、「c =」フィールドをnull値に設定する必要があります（SHOULD）。タイプ「IP4」のアドレスの場合、この値は「0.0.0.0」でなければなりません。タイプ「IP6」の場合、この値は「0：0：0：0：0：0：0：0」でなければなりません（「::」と表記することもできます）。つまり、RFC 4291 [ RFC4291]。
The optional "a=mtag" attribute identifies a version of the session description. It is opaque to the client. SETUP requests may include this identifier in the If-Match field (see Section 18.24) to allow session establishment only if this attribute value still corresponds to that of the current description. The attribute value is opaque and may contain any character allowed within SDP attribute values.
オプションの "a = mtag"属性は、セッション記述のバージョンを識別します。クライアントには不透明です。 SETUPリクエストでは、この属性値が現在の説明の属性値にまだ対応している場合にのみセッションを確立できるように、この識別子をIf-Matchフィールド（セクション18.24を参照）に含めることができます。属性値は不透明で、SDP属性値内で許可されている任意の文字を含めることができます。
ABNF for the attribute is defined in Section 20.3.
属性のABNFはセクション20.3で定義されています。
Example:
例：
a=mtag:"158bb3e7c7fd62ce67f12b533f06b83a"
a = mtag： "158bb3e7c7fd62ce67f12b533f06b83a"
One could argue that the "o=" field provides identical functionality. However, it does so in a manner that would put constraints on servers that need to support multiple session description types other than SDP for the same piece of media content.
「o =」フィールドは同じ機能を提供すると主張することができます。ただし、同じメディアコンテンツのSDP以外の複数のセッション記述タイプをサポートする必要があるサーバーに制約を課すような方法でそうします。
If a presentation does not support aggregate control, no session-level "a=control" attribute is specified. For an SDP with multiple media sections specified, each section will have its own control URI specified via the "a=control" attribute.
プレゼンテーションが集約コントロールをサポートしない場合、セッションレベルの「a = control」属性は指定されません。複数のメディアセクションが指定されたSDPの場合、各セクションには、「a = control」属性で指定された独自のコントロールURIがあります。
Example:
例：
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.56
s=I came from a web page
e=adm@example.com
c=IN IP4 0.0.0.0
t=0 0
m=video 8002 RTP/AVP 31
a=control:rtsp://audio.example.com/movie.aud
m=audio 8004 RTP/AVP 3
a=control:rtsp://video.example.com/movie.vid
Note that the position of the control URI in the description implies that the client establishes separate RTSP control sessions to the servers audio.example.com and video.example.com.
説明内のコントロールURIの位置は、クライアントがサーバーaudio.example.comおよびvideo.example.comへの個別のRTSPコントロールセッションを確立することを意味することに注意してください。
It is recommended that an SDP file contain the complete media-initialization information even if it is delivered to the media client through non-RTSP means. This is necessary as there is no mechanism to indicate that the client should request more detailed media stream information via DESCRIBE.
RTSP以外の方法でメディアクライアントに配信された場合でも、SDPファイルには完全なメディア初期化情報を含めることをお勧めします。クライアントがDESCRIBEを介してより詳細なメディアストリーム情報をリクエストする必要があることを示すメカニズムがないため、これは必要です。
In this scenario, the server has multiple streams that can be controlled as a whole. In this case, there are both a media-level "a=control" attribute, which is used to specify the stream URIs, and a session-level "a=control" attribute, which is used as the Request-URI for aggregate control. If the media-level URI is relative, it is resolved to absolute URIs according to Appendix D.1.1 above.
このシナリオでは、サーバーには、全体として制御できる複数のストリームがあります。この場合、ストリームURIを指定するために使用されるメディアレベルの「a = control」属性と、集約コントロールのRequest-URIとして使用されるセッションレベルの「a = control」属性の両方があります。 。メディアレベルのURIが相対である場合、上記の付録D.1.1に従って絶対URIに解決されます。
Example:
例：
C->M: DESCRIBE rtsp://example.com/movie RTSP/2.0
CSeq: 1
User-Agent: PhonyClient/1.2
M->C: RTSP/2.0 200 OK
CSeq: 1
Date: Wed, 23 Jan 2013 15:36:52 +0000
Expires: Wed, 23 Jan 2013 16:36:52 +0000
Content-Type: application/sdp
Content-Base: rtsp://example.com/movie/
Content-Length: 227
v=0
o=- 2890844256 2890842807 IN IP4 192.0.2.211
s=I contain
i=<more info>
e=adm@example.com
c=IN IP4 0.0.0.0
a=control:*
t=0 0
m=video 8002 RTP/AVP 31
a=control:trackID=1
m=audio 8004 RTP/AVP 3
a=control:trackID=2
In this example, the client is recommended to establish a single RTSP session to the server, and it uses the URIs rtsp://example.com/movie/ trackID=1 and rtsp://example.com/movie/trackID=2 to set up the video and audio streams, respectively. The URI rtsp://example.com/movie/, which is resolved from the "*", controls the whole presentation (movie).
この例では、クライアントはサーバーへの単一のRTSPセッションを確立することが推奨され、rtsp：//example.com/movie/ trackID = 1およびrtsp：//example.com/movie/trackID=2のURIを使用します。ビデオとオーディオのストリームをそれぞれ設定します。 「*」から解決されるURI rtsp：//example.com/movie/は、プレゼンテーション（映画）全体を制御します。
A client is not required to issue SETUP requests for all streams within an aggregate object. Servers should allow the client to ask for only a subset of the streams.
クライアントは、集合オブジェクト内のすべてのストリームに対してSETUP要求を発行する必要はありません。サーバーは、クライアントがストリームのサブセットのみを要求できるようにする必要があります。
For some types of media, it is desirable to express a relationship between various media components, for instance, for lip synchronization or Scalable Video Codec (SVC) [RFC5583]. This relationship is expressed on the SDP level by grouping of media lines, as described in [RFC5888], and can be exposed to RTSP.
一部のタイプのメディアでは、たとえば、リップ同期やスケーラブルビデオコーデック（SVC）[RFC5583]など、さまざまなメディアコンポーネント間の関係を表現することが望ましいです。この関係は、[RFC5888]で説明されているように、メディアラインのグループ化によってSDPレベルで表され、RTSPに公開できます。
For RTSP, it is mainly important to know how to handle grouped media received by means of SDP, i.e., if the media are under aggregate control (see Appendix D.3) or if aggregate control is not available (see Appendix D.2).
RTSPの場合、主にSDPによって受信されたグループ化されたメディアの処理方法を知ることが重要です。つまり、メディアが集約制御されているか（付録D.3を参照）、集約制御が利用できない場合（付録D.2を参照） 。
It is RECOMMENDED that grouped media are handled by aggregate control, to give the client the ability to control either the whole presentation or single media.
クライアントがプレゼンテーション全体または単一のメディアのいずれかを制御できるようにするために、グループ化されたメディアは集約制御によって処理されることをお勧めします。
There are some considerations that need to be made when the session description is delivered to the client outside of RTSP, for example via HTTP or email.
セッションの説明がHTTPや電子メールなどを介してRTSPの外部のクライアントに配信される場合、いくつかの考慮事項があります。
First of all, the SDP needs to contain absolute URIs, since relative will, in most cases, not work as the delivery will not correctly forward the base URI.
第一に、SDPには絶対URIを含める必要があります。相対は、配信がベースURIを正しく転送しないため、ほとんどの場合、機能しないためです。
The writing of the SDP session availability information, i.e., "t=" and "r=", needs to be carefully considered. When the SDP is fetched by the DESCRIBE method, the probability that it is valid is very high. However, the same is much less certain for SDPs distributed using other methods. Therefore, the publisher of the SDP should take care to follow the recommendations about availability in the SDP specification [RFC4566] in Section 4.2.
SDPセッションの可用性情報、つまり "t ="と "r ="の書き込みは慎重に検討する必要があります。 SDPがDESCRIBEメソッドによってフェッチされる場合、それが有効である確率は非常に高くなります。ただし、他の方法を使用して配布されたSDPの場合、これはそれほど確実ではありません。したがって、SDPの発行者は、セクション4.2のSDP仕様[RFC4566]の可用性に関する推奨事項に従うように注意する必要があります。
This appendix describes the most important and considered use cases for RTSP. They are listed in descending order of importance in regard to ensuring that all necessary functionality is present. This specification only fully supports usage of the two first. Also, in these first two cases, there are special cases or exceptions that are not supported without extensions, e.g., the redirection of media delivery to an address other than the controlling agent's (client's).
この付録では、RTSPの最も重要で考慮されている使用例について説明します。これらは、必要なすべての機能が確実に存在するように、重要度の高い順にリストされています。この仕様では、最初に2つの使用法のみを完全にサポートしています。また、これらの最初の2つのケースでは、拡張機能なしではサポートされない特別なケースまたは例外があります。たとえば、制御エージェント（クライアント）以外のアドレスへのメディア配信のリダイレクトなどです。
An RTSP-capable server stores content suitable for being streamed to a client. A client desiring playback of any of the stored content uses RTSP to set up the media transport required to deliver the desired content. RTSP is then used to initiate, halt, and manipulate the actual transmission (playout) of the content. RTSP is also required to provide the necessary description and synchronization information for the content.
RTSP対応サーバーは、クライアントへのストリーミングに適したコンテンツを保存します。保存されたコンテンツの再生を希望するクライアントは、RTSPを使用して、目的のコンテンツを配信するために必要なメディアトランスポートを設定します。次に、RTSPを使用して、コンテンツの実際の送信（プレイアウト）を開始、停止、および操作します。 RTSPは、コンテンツに必要な説明と同期情報を提供するためにも必要です。
The above high-level description can be broken down into a number of functions of which RTSP needs to be capable.
上記の高レベルの説明は、RTSPが機能する必要があるいくつかの機能に分解できます。
Presentation Description: Provide initialization information about the presentation (content); for example, which media codecs are needed for the content. Other information that is important includes the number of media streams the presentation contains, the transport protocols used for the media streams, and identifiers for these media streams. This information is required before setup of the content is possible and to determine if the client is even capable of using the content.
プレゼンテーションの説明：プレゼンテーション（コンテンツ）に関する初期化情報を提供します。たとえば、コンテンツに必要なメディアコーデック。その他の重要な情報には、プレゼンテーションに含まれるメディアストリームの数、メディアストリームに使用されるトランスポートプロトコル、これらのメディアストリームの識別子などがあります。この情報は、コンテンツのセットアップが可能になる前に、クライアントがコンテンツを使用できるかどうかを判断するために必要です。
This information need not be sent using RTSP; other external protocols can be used to transmit the transport presentation descriptions. Two good examples are the use of HTTP [RFC7230] or email to fetch or receive presentation descriptions like SDP [RFC4566]
この情報はRTSPを使用して送信する必要はありません。他の外部プロトコルを使用して、トランスポートプレゼンテーションの説明を送信できます。 2つの良い例は、SDP [RFC4566]などのプレゼンテーションの説明を取得または受信するためのHTTP [RFC7230]または電子メールの使用です。
Setup: Set up some or all of the media streams in a presentation. The setup itself consists of selecting the protocol for media transport and the necessary parameters for the protocol, like addresses and ports.
セットアップ：プレゼンテーションのメディアストリームの一部またはすべてをセットアップします。セットアップ自体は、メディアトランスポート用のプロトコルの選択と、アドレスやポートなど、プロトコルに必要なパラメータの選択で構成されます。
Control of Transmission: After the necessary media streams have been established, the client can request the server to start transmitting the content. The client must be allowed to start or stop the transmission of the content at arbitrary times. The client must also be able to start the transmission at any point in the timeline of the presentation.
送信の制御：必要なメディアストリームが確立された後、クライアントはサーバーにコンテンツの送信を開始するよう要求できます。クライアントは、コンテンツの送信を任意のタイミングで開始または停止できるようにする必要があります。クライアントは、プレゼンテーションのタイムラインのどの時点でも送信を開始できる必要があります。
Synchronization: For media-transport protocols like RTP [RFC3550], it might be beneficial to carry synchronization information within RTSP. This may be due to either the lack of inter-media synchronization within the protocol itself or the potential delay before the synchronization is established (which is the case for RTP when using RTCP).
同期：RTP [RFC3550]などのメディアトランスポートプロトコルの場合、RTSP内で同期情報を伝送すると有益な場合があります。これは、プロトコル自体の内部メディア同期の欠如、または同期が確立される前の潜在的な遅延（RTPを使用する場合のRTPの場合）が原因である可能性があります。
Termination: Terminate the established contexts.
終了：確立されたコンテキストを終了します。
For this use case, there are a number of assumptions about how it works. These are:
この使用例では、それがどのように機能するかについて多くの仮定があります。これらは：
On-Demand content: The content is stored at the server and can be accessed at any time during a time period when it is intended to be available.
オンデマンドコンテンツ：コンテンツはサーバーに保存され、利用可能である期間中はいつでもアクセスできます。
Independent sessions: A server is capable of serving a number of clients simultaneously, including from the same piece of content at different points in that presentations timeline.
独立したセッション：サーバーは、プレゼンテーションのタイムラインの異なるポイントにある同じコンテンツからなど、多数のクライアントに同時にサービスを提供できます。
Unicast Transport: Content for each individual client is transmitted to them using unicast traffic.
ユニキャストトランスポート：個々のクライアントのコンテンツは、ユニキャストトラフィックを使用してクライアントに送信されます。
It is also possible to redirect the media traffic to a different destination than that of the agent controlling the traffic. However, allowing this without appropriate mechanisms for checking that the destination approves of this allows for Distributed DoS (DDoS).
メディアトラフィックを、トラフィックを制御するエージェントの宛先とは異なる宛先にリダイレクトすることもできます。ただし、適切なメカニズムなしでこれを許可すると、宛先がこれを承認することを確認して、分散DoS（DDoS）が許可されることを確認できます。
This use case is similar to the above on-demand content case (see Appendix E.1), the difference is the nature of the content itself. Live content is continuously distributed as it becomes available from a source; i.e., the main difference from on-demand is that one starts distributing content before the end of it has become available to the server.
このユースケースは、上記のオンデマンドコンテンツのケース（付録E.1を参照）に似ていますが、コンテンツ自体の性質が異なります。ソースから利用可能になると、ライブコンテンツは継続的に配信されます。つまり、オンデマンドとの主な違いは、コンテンツの終わりがサーバーで利用可能になる前にコンテンツの配信を開始することです。
In many cases, the consumer of live content is only interested in consuming what actually happens "now"; i.e., very similar to broadcast TV. However, in this case, it is assumed that there exists no broadcast or multicast channel to the users, and instead the server functions as a distribution node, sending the same content to multiple receivers, using unicast traffic between server and client. This unicast traffic and the transport parameters are individually negotiated for each receiving client.
多くの場合、ライブコンテンツの消費者は、実際に「今」起こっていることを消費することにのみ関心があります。つまり、テレビ放送と非常に似ています。ただし、この場合、ユーザーへのブロードキャストチャネルまたはマルチキャストチャネルは存在せず、代わりにサーバーが配信ノードとして機能し、サーバーとクライアント間のユニキャストトラフィックを使用して、同じコンテンツを複数の受信者に送信します。このユニキャストトラフィックとトランスポートパラメータは、受信クライアントごとに個別にネゴシエートされます。
Another aspect of live content is that it often has a very limited time of availability, as it is only available for the duration of the event the content covers. An example of such live content could be a music concert that lasts two hours and starts at a predetermined time. Thus, there is a need to announce when and for how long the live content is available.
ライブコンテンツのもう1つの側面は、コンテンツがカバーするイベントの期間中のみ利用できるため、非常に限られた時間しか利用できないことが多いことです。このようなライブコンテンツの例としては、2時間続き、所定の時間に始まる音楽コンサートがあります。したがって、ライブコンテンツがいつ、どのくらいの期間利用できるかを発表する必要があります。
In some cases, the server providing live content may be saving some or all of the content to allow clients to pause the stream and resume it from the paused point, or to "rewind" and play continuously from a point earlier than the live point. Hence, this use case does not necessarily exclude playing from other than the live point of the stream, playing with scales other than 1.0, etc.
場合によっては、ライブコンテンツを提供するサーバーがコンテンツの一部またはすべてを保存して、クライアントがストリームを一時停止して一時停止したポイントから再開したり、「巻き戻し」してライブポイントより前のポイントから継続的に再生したりできるようにします。したがって、この使用例は、ストリームのライブポイント以外からの再生、1.0以外のスケールでの再生などを必ずしも除外しません。
It is possible to use RTSP to request that media be delivered to a multicast group. The entity setting up the session (the controller) will then control when and what media is delivered to the group. This use case has some potential for DoS attacks by flooding a multicast group. Therefore, a mechanism is needed to indicate that the group actually accepts the traffic from the RTSP server.
RTSPを使用して、メディアをマルチキャストグループに配信するように要求できます。セッションをセットアップするエンティティ（コントローラー）は、いつ、どのメディアをグループに配信するかを制御します。この使用例は、マルチキャストグループをフラッディングすることにより、DoS攻撃の可能性を秘めています。したがって、グループが実際にRTSPサーバーからのトラフィックを受け入れることを示すメカニズムが必要です。
An open issue in this use case is how one ensures that all receivers listening to the multicast or broadcast receives the session presentation configuring the receivers. This specification has to rely on an external solution to solve this issue.
このユースケースの未解決の問題は、マルチキャストまたはブロードキャストをリッスンするすべてのレシーバーが、レシーバーを構成するセッションプレゼンテーションを確実に受信する方法です。この仕様では、この問題を解決するために外部ソリューションに依存する必要があります。
If one has an established conference or group session, it is possible to have an RTSP server distribute media to the whole group. Transmission to the group is simplest when controlled by a single participant or leader of the conference. Shared control might be possible, but would require further investigation and possibly extensions.
会議またはグループセッションが確立されている場合は、RTSPサーバーにグループ全体にメディアを配信させることができます。グループへの送信は、会議の単一の参加者またはリーダーによって制御される場合に最も簡単です。共有制御は可能かもしれませんが、さらなる調査と、場合によっては拡張が必要になります。
This use case assumes that there exists either a multicast or a conference focus that redistributes media to all participants.
この使用例では、すべての参加者にメディアを再配布するマルチキャストまたは会議のフォーカスが存在すると想定しています。
This use case is intended to be able to handle the following scenario: a conference leader or participant (hereafter called the "controller") has some pre-stored content on an RTSP server that he wants to share with the group. The controller sets up an RTSP session at the streaming server for this content and retrieves the session description for the content. The destination for the media content is set to the shared multicast group or conference focus. When desired by the controller, he/she can start and stop the transmission of the media to the conference group.
この使用例は、次のシナリオを処理できるようにすることを目的としています。会議のリーダーまたは参加者（以降、「コントローラー」と呼びます）は、グループと共有するコンテンツをRTSPサーバーに事前に保存しています。コントローラーは、ストリーミングサーバーでこのコンテンツのRTSPセッションをセットアップし、コンテンツのセッションの説明を取得します。メディアコンテンツの宛先は、共有マルチキャストグループまたは会議フォーカスに設定されます。コントローラーは、必要に応じて、会議グループへのメディアの送信を開始および停止できます。
There are several issues with this use case that are not solved by this core specification for RTSP:
この使用例には、RTSPのこのコア仕様では解決されないいくつかの問題があります。
DoS: To avoid an RTSP server from being an unknowing participant in a DoS attack, the server needs to be able to verify the destination's acceptance of the media. Such a mechanism to verify the approval of received media does not yet exist; instead, only policies can be used, which can be made to work in controlled environments.
DoS：RTSPサーバーがDoS攻撃の知らない参加者にならないようにするには、サーバーが宛先のメディアの受け入れを確認できる必要があります。受け取ったメディアの承認を検証するこのようなメカニズムはまだ存在しません。代わりに、制御された環境で機能するように作成できるポリシーのみを使用できます。
Distributing the presentation description to all participants in the group: To enable a media receiver to correctly decode the content, the media configuration information needs to be distributed reliably to all participants. This will most likely require support from an external protocol.
グループのすべての参加者にプレゼンテーションの説明を配信する：メディアレシーバーがコンテンツを正しくデコードできるようにするには、メディア構成情報をすべての参加者に確実に配信する必要があります。ほとんどの場合、これには外部プロトコルからのサポートが必要になります。
Passing control of the session: If it is desired to pass control of the RTSP session between the participants, some support will be required by an external protocol to exchange state information and possibly floor control of who is controlling the RTSP session.
セッションの制御を渡す：参加者間でRTSPセッションの制御を渡すことが必要な場合は、外部プロトコルが状態情報を交換し、場合によってはRTSPセッションを制御しているユーザーのフロア制御を行うためのサポートが必要です。
This use case in its simplest form does not require any use of RTSP at all; this is what multicast conferences being announced with SAP [RFC2974] and SDP are intended to handle. However, in use cases where more advanced features like access control to the multicast session are desired, RTSP could be used for session establishment.
最も単純な形式のこの使用例では、RTSPをまったく使用する必要はありません。これは、SAP [RFC2974]およびSDPで発表されるマルチキャスト会議が処理することを目的としています。ただし、マルチキャストセッションへのアクセス制御などのより高度な機能が必要なユースケースでは、RTSPをセッションの確立に使用できます。
A client desiring to join a live multicasted media session with cryptographic (encryption) access control could use RTSP in the following way. The source of the session announces the session and gives all interested an RTSP URI. The client connects to the server and requests the presentation description, allowing configuration for reception of the media. In this step, it is possible for the client to use secured transport and any desired level of authentication; for example, for billing or access control. An RTSP link also allows for load balancing between multiple servers.
暗号化（暗号化）アクセスコントロールを使用してライブマルチキャストメディアセッションに参加することを希望するクライアントは、RTSPを次のように使用できます。セッションのソースはセッションをアナウンスし、関係するすべてのRTSP URIを提供します。クライアントはサーバーに接続し、プレゼンテーションの説明を要求します。これにより、メディアを受信するための構成が可能になります。このステップでは、クライアントがセキュアなトランスポートと任意の認証レベルを使用することが可能です。たとえば、請求やアクセス制御のために。 RTSPリンクでは、複数のサーバー間の負荷分散も可能です。
If these were the only goals, they could be achieved by simply using HTTP. However, for cases where the sender likes to keep track of each individual receiver of a session, and possibly use the session as a side channel for distributing key-updates or other information on a per-receiver basis, and the full set of receivers is not known prior to the session start, the state establishment that RTSP provides can be beneficial. In this case, a client would establish an RTSP session for this multicast group with the RTSP server. The RTSP server will not transmit any media, but instead will point to the multicast group. The client and server will be able to keep the session alive for as long as the receiver participates in the session thus enabling, for example, the server to push updates to the client.
これらが唯一の目標である場合、単にHTTPを使用することで達成できます。ただし、送信者がセッションの各受信者を追跡し、セッションをサイドチャネルとして使用して受信者ごとにキーの更新やその他の情報を配布する場合、受信者の完全なセットはセッションの開始前はわからないため、RTSPが提供する状態の確立は有益な場合があります。この場合、クライアントはRTSPサーバーとこのマルチキャストグループのRTSPセッションを確立します。 RTSPサーバーはメディアを送信せず、代わりにマルチキャストグループをポイントします。クライアントとサーバーは、レシーバーがセッションに参加している限り、セッションを存続させることができるため、たとえば、サーバーが更新をクライアントにプッシュできるようになります。
This use case will most likely not be able to be implemented without some extensions to the server-to-client push mechanism. Here the PLAY_NOTIFY method (see Section 13.5) with a suitable extension could provide clear benefits.
このユースケースは、サーバーからクライアントへのプッシュメカニズムにいくつかの拡張機能がないと実装できない可能性が高いです。ここで、適切な拡張機能を備えたPLAY_NOTIFYメソッド（セクション13.5を参照）は、明確な利点を提供できます。
A resource of type "text/parameters" consists of either 1) a list of parameters (for a query) or 2) a list of parameters and associated values (for a response or setting of the parameter). Each entry of the list is a single line of text. Parameters are separated from values by a colon. The parameter name MUST only use US-ASCII visible characters while the values are UTF-8 text strings. The media type registration form is in Section 22.16.
タイプ「text / parameters」のリソースは、1）パラメーターのリスト（クエリの場合）または2）パラメーターのリストと関連する値（応答またはパラメーターの設定の場合）のいずれかで構成されます。リストの各エントリは、1行のテキストです。パラメータと値はコロンで区切られています。パラメータ名はUS-ASCII可視文字のみを使用する必要がありますが、値はUTF-8テキスト文字列です。メディアタイプ登録フォームはセクション22.16にあります。
There is a potential interoperability issue for this format. It was named in RFC 2326 but never defined, even if used in examples that hint at the syntax. This format matches the purpose and its syntax supports the examples provided. However, it goes further by allowing UTF-8 in the value part; thus, usage of UTF-8 strings may not be supported. However, as individual parameters are not defined, the implementing application needs to have out-of-band agreement or using feature tag anyway to determine if the endpoint supports the parameters.
この形式には潜在的な相互運用性の問題があります。これはRFC 2326で命名されましたが、構文を示唆する例で使用されている場合でも、定義されていません。この形式は目的に一致し、その構文は提供される例をサポートします。ただし、値の部分でUTF-8を許可することでさらに進んでいます。したがって、UTF-8文字列の使用はサポートされない場合があります。ただし、個々のパラメータが定義されていないため、実装するアプリケーションは、帯域外の合意が必要か、エンドポイントがパラメータをサポートしているかどうかを判断するために機能タグを使用する必要があります。
The ABNF [RFC5234] grammar for "text/parameters" content is:
「テキスト/パラメータ」コンテンツのABNF [RFC5234]文法は次のとおりです。
file = *((parameter / parameter-value) CRLF)
parameter = 1*visible-except-colon
parameter-value = parameter *WSP ":" value
visible-except-colon = %x21-39 / %x3B-7E ; VCHAR - ":"
value = *(TEXT-UTF8char / WSP)
TEXT-UTF8char = <as defined in Section 20.1>
WSP = <See RFC 5234> ; Space or HTAB
VCHAR = <See RFC 5234>
CRLF = <See RFC 5234>
Appendix G. Requirements for Unreliable Transport of RTSP
付録G. RTSPの信頼できないトランスポートの要件
This appendix provides guidance for those who want to implement RTSP messages over unreliable transports as has been defined in RTSP 1.0 [RFC2326]. RFC 2326 defined the "rtspu" URI scheme and provided some basic information for the transport of RTSP messages over UDP. The information is being provided here as there has been at least one commercial implementation and compatibility with that should be maintained.
この付録は、RTSP 1.0 [RFC2326]で定義されているように、信頼性の低いトランスポートを介してRTSPメッセージを実装したい人のためのガイダンスを提供します。 RFC 2326は「rtspu」URIスキームを定義し、UDPを介したRTSPメッセージの転送に関するいくつかの基本情報を提供しました。少なくとも1つの商用実装があり、それとの互換性を維持する必要があるため、ここで情報を提供しています。
The following points should be considered for an interoperable implementation:
相互運用可能な実装では、次の点を考慮する必要があります。
o Requests shall be acknowledged by the receiver. If there is no acknowledgement, the sender may resend the same message after a timeout of one round-trip time (RTT). Any retransmissions due to lack of acknowledgement must carry the same sequence number as the original request.
o リクエストは受信者によって確認されます。確認応答がない場合、送信者は1回のラウンドトリップ時間（RTT）のタイムアウト後に同じメッセージを再送信できます。確認応答がないために再送信する場合は、元の要求と同じシーケンス番号を伝える必要があります。
o The RTT can be estimated as in TCP (RFC 6298) [RFC6298], with an initial round-trip value of 500 ms. An implementation may cache the last RTT measurement as the initial value for future connections.
o RTTは、TCP（RFC 6298）[RFC6298]と同様に推定でき、初期往復時間は500ミリ秒です。実装では、最後のRTT測定を将来の接続の初期値としてキャッシュする場合があります。
o The Timestamp header (Section 18.53) is used to avoid the retransmission ambiguity problem [Stevens98].
o Timestampヘッダー（セクション18.53）は、再送信のあいまいさの問題を回避するために使用されます[Stevens98]。
o The registered default port for RTSP over UDP for the server is 554.
o サーバーのRTSP over UDPの登録済みデフォルトポートは554です。
o RTSP messages can be carried over any lower-layer transport protocol that is 8-bit clean.
o RTSPメッセージは、8ビットクリーンな下位層のトランスポートプロトコルを介して伝送できます。
o RTSP messages are vulnerable to bit errors and should not be subjected to them.
o RTSPメッセージはビットエラーに対して脆弱であり、それらの影響を受けるべきではありません。
o Source authentication, or at least validation that RTSP messages comes from the same entity becomes extremely important, as session hijacking may be substantially easier for RTSP message transport using an unreliable protocol like UDP than for TCP.
o ソースの認証、または少なくとも同じエンティティからRTSPメッセージが送信されることの検証は非常に重要になります。UDPなどの信頼性の低いプロトコルを使用するRTSPメッセージ転送では、TCPよりもセッションハイジャックが大幅に容易になる可能性があるためです。
There are two RTSP headers that are primarily intended for being used by the unreliable handling of RTSP messages and which will be maintained:
RTSPメッセージの信頼できない処理で使用することを主な目的としており、維持される2つのRTSPヘッダーがあります。
o CSeq: See Section 18.20. It should be noted that the CSeq header is also required to match requests and responses independent whether a reliable or unreliable transport is used.
o CSeq：セクション18.20を参照。 CSeqヘッダーは、信頼性のあるトランスポートと信頼性のないトランスポートのどちらが使用されているかに関係なく、要求と応答を一致させるためにも必要です。
o Timestamp: See Section 18.53
o タイムスタンプ：セクション18.53を参照
Appendix H. Backwards-Compatibility Considerations
付録H.下位互換性に関する考慮事項
This section contains notes on issues about backwards compatibility with clients or servers being implemented according to RFC 2326 [RFC2326]. Note that there exists no requirement to implement RTSP 1.0; in fact, this document recommends against it as it is difficult to do in an interoperable way.
このセクションには、RFC 2326 [RFC2326]に従って実装されているクライアントまたはサーバーとの下位互換性に関する問題に関する注意事項が含まれています。 RTSP 1.0を実装する必要がないことに注意してください。実際、相互運用可能な方法で行うのは難しいため、このドキュメントでは推奨しません。
A server implementing RTSP 2.0 MUST include an RTSP-Version of "RTSP/2.0" in all responses to requests containing RTSP-Version value of "RTSP/2.0". If a server receives an RTSP 1.0 request, it MAY respond with an RTSP 1.0 response if it chooses to support RFC 2326. If the server chooses not to support RFC 2326, it MUST respond with a 505 (RTSP Version Not Supported) status code. A server MUST NOT respond to an RTSP 1.0 request with an RTSP 2.0 response.
RTSP 2.0を実装するサーバーは、「RTSP / 2.0」のRTSP-Version値を含むリクエストへのすべての応答に「RTSP / 2.0」のRTSP-Versionを含める必要があります。サーバーがRTSP 1.0リクエストを受信した場合、サーバーがRFC 2326をサポートすることを選択した場合、RTSP 1.0応答で応答してもかまいません。サーバーがRFC 2326をサポートしないことを選択した場合、サーバーは505（RTSPバージョン非サポート）ステータスコードで応答する必要があります。サーバーは、RTSP 2.0応答でRTSP 1.0要求に応答してはなりません（MUST NOT）。
Clients implementing RTSP 2.0 MAY use an OPTIONS request with an RTSP-Version of "RTSP/2.0" to determine whether a server supports RTSP 2.0. If the server responds with either an RTSP-Version of "RTSP/1.0" or a status code of 505 (RTSP Version Not Supported), the client will have to use RTSP 1.0 requests if it chooses to support RFC 2326.
RTSP 2.0を実装するクライアントは、サーバーがRTSP 2.0をサポートしているかどうかを判断するために、RTSP-Versionが「RTSP / 2.0」のOPTIONSリクエストを使用する場合があります。サーバーが "RTSP / 1.0"のRTSPバージョンまたは505（RTSPバージョンはサポートされていません）のステータスコードで応答する場合、クライアントがRFC 2326をサポートすることを選択した場合、クライアントはRTSP 1.0要求を使用する必要があります。
The behavior in the server when a Play is received in Play state has changed (Section 13.4). In RFC 2326, the new PLAY request would be queued until the current Play completed. Any new PLAY request now takes effect immediately replacing the previous request.
Play状態でPlayを受信したときのサーバーの動作が変更されました（セクション13.4）。 RFC 2326では、新しいPLAYリクエストは、現在のPlayが完了するまでキューに入れられます。新しいPLAY要求は、以前の要求を置き換えてすぐに有効になります。
Some server implementations of RFC 2326 maintain a one-to-one relationship between a connection and an RTSP session. Such implementations require clients to use a persistent connection to communicate with the server and when a client closes its connection, the server may remove the RTSP session. This is worth noting if an RTSP 2.0 client also supporting 1.0 connects to a 1.0 server.
RFC 2326の一部のサーバー実装は、接続とRTSPセッションの間の1対1の関係を維持します。このような実装では、クライアントがサーバーと通信するために永続的な接続を使用する必要があり、クライアントが接続を閉じると、サーバーはRTSPセッションを削除する場合があります。これは、1.0もサポートするRTSP 2.0クライアントが1.0サーバーに接続する場合に注目に値します。
Appendix I. Changes
付録I.変更
This appendix briefly lists the differences between RTSP 1.0 [RFC2326] and RTSP 2.0 for an informational purpose. For implementers of RTSP 2.0, it is recommended to read carefully through this memo and not to rely on the list of changes below to adapt from RTSP 1.0 to RTSP 2.0, as RTSP 2.0 is not intended to be backwards compatible with RTSP 1.0 [RFC2326] other than the version negotiation mechanism.
この付録では、情報提供を目的としたRTSP 1.0 [RFC2326]とRTSP 2.0の違いを簡単に示します。 RTSP 2.0はRTSP 1.0との下位互換性を意図していないため、RTSP 2.0の実装者は、このメモを注意深く読み、RTSP 1.0からRTSP 2.0に適応するために以下の変更リストに依存しないことをお勧めします[RFC2326]バージョンネゴシエーションメカニズム以外。
The following protocol elements were removed in RTSP 2.0 compared to RTSP 1.0:
RTSP 1.0と比較して、RTSP 2.0では次のプロトコル要素が削除されました。
o the RECORD and ANNOUNCE methods and all related functionality (including 201 (Created) and 250 (Low On Storage Space) status codes);
o RECORDおよびANNOUNCEメソッドとすべての関連機能（201（作成済み）および250（ストレージ容量不足）ステータスコードを含む）;
o the use of UDP for RTSP message transport (due to missing interest and to broken specification);
o RTSPメッセージ転送にUDPを使用する（関心の欠如と仕様の違反による）。
o the use of PLAY method for keep-alive in Play state.
o Play状態でのキープアライブのためのPLAYメソッドの使用。
The following protocol elements were added or changed in RTSP 2.0 compared to RTSP 1.0:
次のプロトコル要素は、RTSP 1.0と比較してRTSP 2.0で追加または変更されました。
o RTSP session TEARDOWN from the server to the client;
o サーバーからクライアントへのRTSPセッションTEARDOWN。
o IPv6 support;
o IPv6サポート。
o extended IANA registries (e.g., transport headers parameters, transport-protocol, profile, lower-transport, and mode);
o 拡張IANAレジストリー（トランスポートヘッダーパラメーター、トランスポートプロトコル、プロファイル、下位トランスポート、モードなど）
o request pipelining for quick session start-up;
o 迅速なセッション開始のためのパイプライン化を要求します。
o fully reworked state machine;
o 完全に再加工されたステートマシン。
o RTSP messages now use URIs rather than URLs;
o RTSPメッセージはURLではなくURIを使用するようになりました。
o incorporated much of related HTTP text ([RFC2616]) in this memo, compared to just referencing the sections in HTTP, to avoid ambiguities;
o あいまいさを避けるために、HTTPでセクションを参照するだけの場合と比較して、関連するHTTPテキスト（[RFC2616]）の多くをこのメモに組み込んだ。
o the REDIRECT method was expanded and diversified for different situations;
o REDIRECTメソッドは、さまざまな状況に合わせて拡張および多様化されました。
o Includes a new section about how to set up different media-transport alternatives and their profiles in addition to lower-layer protocols. This caused the appendix on RTP interaction to be moved to the new section instead of being in the part that describes RTP. The section also includes guidelines what to consider when writing usage guidelines for new protocols and profiles;
o 下位層のプロトコルに加えて、さまざまなメディアトランスポートの代替とそれらのプロファイルを設定する方法に関する新しいセクションが含まれています。これにより、RTPの相互作用に関する付録が、RTPを説明する部分ではなく、新しいセクションに移動しました。このセクションには、新しいプロトコルとプロファイルの使用ガイドラインを作成するときに考慮すべきガイドラインも含まれています。
o Added an asynchronous notification method PLAY_NOTIFY. This method is used by the RTSP server to asynchronously notify clients about session changes while in Play state. To a limited extent, this is comparable with some implementations of ANNOUNCE in RTSP 1.0 not intended for Recording.
o 非同期通知メソッドPLAY_NOTIFYが追加されました。このメソッドはRTSPサーバーによって使用され、プレイ状態の間にセッションの変更についてクライアントに非同期的に通知します。限られた範囲で、これはRTSP 1.0でのANNOUNCEの一部の実装と同等であり、録音を目的としていません。
The below changes have been made to RTSP 1.0 (RFC 2326) when defining RTSP 2.0. Note that this list does not reflect minor changes in wording or correction of typographical errors.
RTSP 2.0を定義するときに、RTSP 1.0（RFC 2326）に以下の変更が加えられました。このリストは、表記上の小さな変更や誤植の訂正を反映していないことに注意してください。
o The section on minimal implementation was deleted. Instead, the main part of the specification defines the core of RTSP 2.0.
o 最小限の実装に関するセクションが削除されました。代わりに、仕様の主要部分がRTSP 2.0のコアを定義しています。
o The Transport header has been changed in the following ways:
o Transportヘッダーは、次のように変更されました。
* The ABNF has been changed to define that extensions are possible and that unknown parameters result in servers ignoring the transport specification.
* ABNFが変更され、拡張が可能であり、不明なパラメーターによりサーバーがトランスポート仕様を無視することを定義しました。
* To prevent backwards compatibility issues, any extension or new parameter requires the usage of a feature tag combined with the Require header.
* 下位互換性の問題を防ぐために、拡張機能や新しいパラメータでは、Requireヘッダーと組み合わせた機能タグを使用する必要があります。
* Syntax ambiguities with the Mode parameter have been resolved.
* Modeパラメーターの構文のあいまいさは解決されました。
* Syntax error with ";" for multicast and unicast has been resolved.
* 「;」の構文エラーマルチキャストとユニキャストの問題が解決されました。
* Two new addressing parameters have been defined: src_addr and dest_addr. These replace the parameters "port", "client_port", "server_port", "destination", and "source".
* src_addrとdest_addrの2つの新しいアドレス指定パラメーターが定義されました。これらは、パラメーター「port」、「client_port」、「server_port」、「destination」、および「source」を置き換えます。
* Support for IPv6 explicit addresses in all address fields has been included.
* すべてのアドレスフィールドでのIPv6明示アドレスのサポートが含まれています。
* To handle URI definitions that contain ";" or ",", a quoted-URI format has been introduced and is required.
* 「;」を含むURI定義を処理するにはまたは、「、」、引用符で囲まれたURI形式が導入され、必須です。
* IANA registries for the transport header parameters, transport-protocol, profile, lower-transport, and mode have been defined.
* トランスポートヘッダーパラメータ、transport-protocol、profile、lower-transport、およびmodeのIANAレジストリが定義されています。
* The Transport header's interleaved parameter's text was made more strict and uses formal requirements levels. It was also clarified that the interleaved channels are symmetric and that it is the server that sets the channel numbers.
* トランスポートヘッダーのインターリーブパラメーターのテキストはより厳密になり、正式な要件レベルを使用します。また、インターリーブされたチャネルは対称的であり、チャネル番号を設定するのはサーバーであることも明らかになりました。
* It has been clarified that the client can't request of the server to use a certain RTP SSRC, using a request with the transport parameter SSRC.
* トランスポートパラメータSSRCを使用したリクエストを使用して、クライアントが特定のRTP SSRCを使用するようにサーバーにリクエストできないことが明らかになりました。
* Syntax definition for SSRC has been clarified to require 8HEX. It has also been extended to allow multiple values for clients supporting this version.
* SSRCの構文定義が明確になり、8HEXが必要になりました。また、このバージョンをサポートするクライアントに複数の値を許可するように拡張されました。
* Clarified the text on the Transport header's "dest_addr" parameters regarding what security precautions the server is required to perform.
* サーバーが実行するために必要なセキュリティ対策に関するトランスポートヘッダーの「dest_addr」パラメーターのテキストを明確にしました。
o The Range formats have been changed in the following way:
o 範囲の形式は次のように変更されました。
* The NPT format has been given an initial NPT identifier that must now be used.
* NPT形式には、現在使用する必要がある初期NPT識別子が与えられています。
* All formats now support initial open-ended formats of type "npt=-10" and also format only "Range: smpte" ranges for usage with GET_PARAMETER requests.
* すべてのフォーマットは、タイプ「npt = -10」の初期の制限のないフォーマットをサポートし、GET_PARAMETERリクエストで使用する「範囲：smpte」範囲のみをフォーマットします。
* The npt-hhmmss notation now follows ISO 8601 more strictly.
* npt-hhmmss表記はISO 8601に厳密に準拠しています。
o RTSP message handling has been changed in the following ways:
o RTSPメッセージの処理が次のように変更されました。
* RTSP messages now use URIs rather than URLs.
* RTSPメッセージは、URLではなくURIを使用するようになりました。
* It has been clarified that a 4xx message due to a missing CSeq header shall be returned without a CSeq header.
* CSeqヘッダーが欠落しているために4xxメッセージがCSeqヘッダーなしで返されることを明確にしました。
* The 300 (Multiple Choices) response code has been removed.
* 300（Multiple Choices）応答コードは削除されました。
* Rules for how to handle the timing out RTSP messages have been added.
* RTSPメッセージのタイムアウトの処理方法に関するルールが追加されました。
* Extended Pipelining rules allowing for quick session startup.
* 迅速なセッション開始を可能にする拡張パイプラインルール。
* Sequence numbering and proxy handling of sequence numbers have been defined, including cases when responses arrive out of order.
* シーケンス番号とシーケンス番号のプロキシ処理が定義されており、応答が順不同で到着した場合も含まれます。
o The HTTP references have been updated to first RFCs 2616 and 2617 and then to RFC 7230-7235. Most of the text has been copied and then altered to fit RTSP into this specification. The Public and the Content-Base headers have also been imported from RFC 2068 so that they are defined in the RTSP specification. Known effects on RTSP due to HTTP clarifications:
o HTTP参照は、最初のRFC 2616および2617に更新され、次にRFC 7230-7235に更新されました。ほとんどのテキストはコピーされ、RTSPがこの仕様に適合するように変更されています。 PublicおよびContent-Baseヘッダーも、RTSP仕様で定義されるようにRFC 2068からインポートされています。 HTTPの明確化によるRTSPへの既知の影響：
* Content-Encoding header can include encoding of type "identity".
* Content-Encodingヘッダーには、「identity」タイプのエンコーディングを含めることができます。
o The state machine section has been completely rewritten. It now includes more details and is also more clear about the model used.
o ステートマシンセクションは完全に書き直されました。詳細が追加され、使用されているモデルについても明確になりました。
o An IANA section has been included that contains a number of registries and their rules. This will allow us to use IANA to keep track of RTSP extensions.
o 多数のレジストリとそのルールを含むIANAセクションが含まれています。これにより、IANAを使用してRTSP拡張機能を追跡できます。
o The transport of RTSP messages has seen the following changes:
o RTSPメッセージの転送では、次の変更が行われました。
* The use of UDP for RTSP message transport has been deprecated due to missing interest and to broken specification.
* RTSPメッセージ転送にUDPを使用することは、関心が欠けていたり、仕様が壊れていたりしたため廃止されました。
* The rules for how TCP connections are to be handled have been clarified. Now it is made clear that servers should not close the TCP connection unless they have been unused for significant time.
* TCP接続の処理方法に関するルールが明確になりました。これで、サーバーが長時間使用されない限り、サーバーがTCP接続を閉じてはならないことが明らかになりました。
* Strong recommendations why servers and clients should use persistent connections have also been added.
* サーバーとクライアントが永続的な接続を使用するべき強力な推奨事項も追加されました。
* There is now a requirement on the servers to handle non-persistent connections as this provides fault tolerance.
* フォールトトレランスを提供するため、非永続的な接続を処理するためのサーバーの要件があります。
* Added wording on the usage of Connection:Close for RTSP.
* RTSPのConnection：Closeの使用に関する文言を追加しました。
* Specified usage of TLS for RTSP messages, including a scheme to approve a proxy's TLS connection to the next hop.
* ネクストホップへのプロキシのTLS接続を承認するスキームを含む、RTSPメッセージのTLSの指定された使用法。
o The following header-related changes have been made:
o 次のヘッダー関連の変更が行われました。
* Accept-Ranges response-header has been added. This header clarifies which range formats can be used for a resource.
* Accept-Ranges応答ヘッダーが追加されました。このヘッダーは、リソースに使用できる範囲形式を明確にします。
* Fixed the missing definitions for the Cache-Control header. Also added to the syntax definition the missing delta-seconds for max-stale and min-fresh parameters.
* Cache-Controlヘッダーの欠落した定義を修正しました。また、構文定義に、max-staleおよびmin-freshパラメーターの欠落したデルタ秒が追加されました。
* Put requirement on CSeq header that the value is increased by one for each new RTSP request. A recommendation to start at 0 has also been added.
* CSeqヘッダーに、新しいRTSP要求ごとに値が1ずつ増えるという要件を課します。 0から開始するという推奨事項も追加されました。
* Added a requirement that the Date header must be used for all messages with a message body and the Server should always include it.
* メッセージ本文のあるすべてのメッセージに日付ヘッダーを使用する必要があり、サーバーは常にそれを含める必要があるという要件を追加しました。
* Removed the possibility of using Range header with Scale header to indicate when it is to be activated, since it can't work as defined. Also, added a rule that lack of Scale header in a response indicates lack of support for the header. feature tags for scaled playback have been defined.
* RangeヘッダーをScaleヘッダーと共に使用して、アクティブ化するタイミングを示す可能性を削除しました。定義どおりに機能しないためです。また、応答にScaleヘッダーがないことはヘッダーのサポートがないことを示すというルールを追加しました。スケール再生用の機能タグが定義されました。
* The Speed header must now be responded to in order to indicate support and the actual speed going to be used. A feature tag is defined. Notes on congestion control were also added.
* 使用するサポートと実際の速度を示すために、Speedヘッダーに応答する必要があります。機能タグが定義されています。輻輳制御に関する注意事項も追加されました。
* The Supported header was borrowed from SIP [RFC3261] to help with the feature negotiation in RTSP.
* サポートされているヘッダーは、RTSPの機能ネゴシエーションを支援するためにSIP [RFC3261]から借用されました。
* Clarified that the Timestamp header can be used to resolve retransmission ambiguities.
* Timestampヘッダーを使用して再送信のあいまいさを解決できることを明確にしました。
* The Session header text has been expanded with an explanation on keep-alive and which methods to use. SET_PARAMETER is now recommended to use if only keep-alive within RTSP is desired.
* セッションヘッダーテキストが拡張され、キープアライブと使用するメソッドの説明が追加されました。 RTSP内でキープアライブのみが必要な場合は、SET_PARAMETERを使用することをお勧めします。
* It has been clarified how the Range header formats are used to indicate pause points in the PAUSE response.
* Rangeヘッダー形式を使用して、PAUSE応答の一時停止ポイントを示す方法が明確になりました。
* Clarified that RTP-Info URIs that are relative use the Request-URI as base URI. Also clarified that the used URI must be the one that was used in the SETUP request. The URIs are now also
* 相対であるRTP-Info URIは、Request-URIをベースURIとして使用することを明確にしました。また、使用されるURIはSETUPリクエストで使用されたものでなければならないことを明確にしました。 URIもまた
required to be quoted. The header also expresses the SSRC for the provided RTP timestamp and sequence number values.
引用する必要があります。ヘッダーは、提供されたRTPタイムスタンプとシーケンス番号の値のSSRCも表します。
* Added text that requires the Range to always be present in PLAY responses. Clarified what should be sent in case of live streams.
* 範囲が常にPLAY応答に存在する必要があるテキストを追加しました。ライブストリームの場合に送信する内容を明確にしました。
* The headers table has been updated using a structure borrowed from SIP. Those tables convey much more information and should provide a good overview of the available headers.
* ヘッダーテーブルは、SIPから借用した構造を使用して更新されています。これらのテーブルはより多くの情報を伝え、利用可能なヘッダーの概要を提供します。
* It has been clarified that any message with a message body is required to have a Content-Length header. This was the case in RFC 2326, but could be misinterpreted.
* メッセージ本文を含むすべてのメッセージにはContent-Lengthヘッダーが必要であることを明確にしました。これはRFC 2326の場合でしたが、誤って解釈される可能性があります。
* ETag has changed its name to MTag.
* ETagはその名前をMTagに変更しました。
* To resolve functionality around MTag, the MTag and If-None-Match header have been added from HTTP with necessary clarification in regard to RTSP operation.
* MTagに関連する機能を解決するために、RTSPオペレーションに関して必要な説明を加えて、MTagおよびIf-None-MatchヘッダーがHTTPから追加されました。
* Imported the Public header from HTTP (RFC 2068 [RFC2068]) since it has been removed from HTTP due to lack of use. Public is used quite frequently in RTSP.
* HTTPからパブリックヘッダーをインポートしました（RFC 2068 [RFC2068]）。これは、使用されなかったためにHTTPから削除されたためです。 RTSPではPublicが非常に頻繁に使用されています。
* Clarified rules for populating the Public header so that it is an intersection of the capabilities of all the RTSP agents in a chain.
* チェーン内のすべてのRTSPエージェントの機能の共通部分になるように、パブリックヘッダーに入力するためのルールを明確にしました。
* Added the Media-Range header for listing the current availability of the media range.
* メディア範囲の現在の可用性をリストするためのMedia-Rangeヘッダーを追加しました。
* Added the Notify-Reason header for giving the reason when sending PLAY_NOTIFY requests.
* PLAY_NOTIFYリクエストを送信する際の理由を示すためのNotify-Reasonヘッダーを追加しました。
* A new header Seek-Style has been defined to direct and inform how any seek operation should/have been performed.
* 新しいヘッダーSeek-Styleが定義され、シーク操作の実行方法/実行方法を指示および通知します。
o The Protocol Syntax has been changed in the following way:
o プロトコル構文は次のように変更されました。
* All ABNF definitions are updated according to the rules defined in RFC 5234 [RFC5234] and have been gathered in a separate section (Section 20).
* すべてのABNF定義は、RFC 5234 [RFC5234]で定義されたルールに従って更新され、別のセクション（セクション20）に収集されています。
* The ABNF for the User-Agent and Server headers have been corrected.
* User-AgentおよびServerヘッダーのABNFが修正されました。
* Some definitions in the introduction regarding the RTSP session have been changed.
* RTSPセッションに関する概要の一部の定義が変更されました。
* The protocol has been made fully IPv6 capable.
* プロトコルは完全にIPv6対応になっています。
* The CHAR rule has been changed to exclude NULL.
* CHARルールはNULLを除外するように変更されました。
o The Status codes have been changed in the following ways:
o ステータスコードは次のように変更されました。
* The use of status code 303 (See Other) has been deprecated as it does not make sense to use in RTSP.
* ステータスコード303（その他を参照）の使用は、RTSPでの使用には意味がないため、廃止されました。
* The never-defined status code 411 "Length Required" has been completely removed.
* 定義されていないステータスコード411 "Length Required"は完全に削除されました。
* When sending response 451 (Parameter Not Understood) and 458 (Parameter Is Read-Only), the response body should contain the offending parameters.
* 応答451（パラメーターが理解されていません）および458（パラメーターは読み取り専用）を送信する場合、応答の本文には問題のパラメーターが含まれている必要があります。
* Clarification on when a 3rr redirect status code can be received has been added. This includes receiving 3rr as a result of a request within an established session. This provides clarification to a previous unspecified behavior.
* 3rrリダイレクトステータスコードをいつ受信できるかについての説明が追加されました。これには、確立されたセッション内の要求の結果として3rrを受信することが含まれます。これにより、以前の不特定の動作が明確になります。
* Removed the 201 (Created) and 250 (Low On Storage Space) status codes as they are only relevant to recording, which is deprecated.
* 201（Created）および250（Low On Storage Space）ステータスコードは、非推奨となったレコーディングにのみ関連するため削除されました。
* Several new status codes have been defined: 464 (Data Transport Not Ready Yet), 465 (Notification Reason Unknown), 470 (Connection Authorization Required), 471 (Connection Credentials Not Accepted), and 472 (Failure to Establish Secure Connection).
* いくつかの新しいステータスコードが定義されています：464（データ転送の準備がまだできていません）、465（通知理由不明）、470（接続認証が必要です）、471（接続資格情報が受け入れられません）、および472（安全な接続の確立に失敗しました）。
o The following functionality has been deprecated from the protocol:
o 次の機能はプロトコルから廃止されました。
* The use of Queued Play.
* キュープレイの使用。
* The use of PLAY method for keep-alive in Play state.
* Play状態でのキープアライブのためのPLAYメソッドの使用。
* The RECORD and ANNOUNCE methods and all related functionality. Some of the syntax has been removed.
* RECORDおよびANNOUNCEメソッドとすべての関連機能。構文の一部が削除されました。
* The possibility to use timed execution of methods with the time parameter in the Range header.
* Rangeヘッダーにtimeパラメータを指定して、メソッドの時間指定実行を使用する可能性。
* The description on how rtspu works is not part of the core specification and will require external description. Only that it exists is mentioned here and some requirements for the transport are provided.
* rtspuの動作に関する説明はコアの仕様の一部ではないため、外部からの説明が必要になります。ここでは、それが存在することだけを説明し、トランスポートの要件をいくつか示します。
o The following changes have been made in relation to methods:
o メソッドに関して次の変更が行われました。
* The OPTIONS method has been clarified with regard to the use of the Public and Allow headers.
* OPTIONSメソッドは、PublicおよびAllowヘッダーの使用に関して明確になりました。
* Added text clarifying the usage of SET_PARAMETER for keep-alive and usage without a body.
* キープアライブおよび本体なしの使用のためのSET_PARAMETERの使用法を明確にするテキストを追加しました。
* PLAY method is now allowed to be pipelined with the pipelining of one or more SETUP requests following the initial that generates the session for aggregated control.
* PLAYメソッドは、集約された制御のセッションを生成するイニシャルに続いて、1つ以上のSETUPリクエストのパイプライン処理でパイプライン処理できるようになりました。
* REDIRECT has been expanded and diversified for different situations.
* REDIRECTは、状況に応じて拡張および多様化されています。
* Added a new method PLAY_NOTIFY. This method is used by the RTSP server to asynchronously notify clients about session changes.
* 新しいメソッドPLAY_NOTIFYが追加されました。このメソッドは、セッションの変更についてクライアントに非同期的に通知するためにRTSPサーバーによって使用されます。
o Wrote a new section about how to set up different media-transport alternatives and their profiles as well as lower-layer protocols. This caused the appendix on RTP interaction to be moved to the new section instead of being in the part that describes RTP. The new section also includes guidelines what to consider when writing usage guidelines for new protocols and profiles.
o さまざまなメディア転送の選択肢とそのプロファイル、および下位層プロトコルを設定する方法について、新しいセクションを書きました。これにより、RTPの相互作用に関する付録が、RTPを説明する部分ではなく、新しいセクションに移動しました。新しいセクションには、新しいプロトコルとプロファイルの使用ガイドラインを作成するときに考慮すべきガイドラインも含まれています。
o Setup and usage of independent TCP connections for transport of RTP has been specified.
o RTPの転送のための独立したTCP接続のセットアップと使用法が指定されています。
o Added a new section describing the available mechanisms to determine if functionality is supported, called "Capability Handling". Renamed option-tags to feature tags.
o 「機能の処理」と呼ばれる、機能がサポートされているかどうかを判断するために利用可能なメカニズムを説明する新しいセクションを追加しました。 option-tagsの名前をfeatureタグに変更しました。
o Added a Contributors section with people who have contributed actual text to the specification.
o 仕様に実際のテキストを寄稿した人を含む寄稿者セクションを追加しました。
o Added a section "Use Cases" that describes the major use cases for RTSP.
o RTSPの主な使用例を説明するセクション「使用例」を追加しました。
o Clarified the usage of a=range and how to indicate live content that are not seekable with this header.
o a = rangeの使用法と、このヘッダーでシークできないライブコンテンツを示す方法を明確にしました。
o Text specifying the special behavior of PLAY for live content.
o ライブコンテンツに対するPLAYの特別な動作を指定するテキスト。
o Security features of RTSP have been clarified:
o RTSPのセキュリティ機能が明確になりました。
* HTTP-based authorization has been clarified requiring both Basic and Digest support
* HTTPベースの認証が明確になり、基本サポートとダイジェストサポートの両方が必要
* TLS support has been mandated
* TLSサポートが義務付けられています
* If one implements RTP, then SRTP and defined MIKEY-based key-exchange must be supported
* RTPを実装する場合、SRTPと定義済みのMIKEYベースの鍵交換をサポートする必要があります。
* Various minor mitigations discussed or resulted in protocol changes.
* さまざまな軽微な緩和策が検討され、プロトコルの変更が行われました。
Acknowledgements
謝辞
This memorandum defines RTSP version 2.0, which is a revision of the Proposed Standard RTSP version 1.0 defined in [RFC2326]. The authors of RFC 2326 are Henning Schulzrinne, Anup Rao, and Robert Lanphier.
この覚書はRTSPバージョン2.0を定義します。これは、[RFC2326]で定義されているProposed Standard RTSPバージョン1.0の改訂版です。 RFC 2326の作成者は、Henning Schulzrinne、Anup Rao、およびRobert Lanphierです。
Both RTSP version 1.0 and RTSP version 2.0 borrow format and descriptions from HTTP/1.1.
RTSPバージョン1.0とRTSPバージョン2.0はどちらも、HTTP / 1.1から形式と説明を借用しています。
Robert Sparks and especially Elwyn Davies provided very valuable and detailed reviews in the IETF Last Call that greatly improved the document and resolved many issues, especially regarding consistency.
Robert Sparks、特にElwyn Daviesは、IETF Last Callで非常に貴重で詳細なレビューを提供し、ドキュメントを大幅に改善し、特に一貫性に関する多くの問題を解決しました。
This document has benefited greatly from the comments of all those participating in the MMUSIC WG. In addition to those already mentioned, the following individuals have contributed to this specification:
このドキュメントは、MMUSIC WGに参加しているすべての人々のコメントから大きな恩恵を受けています。すでに述べたものに加えて、以下の個人がこの仕様に貢献しました：
Rahul Agarwal, Claudio Allocchio, Jeff Ayars, Milko Boic, Torsten Braun, Brent Browning, Bruce Butterfield, Steve Casner, Maureen Chesire, Jinhang Choi, Francisco Cortes, Elwyn Davies, Spencer Dawkins, Kelly Djahandari, Martin Dunsmuir, Adrian Farrel, Stephen Farrell, Ross Finlayson, Eric Fleischman, Jay Geagan, Andy Grignon, Christian Groves, V. Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, Volker Hilt, John K. Ho, Patrick Hoffman, Go Hori, Philipp Hoschka, Anne Jones, Ingemar Johansson, Jae-Hwan Kim, Anders Klemets, Ruth Lang, Barry Leiba, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Chris Lonvick, Xavier Marjou, Thomas Marshall, Rob McCool, Martti Mela, David Oran, Joerg Ott, Joe Pallas, Maria Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Colin Perkins, Pekka Pessi, Igor Plotnikov, Pete Resnick, Peter Saint-Andre, Holger Schmidt, Jonathan Sergent, Pinaki Shah, David Singer, Lior Sion, Jeff Smith, Alexander Sokolsky, Dale Stammen, John Francis Stracke, Geetha Srikantan, Scott Taylor, David Walker, Stephan Wenger, Dale R. Worley, and Byungjo Yoon, and especially Flemming Andreasen.
Rahul Agarwal、Claudio Allocchio、Jeff Ayars、Milko Boic、Torsten Braun、Brent Browning、Bruce Butterfield、Steve Casner、Maureen Chesire、Jinhang Choi、Francisco Cortes、Elwyn Davies、Spencer Dawkins、Kelly Djahandari、Martin Dunsmuir、Fadre Farrel 、Ross Finlayson、Eric Fleischman、Jay Geagan、Andy Grignon、Christian Groves、V。Guruprasad、Peter Haight、Mark Handley、Brad Hefta-Gaub、Volker Hilt、John K. Ho、Patrick Hoffman、Go Hori、Philipp Hoschka、Anne Jones 、Ingemar Johansson、Jae-Hwan Kim、Anders Klemets、Ruth Lang、Barry Leiba、Stephanie Leif、Jonathan Lennox、Eduardo F. Llach、Chris Lonvick、Xavier Marjou、Thomas Marshall、Rob McCool、Martti Mela、David Oran、Joerg Ott、 Joe Pallas、Maria Papadopouli、Sujal Patel、Ema Patki、Alagu Periyannan、Colin Perkins、Pekka Pessi、Igor Plotnikov、Pete Resnick、Peter Saint-Andre、Holger Schmidt、Jonathan Sergent、Pinaki Shah、David Singer、Lior Sion、Jeff Smith、アレクサンダーソコルスキー、デールスタメン、ジョンフランシストラック、ギースSrikantan、Scott Taylor、David Walker、Stephan Wenger、Dale R. Worley、Byungjo Yoon、特にFlemming Andreasen。
Contributors
貢献者
The following people have made written contributions that were included in the specification:
以下の人々が仕様に含まれている書面による貢献をしました：
o Tom Marshall contributed text on the usage of 3rr status codes.
o Tom Marshallは、3rrステータスコードの使用に関するテキストを寄稿しました。
o Thomas Zheng contributed text on the usage of the Range in PLAY responses and proposed an earlier version of the PLAY_NOTIFY method.
o Thomas Zhengは、PLAY応答でのRangeの使用法に関するテキストを提供し、以前のバージョンのPLAY_NOTIFYメソッドを提案しました。
o Sean Sheedy contributed text on the timeout behavior of RTSP messages and connections, the 463 (Destination Prohibited) status code, and proposed an earlier version of the PLAY_NOTIFY method.
o Sean Sheedyは、RTSPメッセージおよび接続のタイムアウト動作、463（宛先禁止）ステータスコードに関するテキストを提供し、以前のバージョンのPLAY_NOTIFYメソッドを提案しました。
o Greg Sherwood proposed an earlier version of the PLAY_NOTIFY method.
o Greg Sherwoodは、以前のバージョンのPLAY_NOTIFYメソッドを提案しました。
o Fredrik Lindholm contributed text about the RTSP security framework.
o Fredrik Lindholmは、RTSPセキュリティフレームワークに関するテキストを寄稿しました。
o John Lazzaro contributed the text for RTP over Independent TCP.
o John Lazzaroは、RTP over Independent TCPのテキストを寄稿しました。
o Aravind Narasimhan contributed by rewriting "Media-Transport Alternatives" (Appendix C) and making editorial improvements on a number of places in the specification.
o Aravind Narasimhanは、「Media-Transport Alternatives」（付録C）を書き直し、仕様の多くの場所で編集を改善することによって貢献しました。
o Torbjorn Einarsson has done some editorial improvements of the text.
o Torbjorn Einarssonは、テキストの編集を改善しました。
Authors' Addresses
著者のアドレス
Henning Schulzrinne Columbia University 1214 Amsterdam Avenue New York, NY 10027 United States of America
ヘニングシュルズリンネコロンビア大学1214アムステルダムアベニューニューヨーク、ニューヨーク10027アメリカ合衆国
Email: schulzrinne@cs.columbia.edu
Anup Rao Cisco United States of America
Anup Rao Ciscoアメリカ合衆国
Email: anrao@cisco.com
Rob Lanphier San Francisco, CA United States of America
ロブランフィエサンフランシスコ、カリフォルニア州アメリカ合衆国
Email: robla@robla.net
Magnus Westerlund Ericsson Faeroegatan 2 Stockholm SE-164 80 Sweden
Magnus Westerlund Ericsson Faeroegatan 2ストックホルムSE-164 80スウェーデン
Email: magnus.westerlund@ericsson.com
Martin Stiemerling (editor) University of Applied Sciences Darmstadt Haardtring 100 64295 Darmstadt Germany
Martin Stiemerling（editor）University of Applied Sciences Darmstadt Haardtring 100 64295ダルムシュタットドイツ
Email: mls.ietf@gmail.com
URI: http://www.stiemerling.org