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


Real-Time Streaming Protocol Version 2.0




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


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 ( 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トラストの法的規定(の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、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
1. Introduction
1. はじめに

This memo defines version 2.0 of the Real-Time Streaming Protocol (RTSP 2.0). RTSP 2.0 is an application-layer protocol for the setup and control over the delivery of data with real-time properties, typically streaming media. Streaming media is, for instance, video on demand or audio live streaming. Put simply, RTSP acts as a "network remote control" for multimedia servers.

このメモは、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つの標準仕様の付録です。その他の付録には、変更点、使用例、さまざまな考慮事項や動機について説明する情報部分がいくつか含まれています。

2. Protocol Overview
2. プロトコルの概要

This section provides an informative overview of the different mechanisms in the RTSP 2.0 protocol to give the reader a high-level understanding before getting into all the specific details. In case of conflict with this description and the later sections, the later sections take precedence. For more information about use cases considered for RTSP, see Appendix E.

このセクションでは、RTSP 2.0プロトコルのさまざまなメカニズムの概要を説明し、特定の詳細に入る前に読者に高度な理解を提供します。この説明と後のセクションが矛盾する場合は、後のセクションが優先されます。 RTSPで考慮される使用例の詳細については、付録Eを参照してください。

RTSP 2.0 is a bidirectional request and response protocol that first establishes a context including content resources (the media) and then controls the delivery of these content resources from the provider to the consumer. RTSP has three fundamental parts: Session Establishment, Media Delivery Control, and an extensibility model described below. The protocol is based on some assumptions about existing functionality to provide a complete solution for client-controlled real-time media delivery.

RTSP 2.0は、コンテンツリソース(メディア)を含むコンテキストを最初に確立し、プロバイダーからコンシューマーへのこれらのコンテンツリソースの配信を制御する双方向の要求および応答プロトコルです。 RTSPには、セッションの確立、メディア配信制御、および以下で説明する拡張性モデルの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を実装する必要があります。

2.1. Presentation Description
2.1. プレゼンテーションの説明

RTSP exists to provide access to multimedia presentations and content but tries to be agnostic about the media type or the actual media delivery protocol that is used. To enable a client to implement a complete system, an RTSP-external mechanism for describing the presentation and the delivery protocol(s) is used. RTSP assumes that this description is either delivered completely out of band or as a data object in the response to a client's request using the DESCRIBE method (Section 13.2).

RTSPは、マルチメディアプレゼンテーションおよびコンテンツへのアクセスを提供するために存在しますが、使用されるメディアタイプまたは実際のメディア配信プロトコルにとらわれないようにしています。クライアントが完全なシステムを実装できるようにするために、プレゼンテーションと配信プロトコルを記述するためのRTSP外部メカニズムが使用されます。 RTSPは、この説明が完全に帯域外で配信されるか、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).


This specification describes in Appendix D how one uses SDP [RFC4566] for describing the presentation.

この仕様は、付録Dで、プレゼンテーションの説明にSDP [RFC4566]をどのように使用するかを説明しています。

2.2. Session Establishment
2.2. セッションの確立

The RTSP client can request the establishment of an RTSP session after having used the presentation description to determine which media streams are available, which media delivery protocol is used, and the resource identifiers of the media streams. The RTSP session is a common context between the client and the server that consists of one or more media resources that are to be under common media delivery control.

RTSPクライアントは、プレゼンテーションの説明を使用して、使用可能なメディアストリーム、使用されているメディア配信プロトコル、およびメディアストリームのリソース識別子を確認した後、RTSPセッションの確立を要求できます。 RTSPセッションは、クライアントとサーバー間の共通のコンテキストであり、共通のメディア配信制御下にある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)は、現在利用可能なメディアの時間範囲についてクライアントに通知します。

2.3. Media Delivery Control
2.3. メディア配信制御

After having established an RTSP session, the client can start controlling the media delivery. The basic operations are "begin playback", using the PLAY method (Section 13.4) and "suspend (pause) playback" by using the PAUSE method (Section 13.6). PLAY also allows for choosing the starting media position from which the server should deliver the media. The positioning is done by using the Range header (Section 18.40) that supports several different time formats: Normal Play Time (NPT) (Section 4.4.2), Society of Motion Picture and Television Engineers (SMPTE) Timestamps (Section 4.4.1), and absolute time (Section 4.4.3). The Range header also allows the client to specify a position where delivery should end, thus allowing a specific interval to be delivered.

RTSPセッションを確立した後、クライアントはメディア配信の制御を開始できます。基本的な操作は、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.


When playing live content with no extra functions, such as recording, the client will receive the live media from the server after having sent a PLAY request. Seeking in such content is not possible as the server does not store it, but only forwards it from the source of the session. Thus, delivery continues until the client sends a PAUSE request, tears down the session, or the content ends.


For live sessions that are being recorded, the client will need to keep track of how the recording progresses. Upon session establishment, the client will learn the current duration of the recording from the Media-Range header. Because the recording is ongoing, the content grows in direct relation to the time passed. Therefore, each server's response to a PLAY request will contain the current Media-Range header. The server should also regularly send (approximately every 5 minutes) the current media range in a PLAY_NOTIFY request (Section 13.5.2). If the live transmission ends, the server must send a PLAY_NOTIFY request with the updated Media-Properties indicating that the content stopped being a recorded live session and instead became on-demand content; the request also contains the final media range. While the live delivery continues, the client can request to play the current live point by using the NPT timescale symbol "now", or it can request a specific point in the available content by an explicit range request for that point. If the requested point is outside of the available interval, the server will adjust the position to the closest available point, i.e., either at the beginning or the end.


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.


2.4. Session Parameter Manipulations
2.4. セッションパラメータの操作

A session may have additional state or functionality that affects how the server or client treats the session or content, how it functions, or feedback on how well the session works. Such extensions are not defined in this specification, but they may be covered in various extensions. RTSP has two methods for retrieving and setting parameter values on either the client or the server: GET_PARAMETER (Section 13.8) and SET_PARAMETER (Section 13.9). These methods carry the parameters in a message body of the appropriate format. One can also use headers to query state with the GET_PARAMETER method. As an 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)。

2.5. Media Delivery
2.5. メディア配信

This document specifies how media is delivered with RTP [RFC3550] over UDP [RFC768], TCP [RFC793], or the RTSP connection. Additional protocols may be specified in the future as needed.

このドキュメントでは、UDP [RFC768]、TCP [RFC793]、またはRTSP接続を介してRTP [RFC3550]でメディアを配信する方法を指定します。追加のプロトコルは、必要に応じて将来指定される可能性があります。

The usage of RTP as a media delivery protocol requires some additional information to function well. The PLAY response contains information to enable reliable and timely delivery of how a client should synchronize different sources in the different RTP sessions. It also provides a mapping between RTP timestamps and the content-time scale. When the server wants to notify the client about the completion of the media delivery, it sends a PLAY_NOTIFY request to the client. The PLAY_NOTIFY request includes information about the stream end, including the last RTP sequence number for each stream, thus enabling the client to empty the buffer smoothly.

メディア配信プロトコルとしてRTPを使用するには、適切に機能するためにいくつかの追加情報が必要です。 PLAY応答には、クライアントがさまざまなRTPセッションでさまざまなソースを同期する方法を確実かつタイムリーに配信できるようにするための情報が含まれています。また、RTPタイムスタンプとコンテンツ時間スケール間のマッピングも提供します。サーバーがメディア配信の完了についてクライアントに通知する場合、サーバーはクライアントにPLAY_NOTIFY要求を送信します。 PLAY_NOTIFYリクエストには、各ストリームの最後のRTPシーケンス番号など、ストリームの終了に関する情報が含まれているため、クライアントはバッファをスムーズに空にすることができます。

2.5.1. Media Delivery Manipulations
2.5.1. メディア配信操作

The basic playback functionality of RTSP enables delivery of a range of requested content to the client at the pace intended by the content's creator. However, RTSP can also manipulate the delivery to the client in two ways.


Scale: The ratio of media-content time delivered per unit of playback time.


Speed: The ratio of playback time delivered per unit of wallclock time.


Both affect the media delivery per time unit. However, they manipulate two independent timescales and the effects are possible to combine.


Scale (Section 18.46) is used for fast-forward or slow-motion control as it changes the amount of content timescale that should be played back per time unit. Scale > 1.0, means fast forward, e.g., scale = 2.0 results in that 2 seconds of content being played back every second of playback. Scale = 1.0 is the default value that is used if no scale is specified, i.e., playback at the content's original rate. Scale values between 0 and 1.0 provide for slow motion. Scale can be negative to allow for reverse playback in either regular pace (scale = -1.0), fast backwards (scale < -1.0), or slow-motion backwards (-1.0 < scale < 0). Scale = 0 would be equal to pause and is not allowed.

スケール(セクション18.46)は、時間単位ごとに再生されるコンテンツのタイムスケールの量を変更するため、早送りまたはスローモーション制御に使用されます。スケール> 1.0は、早送りを意味します。たとえば、スケール= 2.0の場合、再生の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.


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.


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.


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.


2.6. Session Maintenance and Termination
2.6. セッションの維持と終了

The session context that has been established is kept alive by having the client show liveness. This is done in two main ways:


o Media-transport protocol keep-alive. RTP Control Protocol (RTCP) may be used when using RTP.

o メディア転送プロトコルのキープアライブ。 RTPを使用する場合は、RTP制御プロトコル(RTCP)を使用できます。

o Any RTSP request referencing the session context.

o セッションコンテキストを参照するすべてのRTSP要求。

Section 10.5 discusses the methods for showing liveness in more depth. If the client fails to show liveness for more than the established session timeout value (normally 60 seconds), the server may terminate the context. Other values may be selected by the server through the inclusion of the timeout parameter in the session header.


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.


A client may keep the session alive indefinitely if allowed by the server; however, a client is advised to release the session context when an extended period of time without media delivery activity has passed. The client can re-establish the session context if required later. What constitutes an extended period of time is dependent on the client, server, and their usage. It is recommended that the client terminate the session before ten times the session timeout value has passed. A server may terminate the session after one session timeout period without any client activity beyond keep-alive. When a server terminates the session context, it does so by sending a TEARDOWN request indicating the reason.


A server can also request that the client tear down the session and re-establish it at an alternative server, as may be needed for maintenance. This is done by using the REDIRECT method (Section 13.10). The Terminate-Reason header (Section 18.52) is used to indicate when and why. The Location header indicates where it should connect if there is an alternative server available. When the deadline expires, the server simply stops providing the service. To achieve a clean closure, the client needs to initiate session termination prior to the deadline. In case the server has no other server to redirect to, and it wants to close the session for maintenance, it shall use the TEARDOWN method with a Terminate-Reason header.

サーバーは、メンテナンスに必要な場合があるため、クライアントにセッションを破棄し、代替サーバーでセッションを再確立するように要求することもできます。これはREDIRECTメソッド(セクション13.10)を使用して行われます。 Terminate-Reasonヘッダー(セクション18.52)は、いつ、なぜかを示すために使用されます。 Locationヘッダーは、使用可能な代替サーバーがある場合に接続する場所を示します。期限が切れると、サーバーは単にサービスの提供を停止します。クリーンなクロージャを実現するには、クライアントは期限前にセッションの終了を開始する必要があります。サーバーにリダイレクトする他のサーバーがなく、メンテナンスのためにセッションを閉じたい場合は、Terminate-Reasonヘッダーを指定したTEARDOWNメソッドを使用します。

2.7. Extending RTSP
2.7. RTSPの拡張

RTSP is quite a versatile protocol that supports extensions in many different directions. Even this core specification contains several blocks of functionality that are optional to implement. The use case and need for the protocol deployment should determine what parts are implemented. Allowing for extensions makes it possible for RTSP to address additional use cases. However, extensions will affect the interoperability of the protocol; therefore, it is important that they can be added in a structured way.


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.


The RTSP, in itself, can be extended in three ways, listed here in increasing order of the magnitude of changes supported:


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.


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.


3. Document Conventions
3. 文書規約
3.1. Notational Conventions
3.1. 表記規則

All the mechanisms specified in this document are described in both prose and the Augmented Backus-Naur form (ABNF) described in detail in [RFC5234].


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.


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


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.


3.2. Terminology
3.2. 用語

Aggregate control: The concept of controlling multiple streams using a single timeline, generally one maintained by the server. A client, for example, uses aggregate control when it issues a single play or pause message to simultaneously control both the audio and video in a movie. A session that is under aggregate control is referred to as an "aggregated session".


Aggregate control URI: The URI used in an RTSP request to refer to and control an aggregated session. It normally, but not always, corresponds to the presentation URI specified in the session description. See Section 13.3 for more information.


Client: The client is the requester of media service from the media server.


Connection: A transport-layer virtual circuit established between two programs for the purpose of communication.


Container file: A file that may contain multiple media streams that often constitute a presentation when played together. The concept of a container file is not embedded in the protocol. However, RTSP servers may offer aggregate control on the media streams within these files.


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.


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


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.


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.


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.


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 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です。

4. Protocol Parameters
4. プロトコルパラメータ
4.1. RTSP Version
4.1. RTSPバージョン

This specification defines version 2.0 of RTSP.


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)、受信者は無視する必要があります。

4.2. RTSP IRI and URI

RTSP 2.0 defines and registers or updates three URI schemes "rtsp", "rtsps", and "rtspu". The usage of the last, "rtspu", is unspecified in RTSP 2.0 and is defined here to register the URI scheme that was defined in RTSP 1.0. The "rtspu" scheme indicates unspecified transport of the RTSP messages over unreliable transport means (UDP in RTSP 1.0). An RTSP server MUST respond with an error code indicating the "rtspu" scheme is not implemented (501) to a request that carries a "rtspu" URI scheme.

RTSP 2.0は、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.


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.


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.


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:


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


Also, the RTSP URI:



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 "" and the whole presentation "".


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.


4.3. Session Identifiers
4.3. セッション識別子

Session identifiers are strings of a length between 8-128 characters. A session identifier MUST be generated using methods that make it cryptographically random (see [RFC4086]). It is RECOMMENDED that a session identifier contain 128 bits of entropy, i.e., approximately 22 characters from a high-quality generator (see Section 21). However, note that the session identifier does not provide any security against session hijacking unless it is kept confidential by the client, server, and trusted proxies.


4.4. Media-Time Formats
4.4. メディアタイム形式

RTSP currently supports three different media-time formats defined below. Additional time formats may be specified in the future. These time formats can be used with the Range header (Section 18.40) to request playback and specify at which media position protocol requests actually will or have taken place. They are also used in description of the media's properties using the Media-Range header (Section 18.30). The unqualified format identifier is used on its own in Accept-Ranges header (Section 18.5) to declare supported time formats and also in the Range header (Section 18.40) to request the time format used in the response.


4.4.1. SMPTE-Relative Timestamps
4.4.1. SMPTE相対タイムスタンプ

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]として表されます。タイムコードの形式は次のとおりです。


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フレームで測定されます。



4.4.2. Normal Play Time
4.4.2. 通常の再生時間

Normal Play Time (NPT) indicates the stream-absolute position relative to the beginning of the presentation. The timestamp consists of two parts: The mandatory first part may be expressed in either seconds only or in hours, minutes, and seconds. The optional second part consists of a decimal point and decimal figures and indicates fractions of a second.


The beginning of a presentation corresponds to 0.0 seconds. Negative values are not defined.


The special constant "now" is defined as the current instant of a live event. It MAY only be used for live events and MUST NOT be used for on-demand (i.e., non-live) content.


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タイムコードと同等です。




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 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 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表記は、人間の読者が使用できるように最適化されています。 「今」の定数により、クライアントは、保存されたバージョンや時間遅延されたバージョンではなく、ライブフィードの受信を要求できます。この場合、絶対時間もゼロ時間も適切ではないため、これが必要です。

4.4.3. Absolute Time
4.4.3. 絶対時間

Absolute time is expressed using a timestamp based on ISO 8601 [ISO.8601.2000]. The date is a complete representation of the calendar date in basic format (YYYYMMDD) without separators (per Section of [ISO.8601.2000]). The time of day is provided in the complete representation basic format (hhmmss) as specified in Section of [ISO.8601.2000], allowing decimal fractions of seconds following Section 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

4.5. Feature Tags
4.5. 機能タグ

Feature tags are unique identifiers used to designate features in RTSP. These tags are used in Require (Section 18.43), Proxy-Require (Section 18.37), Proxy-Supported (Section 18.38), Supported (Section 18.51), and Unsupported (Section 18.55) header fields.


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 "") or register the new feature tag with the Internet Assigned Numbers Authority (IANA). (See Section 22, "IANA Considerations".)

新しいRTSP機能タグの作成者は、機能タグの前に逆ドメイン名を付ける必要があります(たとえば、「com.example.mynewfeature」は、発明者が「」にアクセスできる機能の適切な名前です)または登録する必要があります。 Internet Assigned Numbers Authority(IANA)の新しい機能タグ。 (セクション22「IANAの考慮事項」を参照してください。)

The usage of feature tags is further described in Section 11, which deals with capability handling.


4.6. Message Body Tags
4.6. メッセージ本文タグ

Message body tags are opaque strings that are used to compare two message bodies from the same resource, for example, in caches or to optimize setup after a redirect. Message body tags can be carried in the MTag header (see Section 18.31) or in SDP (see Appendix D.1.9). MTag is similar to ETag in HTTP/1.1 (see Section 3.11 of [RFC2068]).

メッセージ本文タグは、たとえばキャッシュ内の同じリソースからの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.


Message body tags are used in RTSP to make some methods conditional. The methods are made conditional through the inclusion of headers; see Section 18.24 and Section 18.26 for information on the If-Match and If-None-Match headers, respectively. Note that RTSP message body tags apply to the complete presentation, i.e., both the presentation description and the individual media streams. Thus, message body tags can be used to verify at setup time after a redirect that the same session description applies to the media at the new location using the If-Match header.

メッセージ本文タグは、一部のメソッドを条件付きにするためにRTSPで使用されます。メソッドは、ヘッダーを含めることで条件付きになります。 If-MatchおよびIf-None-Matchヘッダーの詳細については、それぞれセクション18.24およびセクション18.26を参照してください。 RTSPメッセージ本文タグは、完全なプレゼンテーション、つまりプレゼンテーションの説明と個々のメディアストリームの両方に適用されることに注意してください。したがって、メッセージ本文タグは、リダイレクト後のセットアップ時に、同じセッションの説明がIf-Matchヘッダーを使用して新しい場所のメディアに適用されることを確認するために使用できます。

4.7. Media Properties
4.7. メディアのプロパティ

When an RTSP server handles media, it is important to consider the different properties a media instance for delivery and playback can have. This specification considers the media properties listed below in its protocol operations. They are derived from the differences between a number of supported usages.


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.


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.


Live: Live media represents a progressing content stream (such as broadcast TV) where the duration may or may not be known. It is not seekable, only the content presently being delivered can be accessed.


Live with Recording: A live stream that is combined with a server-side capability to store and retain the content of the live session and allow for random access delivery within the part of the already-recorded content. The actual behavior of the media stream is very much dependent on the retention policy for the media stream; either the server will be able to capture the complete media stream or it will have a limitation in how much will be retained. The media range will dynamically change as the session progress. For servers with a limited amount of storage available for recording, there will typically be a sliding window that moves forward while new data is made available and older data is discarded.


To cover the above usages, the following media properties with appropriate values are specified.


4.7.1. Random Access and Seeking
4.7.1. ランダムアクセスとシーク

Random access is the ability to specify and get media delivered starting from any time (instant) within the content, an operation called "seeking". The Media-Properties header will indicate the general capability for a media resource to perform random access.

ランダムアクセスとは、コンテンツ内でいつでも(瞬時に)メディアを指定して配信する機能で、「シーク」と呼ばれる操作です。 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).


4.7.2. Retention
4.7.2. 保持

The following retention policies are used by media to limit possible protocol operations:


Unlimited: The media will not be removed as long as the RTSP session is in existence.


Time-Limited: The media will not be removed before the given wallclock time. After that time, it may or may not be available anymore.


Time-Duration: The media (on fragment or unit basis) will be retained for the specified duration.


4.7.3. Content Modifications
4.7.3. コンテンツの変更

The media content and its timeline can be of different types, e.g. pre-produced content on demand, a live source that is being generated as time progresses, or something that is dynamically altered or recomposed during playback. Therefore, a media property for content modifications is needed and the following initial values are defined:


Immutable: The content of the media will not change, even if the representation, such as encoding or quality changes.


Dynamic: The content can change due to external methods or triggers, such as playlists, but this will be announced by explicit updates.


Time-Progressing: As time progresses, new content will become available. If the content is also retained, it will become longer as everything between the start point and the point currently being made available can be accessed. If the media server uses a sliding-window policy for retention, the start point will also change as time progresses.


4.7.4. Supported Scale Factors
4.7.4. サポートされる倍率

A particular media content item often supports only a limited set or range of scales when delivering the media. To enable the client to know what values or ranges of scale operations that the whole content or the current position supports, a media properties attribute for this is defined that contains a list with the values or ranges that are supported. The attribute is named "Scales". The "Scales" attribute may be updated at any point in the content due to content consisting of spliced pieces or content being dynamically updated by out-of-band mechanisms.

多くの場合、特定のメディアコンテンツアイテムは、メディアを配信するときに限られたセットまたは範囲のスケールのみをサポートします。コンテンツ全体または現在の位置がサポートするスケール操作の値または範囲をクライアントが認識できるようにするために、サポートされる値または範囲のリストを含む、このメディアプロパティ属性が定義されています。属性の名前は「スケール」です。 「スケール」属性は、スプライスされた断片から構成されるコンテンツまたは帯域外メカニズムによって動的に更新されるコンテンツが原因で、コンテンツの任意の時点で更新される可能性があります。

4.7.5. Mapping to the Attributes
4.7.5. 属性へのマッピング

This section shows examples of how one would map the above usages to the properties and their values.


Example of On-Demand: Random Access: Random-Access=5.0, Content Modifications: Immutable, Retention: Unlimited or Time-Limited.

オンデマンドの例:ランダムアクセス: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
5. RTSP Message
5. RTSPメッセージ

RTSP is a text-based protocol that uses the ISO 10646 character set in UTF-8 encoding per RFC 3629 [RFC3629]. Lines MUST be terminated by a CRLF.

RTSPは、RFC 3629 [RFC3629]に基づくUTF-8エンコーディングのISO 10646文字セットを使用するテキストベースのプロトコルです。行はCRLFで終了する必要があります。

Text-based protocols make it easier to add optional parameters in a self-describing manner. Since the number of parameters and the frequency of commands is low, processing efficiency is not a concern. Text-based protocols, if used carefully, also allow easy implementation of research prototypes in scripting languages such as Python, PHP, Perl and TCL.


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.


5.1. Message Types
5.1. メッセージの種類

RTSP messages are either requests from client to server or from server to client, and responses in the reverse direction. Request (Section 7) and response (Section 8) messages use a format based on the generic message format of RFC 5322 [RFC5322] for transferring bodies (the payload of the message). Both types of messages consist of a start-line, zero or more header fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the headers, and possibly the data of the message body. The ABNF [RFC5234] below is for illustration only; the formal message specification is presented in Section 20.2.2.

RTSPメッセージは、クライアントからサーバーまたはサーバーからクライアントへの要求であり、逆方向の応答です。要求(セクション7)および応答(セクション8)メッセージは、本文(メッセージのペイロード)の転送にRFC 5322 [RFC5322]の一般的なメッセージ形式に基づく形式を使用します。どちらのタイプのメッセージも、開始行、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.


5.2. Message Headers
5.2. メッセージヘッダー

RTSP header fields (see Section 18) include general-header, request-header, response-header, and message body header fields.

RTSPヘッダーフィールド(セクション18を参照)には、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)ヘッダーに含める必要があります。

5.3. Message Body
5.3. メッセージ本文

The message body (if any) of an RTSP message is used to carry further information for a particular resource associated with the request or response. An example of a message body is an SDP message.


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)。これは、将来の拡張でメッセージ本文のオプションの使用を定義できるようにするためです。

5.4. Message Length
5.4. メッセージの長さ

An RTSP message that does not contain any message body is terminated by the first empty line after the header fields (note: an empty line is a line with nothing preceding the CRLF.). In RTSP messages that contain message bodies, the empty line is followed by the message body. The length of that body is determined by the value of the Content-Length header (Section 18.17). The value in the header represents the length of the message body in octets. If this header field is not present, a value of zero is assumed, i.e., no message body present in the message. Unlike an HTTP message, an RTSP message MUST contain a Content-Length header whenever it contains a message body. Note that RTSP does not support the HTTP/1.1 "chunked" transfer coding (see Section 4.1 of [RFC7230]).

メッセージ本文を含まないRTSPメッセージは、ヘッダーフィールドの後の最初の空行で終了します(注:空行は、CRLFの前に何もない行です)。メッセージ本文を含むRTSPメッセージでは、空行の後にメッセージ本文が続きます。その本文の長さは、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.


6. General-Header Fields
6. General-Headerフィールド

General headers are headers that may be used in both requests and responses. The general-headers are listed in Table 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


7. Request
7. リクエスト

A request message uses the format outlined below regardless of the direction of a request, whether client to server or server to client:


o Request line, containing the method to be applied to the resource, the identifier of the resource, and the protocol version in use;

o リソースに適用されるメソッド、リソースの識別子、および使用中のプロトコルバージョンを含むリクエストライン。

o Zero or more Header lines, which can be of the following types: general-headers (Section 6), request-headers (Section 7.2), or message body headers (Section 9.1);

o ゼロ以上のヘッダー行。次のタイプがあります。一般ヘッダー(セクション6)、要求ヘッダー(セクション7.2)、またはメッセージ本文ヘッダー(セクション9.1)。

o One empty line (CRLF) to indicate the end of the header section;

o ヘッダーセクションの終わりを示す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メッセージヘッダーで示されます。

7.1. Request Line
7.1. リクエストライン

The request line provides the key information about the request: what method, on what resources, and using which RTSP version. The methods that are defined by this specification are listed in Table 2.


                    | 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


The syntax of the RTSP request line has the following:


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


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.


For example:



オプション* 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.


For example:


      OPTIONS rtsp:// RTSP/2.0
7.2. Request-Header Fields
7.2. リクエストヘッダーフィールド

The RTSP headers in Table 3 can be included in a request, as request-headers, to modify the specifics of the request.


                 | 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


Detailed header definitions are provided in Section 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.


8. Response
8. 応答

After receiving and interpreting a request message, the recipient responds with an RTSP response message. Normally, there is only one, final, response. Responses using the response code class 1xx is the only class for which there MAY be sent one or more responses prior to the final response message.


The valid response codes and the methods they can be used with are listed in Table 4.


8.1. Status-Line
8.1. ステータスライン

The first line of a response message is the Status-Line, consisting of the protocol version followed by a numeric status code and the textual phrase associated with the status code, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.


   <RTSP-Version> SP <Status-Code> SP <Reason Phrase> CRLF
8.1.1. Status Code and Reason Phrase
8.1.1. ステータスコードと理由フレーズ

The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes are fully defined in Section 17. The reason phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the reason phrase is intended for the human user. The client is not required to examine or display the reason phrase.


The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are five values for the first digit:


1xx: Informational - Request received, continuing process


2xx: Success - The action was successfully received, understood, and accepted


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)


4xx: Client Error - The request contains bad syntax or cannot be fulfilled


5xx: Server Error - The server failed to fulfill an apparently valid request


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


8.2. Response Headers
8.2. 応答ヘッダー

The response-headers allow the request recipient to pass additional information about the response that cannot be placed in the Status-Line. This header gives information about the server and about further access to the resource identified by the Request-URI. All headers currently classified as response-headers are listed in Table 5.


                | 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


Response-header names can be extended reliably only in combination with a change in the protocol version. However, the usage of feature tags in the request allows the responding party to learn the capability of the receiver of the response. A new or experimental header can be given the semantics of response-header if all parties in the communication recognize them to be a response-header. Unrecognized headers in responses MUST be ignored.


9. Message Body
9. メッセージ本文

Some request and response messages include a message body, if not otherwise restricted by the request method or response status code. The message body consists of the content data itself (see also Section 5.3).


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.


9.1. Message Body Header Fields
9.1. メッセージ本文のヘッダーフィールド

Message body header fields define meta-information about the content data in the message body. The message body header fields are listed in Table 6.


                   | 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


The extension-header mechanism allows additional message body header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields MUST be ignored by the recipient and forwarded by proxies.


9.2. Message Body
9.2. メッセージ本文

An RTSP message with a message body MUST include the Content-Type and Content-Length headers. When a message body is included with a message, the data type of that content data is determined via the Content-Type and Content-Encoding header fields.


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.


The Content-Length of a message is the length of the content, measured in octets.


9.3. Message Body Format Negotiation
9.3. メッセージ本文形式の交渉

The content format of the message body is provided using the Content-Type header (Section 18.19). To enable the responder of a request to determine which media type it should use, the requester may include the Accept header (Section 18.1) in a request to identify supported media types or media type ranges suitable to the response. In case the responder is not supporting any of the specified formats, then the request response will be a 406 (Not Acceptable) error code.

メッセージ本文のコンテンツ形式は、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).


The formats supported and their negotiation is done individually on a per method and direction (request or response body) direction. Requirements on supporting particular media types for use as message bodies in requests and response SHALL also be specified on a per-method and per-direction basis.


10. Connections
10. 接続

RTSP messages are transferred between RTSP agents and proxies using a transport connection. This transport connection uses TCP or TCP/TLS. This transport connection is referred to as the "connection" or "RTSP connection" within this document.

RTSPメッセージは、トランスポート接続を使用してRTSPエージェントとプロキシの間で転送されます。このトランスポート接続は、TCPまたはTCP / TLSを使用します。このトランスポート接続は、このドキュメントでは「接続」または「RTSP接続」と呼ばれます。

RTSP requests can be transmitted using the two different connection scenarios listed below:


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接続で複数のクライアント要求を集約するときに、さまざまな要求を追跡するプロキシでも役立ちます。

10.1. Reliability and Acknowledgements
10.1. 信頼性と謝辞

Since RTSP messages are transmitted using reliable transport protocols, they MUST NOT be retransmitted at the RTSP level. Instead, the implementation must rely on the underlying transport to 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.


Lack of acknowledgment of an RTSP request should be handled within the constraints of the connection timeout considerations described below (Section 10.4).


10.2. Using Connections
10.2. 接続の使用

A TCP transport can be used for both persistent connections (for several message exchanges) and transient connections (for a single message exchange). Implementations of this specification MUST support RTSP over TCP. The scheme of the RTSP URI (Section 4.2) allows the client to specify the port it will contact the server on, and defines the default port to use if one is not explicitly given.

TCPトランスポートは、永続的な接続(複数のメッセージ交換の場合)と一時的な接続(単一のメッセージ交換の場合)の両方に使用できます。この仕様の実装は、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.


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.


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.


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.


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.


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


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.


The reason for this is to avoid a head-of-line blocking situation. In a sequence of requests, an early outstanding request may take time to be processed at one destination. Simultaneously, a response from any other destination that was later in the sequence of requests may have arrived at the proxy; thus, allowing out-of-order responses avoids forcing the proxy to buffer this response and instead deliver it as soon as possible. Note, this will not affect the order in which the messages sent to each separate destination were processed at the request destination.


This scenario can occur in two cases involving proxies. The first is a client issuing requests for sessions on different servers using a common client-to-proxy connection. The second is for server-to-client requests, like REDIRECT being sent by the server over a common transport connection the proxy created for its different connecting clients.

このシナリオは、プロキシを含む2つのケースで発生する可能性があります。 1つ目は、クライアントからプロキシへの共通接続を使用して、さまざまなサーバー上のセッションに対する要求を発行するクライアントです。 2つ目は、サーバーからクライアントへのリクエスト用です。たとえば、リダイレクトは、さまざまな接続クライアント用にプロキシが作成した一般的なトランスポート接続を介してサーバーから送信されます。

10.3. Closing Connections
10.3. 接続を閉じる

The client MAY close a connection at any point when no outstanding request/response transactions exist for any RTSP session being managed through the connection. The server, however, SHOULD NOT close a connection until all RTSP sessions being managed through the connection have been timed out (Section 18.49). A server SHOULD NOT close a connection immediately after responding to a session-level TEARDOWN request for the last RTSP session being controlled through the connection. Instead, the server should wait for a reasonable amount of time for the client to receive and act upon the TEARDOWN response and then initiate the connection closing. The server SHOULD wait at least 10 seconds after sending the TEARDOWN response before closing the connection.


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


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.


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で定義されているように適切に終了します。

10.4. Timing Out Connections and RTSP Messages
10.4. 接続とRTSPメッセージのタイムアウト

Receivers of a request (responders) SHOULD respond to requests in a timely manner even when a reliable transport such as TCP is used. Similarly, the sender of a request (requester) SHOULD wait for a sufficient time for a response before concluding that the responder will not be acting upon its request.


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.


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秒の値はタイムアウトの半分であり、リクエスタ側でタイムアウトが発生する前に配信が成功する合理的な可能性があります。

10.5. Showing Liveness
10.5. 活気を示す

RTSP requires the client to periodically show its liveness to the server or the server may terminate any session state. Several different protocol mechanism include in their usage a liveness proof from the client. These mechanisms are RTSP requests with a Session header to the server; if RTP & RTCP is used for media data transport and the transport is established, the RTCP message proves liveness; or through any other used media-transport protocol capable of indicating liveness of the RTSP client. It is RECOMMENDED that a client not wait to the last second of the timeout before trying to send a liveness message. The RTSP message may take some time to arrive safely at the receiver, due to packet loss and TCP retransmissions. To show liveness between RTSP requests being issued to accomplish other things, the following mechanisms can be used, in descending order of preference:

RTSPでは、クライアントがサーバーにその活性を定期的に示す必要があります。そうしないと、サーバーがセッション状態を終了する場合があります。いくつかの異なるプロトコルメカニズムには、その使用法にクライアントからの生存証明が含まれています。これらのメカニズムは、サーバーへのセッションヘッダーを持つRTSP要求です。 RTPおよびRTCPがメディアデータトランスポートに使用され、トランスポートが確立されている場合、RTCPメッセージは活性を証明します。または、RTSPクライアントの活性を示すことができる他の使用されているメディア転送プロトコルを介して。クライアントが活性メッセージを送信する前に、タイムアウトの最後の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.


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秒です。確立されたセッションでは、セッションタイムアウトの長さを変更してはなりません。

10.6. Use of IPv6
10.6. IPv6の使用

Explicit IPv6 [RFC2460] support was not present in RTSP 1.0. RTSP 2.0 has been updated for explicit IPv6 support. Implementations of RTSP 2.0 MUST understand literal IPv6 addresses in URIs and RTSP headers. Although the general URI format envisages potential future new versions of the literal IP address, usage of any such new version would require other modifications to the RTSP specification (e.g., address fields in the Transport header (Section 18.54)).

明示的なIPv6 [RFC2460]サポートはRTSP 1.0には存在しませんでした。 RTSP 2.0は、明示的なIPv6サポートのために更新されました。 RTSP 2.0の実装は、URIおよびRTSPヘッダー内のリテラルIPv6アドレスを理解する必要があります。一般的なURI形式では、リテラルIPアドレスの将来の新しいバージョンが想定されていますが、そのような新しいバージョンを使用するには、RTSP仕様(トランスポートヘッダーのアドレスフィールド(セクション18.54)など)を変更する必要があります。

10.7. Overload Control
10.7. 過負荷制御

Overload in RTSP can occur when servers and proxies have insufficient resources to complete the processing of a request. An improper handling of such an overload situation at proxies and servers can impact the operation of the RTSP deployment, and probably worsen the situation. RTSP defines the 503 (Service Unavailable) response (Section 17.5.4) to let servers and proxies notify requesting proxies and RTSP clients about an overload situation. In conjunction with 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.


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倍の範囲内のランダムな値を選択する必要があります。

11. Capability Handling
11. 能力処理

This section describes the available capability-handling mechanism that allows RTSP to be extended. Extensions to this version of the protocol are basically done in two ways. Firstly, new headers can be added. Secondly, new methods can be added. The capability-handling mechanism is designed to handle both cases.


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.


Feature tags are used to determine whether the client, server, or proxy supports the functionality that is necessary to achieve the desired service. To determine support of a feature tag, several different headers can be used, each explained below:


Supported: This header is used to determine the complete set of functionality that both client and server have, in general, and is not dependent on a specific resource. The intended usage is to determine before one needs to use a functionality that it is supported. It can be used in any method, but OPTIONS is the most suitable as it simultaneously determines all methods that are implemented. When sending a request, the requester declares all its capabilities by including all supported feature tags. This results in the receiver learning the requester's feature support. The receiver then includes its set of features in the response.


Proxy-Supported: This header is used in a similar fashion as the Supported header, but instead of giving the supported functionality of the client or server, it provides both the requester and the responder a view of the common functionality supported in general by all members of the proxy chain between the client and server; it does not depend on the resource. Proxies are required to add this header whenever the Supported header is present, but proxies may also add it independently of the requester.


Require: This header can be included in any request where the endpoint, i.e., the client or server, is required to understand the feature to correctly perform the request. This can, for example, be a SETUP request, where the server is required to understand a certain parameter to be able to set up the media delivery correctly. Ignoring this parameter would not have the desired effect and is not acceptable. Therefore, the endpoint receiving a request containing a Require MUST negatively acknowledge any feature that it does not understand and not perform the request. The response in cases where features are not supported is 551 (Option Not Supported). Also, the features that are not supported are given in the Unsupported header in the response.


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.


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.


11.1. Feature Tag: play.basic
11.1. 機能タグ:play.basic

An implementation supporting all normative parts of this specification for the setup and control of playback of media uses the feature tag "play.basic" to indicate this support. The appendices (starting with letters) are not part of the functionality included in the feature tag unless the appendix is explicitly specified in a main section as being a required appendix.


Note: This feature tag does not mandate any media delivery protocol, such as 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の機能を明示的に列挙しようとするのではなく、この仕様は全体として解釈する必要があり、規範的に必要と定義されている必要な機能が含まれています。

12. Pipelining Support
12. パイプラインのサポート

Pipelining is a general method to improve performance of request/ response protocols by allowing the requesting agent to have more than one request outstanding and to send them over the same persistent connection. For RTSP, where the relative order of requests will matter, it is important to maintain the order of the requests. Because of this, the responding agent MUST process the incoming requests in their sending order. The sending order can be determined by the CSeq header and its sequence number. For TCP, the delivery order will be the same, between two agents, as the sending order. The processing of the request MUST also have been finished before processing the next request from the same agent. The responses MUST be sent in the order the requests were processed.

パイプライン処理は、要求側エージェントが複数の要求を未処理にして、同じ永続的な接続を介して送信できるようにすることで、要求/応答プロトコルのパフォーマンスを向上させる一般的な方法です。リクエストの相対的な順序が重要となるRTSPの場合、リクエストの順序を維持することが重要です。このため、応答するエージェントは受信リクエストを送信順に処理する必要があります。送信順序は、CSeqヘッダーとそのシーケンス番号によって決定できます。 TCPの場合、配信順序は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要求を修正してから、再生を要求できます。

13. Method Definitions
13. メソッドの定義

The method indicates what is to be performed on the resource identified by the Request-URI. The method name is case sensitive. New methods may be defined in the future. Method names MUST NOT start with a $ character (decimal 36) and MUST be a token as defined by the ABNF [RFC5234] in Section 20. The methods are summarized in Table 7.

このメソッドは、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


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.


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.


13.1. オプション

The semantics of the RTSP OPTIONS method is similar to that of the HTTP OPTIONS method described in Section 4.3.7 of [RFC7231]. However, in RTSP, OPTIONS is bidirectional in that a client can send the request to a server and vice versa. A client MUST implement the capability to send an OPTIONS request and a server or a proxy MUST implement the capability to respond to an OPTIONS request. In addition to this "MUST-implement" functionality, clients, servers and proxies MAY provide support both for sending OPTIONS requests and for generating responses to the requests.

RTSP OPTIONSメソッドのセマンティクスは、[RFC7231]のセクション4.3.7で説明されているHTTP OPTIONSメソッドのセマンティクスに似ています。ただし、RTSPでは、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)。



     C->S:  OPTIONS rtsp:// 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
            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.


13.2. 説明

The DESCRIBE method is used to retrieve the description of a presentation or media object from a server. The Request-URI of the DESCRIBE request identifies the media resource of interest. The client MAY include the Accept header in the request to list the description formats that it understands. The server MUST respond with a description of the requested resource and return the description in the message body of the response, if the DESCRIBE method request can be successfully fulfilled. The DESCRIBE reply-response pair constitutes the media initialization phase of RTSP.

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.




     C->S: DESCRIBE rtsp:// 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://
           Content-Type: application/sdp
           Content-Length: 358
           o=MNobody 2890844526 2890842807 IN IP4
           s=SDP Seminar
           i=A Seminar on the session description protocol
  (Seminar Management)
           c=IN IP4
           t=2873397496 2873404696
           m=audio 3456 RTP/AVP 0
           m=video 2232 RTP/AVP 31

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


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.


13.3. SETUP
13.3. セットアップ

The description below uses the following states in a protocol state machine that is related to a specific session when that session has been created. The state transitions are driven by protocol interactions. For additional information about the state machine, see Appendix B.


Init: Initial state. No session exists.


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.


For the benefit of any intervening firewalls, a client MUST indicate the known transport parameters, even if it has no influence over these parameters, for example, where the server advertises a fixed-multicast address as destination.


Since SETUP includes all transport initialization information, firewalls and other intermediate network devices (which need this information) are spared the more arduous task of parsing the DESCRIBE response, which has been reserved for media initialization.


The client MUST include the Accept-Ranges header in the request, indicating all supported unit formats in the Range header. This allows the server to know which formats it may use in future session-related responses, such as a PLAY response without any range in the request. If the client does not support a time format necessary for the presentation, the server MUST respond using 456 (Header Field Not Valid for Resource) and include the Accept-Ranges header with the range unit formats supported for the resource.


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.


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:// RTSP/2.0
           CSeq: 302
           Transport: RTP/AVP;unicast;dest_addr=":4588"/":4589",
           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=""/
                      ""; src_addr=""/
                      ""; ssrc=2A3F93ED
           Accept-Ranges: npt
           Media-Properties: Random-Access=3.2, Time-Progressing,
           Media-Range: npt=0-2893.23

In the above example, the client wants to create an RTSP session containing the media resource "rtsp://". The transport parameters acceptable to the client are either RTP/AVP/ UDP (UDP per default) to be received on client port 4588 and 4589 at the address the RTSP setup connection comes from or RTP/AVP interleaved on the RTSP control channel. The server selects the RTP/AVP/UDP transport and adds the address and ports it will send and receive RTP and RTCP from, and the RTP SSRC that will be used by the server.

上記の例では、クライアントはメディアリソース「rtsp://」を含むRTSPセッションを作成しようとしています。クライアントに受け入れられるトランスポートパラメータは、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.


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.


The SETUP of media streams in an aggregate that has not been given an aggregated control URI is unspecified.


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.


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.


13.3.1. Changing Transport Parameters
13.3.1. トランスポートパラメータの変更

A client MAY issue a SETUP request for a stream that is already set up or playing in the session to change transport parameters, which a server MAY allow. If it does not allow the changing of parameters, it MUST respond with error 455 (Method Not Valid in This State). The reasons to support changing transport parameters include allowing application-layer mobility and flexibility to utilize the best available transport as it becomes available. If a client receives a 455 error when trying to change transport parameters while the server is in Play state, it MAY try to put the server in Ready state using PAUSE before issuing the SETUP request again. If that also fails, the changing of transport parameters will require that the client perform a TEARDOWN of the affected media and then set it up again. For an aggregated session, not tearing down all the media at the same time will avoid the creation of a new session.


All transport parameters MAY be changed. However, the primary usage expected is to either change the transport protocol completely, like switching from Interleaved TCP mode to UDP or vice versa, or to change the delivery address.


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応答に含める必要があります。ただし、サーバーは、可能であれば同期情報の変更を避ける必要があります。

13.4. PLAY
13.4. 演奏する

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


13.4.1. General Usage
13.4.1. 一般的な使用法

The PLAY method tells the server to start sending data via the mechanism specified in SETUP and which part of the media should be played out. PLAY requests are valid when the session is in Ready or Play state. A PLAY request MUST include a Session header to indicate to which session the request applies.

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


request. The Seek-Style applied will affect the content of the Range header as it will be adjusted to indicate from what point the media actually is delivered.


A client desiring to play the media from the beginning MUST send a PLAY request with a Range header pointing at the beginning, e.g., "npt=0-". If a PLAY request is received without a Range header and media delivery has stopped at the end, the server SHOULD respond with a 457 (Invalid Range) error response. In that response, the current pause point MUST be included in a Range header.

最初からメディアを再生したいクライアントは、最初を指す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.


     C->S: PLAY rtsp:// 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.


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.


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:// 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
   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.


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.


   C->S: PLAY rtsp:// 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
   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.


   C->S: PLAY rtsp:// 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

For playing back a recording of a live presentation, it may be desirable to use clock units:


   C->S: PLAY rtsp:// 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
13.4.2. Aggregated Sessions
13.4.2. 集約されたセッション

PLAY requests can operate on sessions controlling a single media stream and on aggregated sessions controlling multiple media streams.


In an aggregated session, the PLAY request MUST contain an aggregated control URI. A server MUST respond with a 460 error (Only Aggregate Operation Allowed) if the client PLAY Request-URI is for a single media. The media in an aggregate MUST be played in sync. If a client wants individual control of the media, it needs to use separate RTSP sessions for each media.

集約セッションでは、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.


13.4.3. Updating Current PLAY Requests
13.4.3. 現在のPLAYリクエストの更新

Clients can issue PLAY requests while the stream is in Play state and thus updating their request.


The important difference compared to a PLAY request in Ready state is the handling of the current play point and how the Range header in the request is constructed. The session is actively playing media and the play point will be moving, making the exact time a request will take effect hard to predict. Depending on how the PLAY header appears, two different cases exist: total replacement or continuation. A total replacement is signaled by having the first range specification have an explicit start value, e.g., "npt=45-" or "npt=45-60", in which case the server stops playout at the current playout point and then starts delivering media according to the Range header. This is equivalent to having the client first send a PAUSE and then a new PLAY request that isn't based on the pause point. In the case of continuation, the first range specifier has an implicit start point and an explicit stop value (Z), e.g., "npt=-60", which indicate that it MUST convert the range specifier being played prior to this PLAY request (X to Y) into (X to Z) and continue as if this was the request originally played. If the current delivery point is beyond the stop point, the server SHALL immediately pause delivery. As the request has been completed successfully, it shall be responded to with a 200 OK response. A PLAY_NOTIFY with end-of-stream is also sent to indicate the actual stop point. The pause point is set to the requested stop point.

準備完了状態の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:// 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
     C->S: PLAY rtsp:// 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

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:// 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

[playing in fast forward and now returning to scale = 1]

[早送りで再生し、スケールに戻る= 1]

     C->S: PLAY rtsp:// 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
13.4.4. Playing On-Demand Media
13.4.4. オンデマンドメディアの再生

On-demand media is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29):


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.5. Playing Dynamic On-Demand Media
13.4.5. ダイナミックオンデマンドメディアの再生

Dynamic on-demand media is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29):


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.


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を参照)。

13.4.6. Playing Live Media
13.4.6. ライブメディアの再生

Live media is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29):


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ヘッダーを使用してサポートしている場合にのみ使用できます。

13.4.7. Playing Live with Recording
13.4.7. レコーディングでライブ演奏する

Certain media servers may offer recording services of live sessions to their clients. This recording would normally be from the beginning of the media session. Clients can randomly access the media between now and the beginning of the media session. This live media with recording is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29):


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の考慮事項が適用されます。

13.4.8. Playing Live with Time-Shift
13.4.8. タイムシフトでライブ演奏

Certain media servers may offer time-shift services to their clients. This time shift records a fixed interval in the past, i.e., a sliding window recording mechanism, but not past this interval. Clients can randomly access the media between now and the interval. This live media with recording is indicated by the content of the Media-Properties header in the SETUP response when (see also Section 18.29):


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 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 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:


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を参照)。

13.5.1. End-of-Stream
13.5.1. ストリームの終わり

A PLAY_NOTIFY request with the Notify-Reason header set to end-of-stream indicates the completion or near completion of the PLAY request and the ending delivery of the media stream(s). The request MUST NOT be issued unless the server is in the Play state. The end of the media stream delivery notification may be used either to indicate a successful completion of the PLAY request currently being served or to indicate some error resulting in failure to complete the request. The Request-Status header (Section 18.42) MUST be included to indicate which request the notification is for and its completion status. The message response status codes (Section 8.1.1) are used to indicate how the PLAY request concluded. The sender of a PLAY_NOTIFY MAY issue an updated PLAY_NOTIFY, in the case of a 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.


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.


This example request notifies the client about a future end-of-stream event:


     S->C: PLAY_NOTIFY rtsp:// RTSP/2.0
           CSeq: 854
           Notify-Reason: end-of-stream
           Request-Status: cseq=853 status=200 reason="OK"
           Range: npt=-145
           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
13.5.2. Media-Properties-Update
13.5.2. メディアプロパティの更新

A PLAY_NOTIFY request with a Notify-Reason header set to media-properties-update indicates an update of the media properties for the given session (see Section 18.29) or the available media range that can be played as indicated by the Media-Range header (Section 18.30). PLAY_NOTIFY requests with Notify-Reason header set to media-properties-update MUST include a Media-Properties and Date header and SHOULD include a Media-Range header. The Media-Properties header has session scope; thus, for aggregated sessions, the PLAY_NOTIFY request MUST use the aggregated control URI.

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.


The recommendation for sending updates every 5 minutes is due to any clock skew issues. In 5 minutes, the clock skew should not become too significant as this is not used for media playback and synchronization, it is only for determining which content is available to the user.

5分ごとに更新を送信することをお勧めするのは、クロックスキューの問題によるものです。 5分後、クロックスキューはメディアの再生と同期には使用されず、ユーザーが利用できるコンテンツを判別するためだけに使用されるため、あまり大きくなりすぎないはずです。

A PLAY_NOTIFY request with Notify-Reason header set to media-properties-update MUST NOT carry a message body.


    S->C: PLAY_NOTIFY rtsp:// 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
13.5.3. Scale-Change
13.5.3. スケール変更

The server may be forced to change the rate of media time per playback time when a client requests delivery using a scale (Section 18.46) value other than 1.0 (normal playback rate). For time-progressing media with some retention, i.e., the server stores already-sent content, a client requesting to play with scale values larger than 1 may catch up with the front end of the media. The server will then be unable to continue to provide content at scale larger than 1 as content is only made available by the server at scale = 1. Another case is when scale < 1 and the media retention is Time-Duration limited. In this case, the delivery point can reach the oldest media unit available, and further playback at this scale becomes impossible as there will be no media available. To avoid having the client lose any media, the scale will need to be adjusted to the same rate at which the media is removed from the storage buffer, commonly scale = 1.0.

クライアントが1.0(通常の再生レート)以外のスケール(18.46項)値を使用して配信を要求すると、サーバーは再生時間あたりのメディア時間のレートを強制的に変更する場合があります。ある程度保持されている、つまりサーバーがすでに送信されたコンテンツを保存している時間の経過するメディアの場合、1より大きいスケール値での再生を要求するクライアントは、メディアのフロントエンドに追いつく場合があります。その後、サーバーは1より大きいスケールでコンテンツを提供し続けることができなくなります。コンテンツがスケール1でのみサーバーによって利用可能になるためです。この場合、配信ポイントは利用可能な最も古いメディアユニットに到達する可能性があり、利用可能なメディアがないため、このスケールでのそれ以上の再生は不可能になります。クライアントがメディアを失うのを防ぐには、メディアがストレージバッファーから削除されるのと同じレートにスケールを調整する必要があります。通常は、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.


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.


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.


A PLAY_NOTIFY request with Notify-Reason header set to "Scale-Change" MUST NOT carry a message body.


     S->C: PLAY_NOTIFY rtsp:// 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://"
     C->S: RTSP/2.0 200 OK
           CSeq: 854
           User-Agent: PhonyClient/1.2
           Session: CDtUJfDQXJWtJ7Iqua2xOi
13.6. PAUSE
13.6. 一時停止

The PAUSE request causes the stream delivery to immediately be interrupted (halted). A PAUSE request MUST be made either with the aggregated control URI for aggregated sessions, resulting in all media being halted, or with the media URI for non-aggregated sessions. Any attempt to mute a single media with a PAUSE request in an aggregated session MUST be responded to with a 460 (Only Aggregate Operation Allowed) error. After resuming playback, synchronization of the tracks MUST be maintained. Any server resources are kept, though servers MAY close the session and free resources after being paused for the duration specified with the timeout parameter of the Session header in the SETUP message.

PAUSE要求は、ストリーム配信を即座に中断(停止)させます。 PAUSEリクエストは、集約されたセッションの集約された制御URIを使用して行われ、すべてのメディアが停止されるか、集約されていないセッションのメディアURIを使用する必要があります。集約セッションでPAUSE要求を使用して単一のメディアをミュートしようとする試みは、460(集約操作のみ許可)エラーで応答する必要があります。再生を再開した後、トラックの同期を維持する必要があります。サーバーリソースは保持されますが、サーバーはSETUPメッセージのセッションヘッダーのタイムアウトパラメータで指定された期間一時停止した後、セッションを閉じてリソースを解放する場合があります。



     C->S: PAUSE rtsp:// 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:// 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
           Session: OccldOFFq23KwjYpAnBbUr

After 11 seconds, i.e., at 21 seconds into the presentation:


     C->S: PAUSE rtsp:// 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:// 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:// 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
13.7. 取り壊す
13.7.1. Client to Server
13.7.1. クライアントからサーバーへ

The TEARDOWN client-to-server request stops the stream delivery for the given URI, freeing the resources associated with it. A TEARDOWN request can be performed on either an aggregated or a media control URI. However, some restrictions apply depending on the current state. The TEARDOWN request MUST contain a Session header indicating to what session the request applies. The TEARDOWN request MUST NOT include a Terminate-Reason header.

クライアントからサーバーへの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.


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.




     C->S: TEARDOWN rtsp:// 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
13.7.2. Server to Client
13.7.2. サーバーからクライアント

The server can send TEARDOWN requests in the server-to-client direction to indicate that the server has been forced to terminate the ongoing session. This may happen for several reasons, such as server maintenance without available backup, or that the session has been inactive for extended periods of time. The reason is provided in the Terminate-Reason header (Section 18.52).


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.


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.


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.


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ヘッダーを使用することをお勧めします。このため、通常は、ヘッダーを使用するよりも、取得するパラメーターを本文で送信する方が簡単です。



     S->C: GET_PARAMETER rtsp:// RTSP/2.0
           CSeq: 431
           User-Agent: PhonyClient/1.2
           Session: OccldOFFq23KwjYpAnBbUr
           Content-Length: 26
           Content-Type: text/parameters

packets_received jitter


     C->S: RTSP/2.0 200 OK
           CSeq: 431
           Session: OccldOFFq23KwjYpAnBbUr
           Server: PhonyServer/1.1
           Date: Mon, 08 Mar 2010 13:43:23 GMT
           Content-Length: 38
           Content-Type: text/parameters

packets_received: 10 jitter: 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.


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.


Note: transport parameters for the media stream MUST only be set with the SETUP command.


Restricting setting transport parameters to SETUP is for the benefit of firewalls connected to border RTSP proxies.


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.




     C->S: SET_PARAMETER rtsp:// 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


     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


13.10. リダイレクト

The REDIRECT method is issued by a server to inform a client that the service provided will be terminated and where a corresponding service can be provided instead. This may happen for different reasons. One is that the server is being administered such that it must stop providing service. Thus, the client is required to connect to another server location to access the resource indicated by the Request-URI.

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.


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.


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.


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.


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.


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.


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.


This example request redirects traffic for this session to the new server at the given absolute time:


     S->C: REDIRECT rtsp:// RTSP/2.0
           CSeq: 732
           Location: rtsp://
           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
14. Embedded (Interleaved) Binary Data
14. 埋め込まれた(インターリーブされた)バイナリデータ

In order to fulfill certain requirements on the network side, e.g., in conjunction with network address translators that block RTP traffic over UDP, it may be necessary to interleave RTSP messages and media-stream data. This interleaving should generally be avoided unless necessary since it complicates client and server operation and imposes additional overhead. Also, head-of-line blocking may cause problems. Interleaved binary data SHOULD only be used if RTSP is carried over TCP. Interleaved data is not allowed inside RTSP messages.


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.


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.


       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


The channel identifier is defined in the Transport header with the interleaved parameter (Section 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:// 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:// 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://"
           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}
15. Proxies
15. プロキシ

RTSP Proxies are RTSP agents that are located in between a client and a server. A proxy can take on the roles of both client and server depending on what it tries to accomplish. RTSP proxies use two transport-layer connections: one from the RTSP client to the RTSP proxy and a second from the RTSP proxy to the RTSP server. Proxies are introduced for several different reasons; those listed below are often combined.

RTSPプロキシは、クライアントとサーバーの間にあるRTSPエージェントです。プロキシは、何を達成しようとしているかに応じて、クライアントとサーバーの両方の役割を担うことができます。 RTSPプロキシは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.


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.


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.


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.


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の将来の開発と使用を妨げます。

15.1. Proxies and Protocol Extensions
15.1. プロキシとプロトコル拡張

The existence of proxies must always be considered when developing new RTSP extensions. Most types of proxies will need to implement any new method to operate correctly in the presence of that extension. New headers can be introduced and will not be blocked by older proxies. However, it is important to consider if this header and its function are required to be understood by the proxy or if it can be simply forwarded. If the header needs to be understood, a feature tag representing the functionality MUST be included in the Proxy-Require header. Below are guidelines for analysis whether the header needs to be understood. The Transport header and its parameters are extensible, which requires handling rules for a proxy in order to ensure a correct interpretation.


Whether or not a proxy needs to understand a header is not easy to determine as they serve a broad variety of functions. When evaluating if a header needs to be understood, one can divide the functionality into three main categories:


Media modifying: The caching and translator proxies modify the actual media and therefore need also to understand the request directed to the server that affects how the media is rendered. Thus, this type of proxy also needs to understand the server-side functionality.


Transport modifying: The access and the security proxy both need to understand how the media transport is performed, either for opening pinholes or translating the outer headers, e.g., IP and UDP or TCP.


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.


An extension has to be classified as mandatory to be implemented for a proxy, if an extension has to be understood by a "Transport modifying" type of proxy.


15.2. Multiplexing and Demultiplexing of Messages
15.2. メッセージの多重化と逆多重化

RTSP proxies may have to multiplex several RTSP sessions from their clients towards RTSP servers. This requires that RTSP requests from multiple clients be multiplexed onto a common connection for requests outgoing to an RTSP server, and, on the way back, the responses be demultiplexed from the server to per-client responses. On the protocol level, this requires that request and response messages be handled in both directions, requiring that there be a mechanism to correlate which request/response pair exchanged between proxy and server is mapped to which client (or client request).


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.


16. Caching
16. キャッシング

In HTTP, request/response pairs are cached. RTSP differs significantly in that respect. Responses are not cacheable, with the exception of the presentation description returned by DESCRIBE. (Since the responses for anything but DESCRIBE and GET_PARAMETER do not return any data, caching is not really an issue for these requests.) However, it is desirable for the continuous media data, typically delivered out-of-band with respect to RTSP, to be cached, as well as the session description.

HTTPでは、要求/応答のペアがキャッシュされます。 RTSPはその点で大きく異なります。 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.


To the client, an RTSP proxy cache appears like a regular media server. To the media origin server, an RTSP proxy cache appears like a client. Just as an HTTP cache has to store the content type, content language, and so on for the objects it caches, a media cache has to store the presentation description. Typically, a cache eliminates all transport references (e.g., multicast information) from the presentation description, since these are independent of the data delivery from the cache to the client. Information on the encodings remains the same. If the cache is able to translate the cached media data, it would create a new presentation description with all the encoding possibilities it can offer.

クライアントにとって、RTSPプロキシキャッシュは通常のメディアサーバーのように見えます。メディアオリジンサーバーにとって、RTSPプロキシキャッシュはクライアントのように見えます。 HTTPキャッシュがキャッシュするオブジェクトのコンテンツタイプ、コンテンツ言語などを格納する必要があるのと同様に、メディアキャッシュはプレゼンテーションの説明を格納する必要があります。通常、キャッシュは、トランスポート参照(マルチキャスト情報など)をすべてキャッシュからクライアントへのデータ配信とは独立しているため、プレゼンテーションの説明から削除します。エンコーディングに関する情報は変わりません。キャッシュがキャッシュされたメディアデータを変換できる場合、提供できるすべてのエンコーディングの可能性を備えた新しいプレゼンテーションの説明が作成されます。

16.1. Validation Model
16.1. 検証モデル

When a cache has a stale entry that it would like to use as a response to a client's request, it first has to check with the origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable. This is called "validating" the cache entry. To avoid having to pay the overhead of retransmitting the full response if the cached entry is good, and at the same time avoiding having to pay the overhead of an extra round trip if the cached entry is invalid, RTSP supports the use of conditional methods.


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.


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.


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.


Media streams that are being adapted based on the transport capacity between the server and the cache make caching more difficult. A server needs to consider how it views the caching of media streams that it adapts and potentially instruct any caches not to cache such streams.


16.1.1. Last-Modified Dates
16.1.1. 最終更新日

The Last-Modified header (Section 18.27) value is often used as a cache validator. In simple terms, a cache entry is considered to be valid if the cache entry was created after the Last-Modified time.


16.1.2. Message Body Tag Cache Validators
16.1.2. メッセージ本文タグキャッシュバリデーター

The MTag response-header field-value, a message body tag, provides for an "opaque" cache validator. This might allow more reliable validation in situations where it is inconvenient to store modification dates, where the one-second resolution of RTSP-date values is not sufficient, or where the origin server wishes to avoid certain paradoxes that might arise from the use of modification dates.


Message body tags are described in Section 4.6


16.1.3. Weak and Strong Validators
16.1.3. 弱くて強いバリデーター

Since both origin servers and caches will compare two validators to decide if they represent the same or different entities, one normally would expect that if the message body (i.e., the presentation description) or any associated message body headers changes in any way, then the associated validator would change as well. If this is true, then this validator is a "strong validator". The Message body (i.e., the presentation description) or any associated message body headers is named an entity for a better understanding.


However, there might be cases when a server prefers to change the validator only on semantically significant changes and not when insignificant aspects of the entity change. A validator that does not always change when the resource changes is a "weak validator".


Message body tags are normally strong validators, but the protocol provides a mechanism to tag a message body tag as "weak". One can think of a strong validator as one that changes whenever the bits of an entity changes, while a weak value changes whenever the meaning of an entity changes. Alternatively, one can think of a strong validator as part of an identifier for a specific entity, while a weak validator is part of an identifier for a set of semantically equivalent entities.


Note: One example of a strong validator is an integer that is incremented in stable storage every time an entity is changed.


An entity's modification time, if represented with one-second resolution, could be a weak validator, since it is possible that the resource might be modified twice during a single second.


Support for weak validators is optional. However, weak validators allow for more efficient caching of equivalent objects.


A "use" of a validator is either when a client generates a request and includes the validator in a validating header field or when a server compares two validators.


Strong validators are usable in any context. Weak validators are only usable in contexts that do not depend on exact equality of an entity. For example, either kind is usable for a conditional DESCRIBE of a full entity. However, only a strong validator is usable for a subrange retrieval, since otherwise the client might end up with an internally inconsistent entity.


Clients MAY issue DESCRIBE requests with either weak or strong validators. Clients MUST NOT use weak validators in other forms of requests.


The only function that RTSP defines on validators is comparison. There are two validator comparison functions, depending on whether or not the comparison context allows the use of weak validators:


o The strong comparison function: in order to be considered equal, both validators MUST be identical in every way, and both MUST NOT be weak.

o 強力な比較関数:等しいと見なされるためには、両方のバリデーターがあらゆる点で同一である必要があり、両方が弱いことはありません。

o The weak comparison function: in order to be considered equal, both validators MUST be identical in every way, but either or both of them MAY be tagged as "weak" without affecting the result.

o 弱い比較関数:等しいと見なされるためには、両方のバリデーターはあらゆる点で同一である必要がありますが、結果に影響を与えることなく、どちらかまたは両方に「弱い」というタグを付けることができます。

A message body tag is strong unless it is explicitly tagged as weak.


A Last-Modified time, when used as a validator in a request, is implicitly weak unless it is possible to deduce that it is strong, using the following rules:


o The validator is being compared by an origin server to the actual current validator for the entity and,

o バリデーターは、起点サーバーによってエンティティーの実際の現在のバリデーターと比較され、

o That origin server reliably knows that the associated entity did not change more than once during the second covered by the presented validator.

o その起点サーバーは、関連するエンティティーが、提示されたバリデーターでカバーされる2番目の間に2回以上変更されなかったことを確実に認識しています。



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秒前です。



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.


16.1.4. Rules for When to Use Message Body Tags and Last-Modified Dates
16.1.4. メッセージ本文タグと最終更新日をいつ使用するかのルール

This document adopts a set of rules and recommendations for origin servers, clients, and caches regarding when various validator types ought to be used, and for what purposes.


RTSP origin servers:


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.


Note: in order to provide semantically transparent caching, an origin server MUST avoid reusing a specific strong message body tag value for two different entities or reusing a specific weak message body tag value for two semantically different entities. Cache entries might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to expect that a cache will never again attempt to validate an entry using a validator that it obtained at some point in the past.


RTSP clients:


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.


16.1.5. Non-validating Conditionals
16.1.5. 非検証条件

The principle behind message body tags is that only the service author knows the semantics of a resource well enough to select an appropriate cache validation mechanism, and the specification of any validator comparison function more complex than octet equality would open up a can of worms. Thus, comparisons of any other headers are never used for purposes of validating a cache entry.


16.2. Invalidation after Updates or Deletions
16.2. 更新または削除後の無効化

The effect of certain methods performed on a resource at the origin server might cause one or more existing cache entries to become non-transparently invalid. That is, although they might continue to be "fresh," they do not accurately reflect what the origin server would return for a new request on that resource.


There is no way for RTSP to guarantee that all such cache entries are marked invalid. For example, the request that caused the change at the origin server might not have gone through the proxy where a cache entry is stored. However, several rules help reduce the likelihood of erroneous behavior.


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:



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.


17. Status Code Definitions
17. ステータスコードの定義

Where applicable, HTTP status codes (see Section 6 of [RFC7231]) are reused. See Table 4 in Section 8.1 for a listing of which status codes may be returned by which requests. All error messages, 4xx and 5xx, MAY return a body containing further information about the error.


17.1. Informational 1xx
17.1. 情報1xx
17.1.1. 100 Continue
17.1.1. 100続行

The requesting agent SHOULD continue with its request. This interim response is used to inform the requesting agent that the initial part of the request has been received and has not yet been rejected by the responding agent. The requesting agent SHOULD continue by sending the remainder of the request or, if the request has already been completed, continue to wait for a final response (see Section 10.4). The responding agent MUST send a final response after the request has been completed.


17.2. Success 2xx
17.2. 成功2xx

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


17.2.1. 200 OK
17.2.1. 200 OK

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


17.3. Redirection 3xx
17.3. リダイレクト3xx

The notation "3xx" indicates response codes from 300 to 399 inclusive that are meant for redirection. We use the notation "3rr" to indicate all 3xx codes used for redirection, i.e., excluding 304. The 304 response code appears here, rather than a 2xx response code, which would have been appropriate; 304 has also been used in RTSP 1.0 [RFC2326].

「3xx」という表記は、リダイレクト用の300〜399の応答コードを示します。 「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.


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


17.3.1. 300
17.3.1. 300

The 300 response code is not used in RTSP 2.0.

300応答コードはRTSP 2.0では使用されません。

17.3.2. 301 Moved Permanently
17.3.2. 301永久に移動

The requested resource is moved permanently and resides now at the URI given by the Location header. The user agent SHOULD redirect automatically to the given URI. This response MUST NOT contain a message body. The Location header MUST be included in the response.

要求されたリソースは永続的に移動され、Locationヘッダーで指定されたURIに常駐します。ユーザーエージェントは、指定されたURIに自動的にリダイレクトする必要があります(SHOULD)。この応答にメッセージ本文を含めることはできません。 Locationヘッダーを応答に含める必要があります。

17.3.3. 302 Found
17.3.3. 302見つかりました

The requested resource resides temporarily at the URI given by the Location header. This response is intended to be used for many types of temporary redirects, e.g., load balancing. It is RECOMMENDED that the server set the reason phrase to something more meaningful than "Found" in these cases. The Location header MUST be included in the response. The user agent SHOULD redirect automatically to the given URI. This response MUST NOT contain a message body.

要求されたリソースは、Locationヘッダーで指定されたURIに一時的に存在します。この応答は、ロードバランシングなど、多くのタイプの一時的なリダイレクトに使用することを目的としています。これらのケースでは、サーバーが理由フレーズを「検出」よりも意味のあるものに設定することをお勧めします。 Locationヘッダーを応答に含める必要があります。ユーザーエージェントは、指定されたURIに自動的にリダイレクトする必要があります(SHOULD)。この応答にメッセージ本文を含めることはできません。

This example shows a client being redirected to a different server:


     C->S: SETUP rtsp:// 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://
17.3.4. 303 See Other
17.3.4. 303他を見る

This status code MUST NOT be used in RTSP 2.0. However, it was allowed in RTSP 1.0 [RFC2326].

このステータスコードは、RTSP 2.0では使用してはなりません(MUST NOT)。ただし、RTSP 1.0 [RFC2326]では許可されていました。

17.3.5. 304 Not Modified
17.3.5. 304変更されていません

If the agent has performed a conditional DESCRIBE or SETUP (see Sections 18.25 and 18.26) and the requested resource has not been modified, the server SHOULD send a 304 response. This response MUST NOT contain a message body.


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をこの方法でリンクできます。

17.3.6. 305 Use Proxy
17.3.6. 305プロキシを使用

The requested resource MUST be accessed through the proxy given by the Location header that MUST be included. The Location header field-value gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 responses MUST only be generated by origin servers.

要求されたリソースは、必ず含める必要があるLocationヘッダーで指定されたプロキシを介してアクセスする必要があります。 Locationヘッダーのフィールド値は、プロキシのURIを示します。受信者は、プロキシ経由でこの単一の要求を繰り返すことが期待されています。 305応答は、オリジンサーバーによってのみ生成される必要があります。

17.4. Client Error 4xx
17.4. クライアントエラー4xx
17.4.1. 400 Bad Request
17.4.1. 400不正な要求

The request could not be understood by the agent due to malformed syntax. The agent SHOULD NOT repeat the request without modifications. If the request does not have a CSeq header, the agent MUST NOT include a CSeq in the response.

不正な構文のため、リクエストはエージェントによって理解されませんでした。エージェントは変更なしでリクエストを繰り返すべきではありません。要求にCSeqヘッダーがない場合、エージェントはCSeqを応答に含めてはなりません(MUST NOT)。

17.4.2. 401 Unauthorized
17.4.2. 401無許可

The request requires user authentication using the HTTP authentication mechanism [RFC7235]. The usage of the error code is defined in [RFC7235] and any applicable HTTP authentication scheme, such as Digest [RFC7616]. The response is to include a WWW-Authenticate header (Section 18.58) field containing a challenge applicable to the requested resource. The agent can repeat the request with a suitable Authorization header field. If the request already included authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the message body that was given in the response, since that message body might include relevant diagnostic information.

リクエストには、HTTP認証メカニズム[RFC7235]を使用したユーザー認証が必要です。エラーコードの使用法は、[RFC7235]およびダイジェスト[RFC7616]などの該当するHTTP認証スキームで定義されています。応答には、要求されたリソースに適用可能なチャレンジを含むWWW-Authenticateヘッダー(セクション18.58)フィールドが含まれます。エージェントは、適切なAuthorizationヘッダーフィールドを使用して要求を繰り返すことができます。リクエストにすでに認証情報が含まれている場合、401レスポンスは、それらの認証情報に対する認証が拒否されたことを示します。 401応答に前の応答と同じチャレンジが含まれていて、ユーザーエージェントが少なくとも1回は認証をすでに試みている場合は、応答で指定されたメッセージ本文をユーザーに提示する必要があります(そのメッセージ本文には関連する診断情報が含まれる可能性があるため) 。

17.4.3. 402 Payment Required
17.4.3. 402支払いが必要

This code is reserved for future use.


17.4.4. 403 Forbidden
17.4.4. 403禁止します

The agent understood the request, but is refusing to fulfill it. Authorization will not help, and the request SHOULD NOT be repeated. If the agent wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the message body. If the agent does not wish to make this information available to the agent, the status code 404 (Not Found) can be used instead.


17.4.5. 404 Not Found
17.4.5. 404お探しのページが見つかりませんでした

The agent has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the agent knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address.

エージェントは、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.


17.4.6. 405 Method Not Allowed
17.4.6. 405メソッドは許可されていません

The method specified in the request is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource. This status code is also to be used if a request attempts to use a method not indicated during SETUP.


17.4.7. 406 Not Acceptable
17.4.7. 406受け入れ不可

The resource identified by the request is only capable of generating response message bodies that have content characteristics not acceptable according to the Accept headers sent in the request.


The response SHOULD include a message body containing a list of available message body characteristics and location(s) from which the user or user agent can choose the one most appropriate. The message body format is specified by the media type given in the Content-Type header field. Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice MAY be performed automatically. However, this specification does not define any standard for such automatic selection.


If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.


17.4.8. 407 Proxy Authentication Required
17.4.8. 407プロキシ認証が必要です

This code is similar to 401 (Unauthorized) (Section 17.4.2), but it indicates that the client must first authenticate itself with the proxy. The usage of this error code is defined in [RFC7235] and any applicable HTTP authentication scheme, such as Digest [RFC7616]. The proxy MUST return a Proxy-Authenticate header field (Section 18.34) containing a challenge applicable to the proxy for the requested resource.


17.4.9. 408 Request Timeout
17.4.9. 408リクエストのタイムアウト

The agent did not produce a request within the time that the agent was prepared to wait. The agent MAY repeat the request without modifications at any later time.


17.4.10. 410 Gone
17.4.10. 410なくなった

The requested resource is no longer available at the server and the forwarding address is not known. This condition is expected to be considered permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. This response is cacheable unless indicated otherwise.


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.


17.4.11. 412 Precondition Failed
17.4.11. 412前提条件が満たされていません

The precondition given in one or more of the 'if-' request-header fields evaluated to false when it was tested on the agent. See these sections for the 'if-' headers: If-Match Section 18.24, If-Modified-Since Section 18.25, and If-None-Match Section 18.26. This response code allows the agent to place preconditions on the current resource meta-information (header field data) and, thus, prevent the requested method from being applied to a resource other than the one intended.

1つ以上の「if-」リクエストヘッダーフィールドに指定された前提条件が、エージェントでテストされたときにfalseと評価されました。 「if-」ヘッダーについては、以下のセクションを参照してください。If-Matchセクション18.24、If-Modified-Sinceセクション18.25、およびIf-None-Matchセクション18.26。この応答コードにより、エージェントは現在のリソースメタ情報(ヘッダーフィールドデータ)に前提条件を設定できるため、要求されたメソッドが意図したもの以外のリソースに適用されるのを防ぐことができます。

17.4.12. 413 Request Message Body Too Large
17.4.12. 413リクエストメッセージ本文が大きすぎます

The agent is refusing to process a request because the request message body is larger than the agent is willing or able to process. The agent MAY close the connection to prevent the requesting agent from continuing the request.


If the condition is temporary, the agent SHOULD include a Retry-After header field to indicate that it is temporary and after what time the requesting agent MAY try again.


17.4.13. 414 Request-URI Too Long
17.4.13. 414 Request-URIが長すぎる

The responding agent is refusing to service the request because the Request-URI is longer than the agent is willing to interpret. This rare condition is only likely to occur when an agent has used a request with long query information, when the agent has descended into a URI "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the agent is under attack by an agent attempting to exploit security holes present in some agents using fixed-length buffers for reading or manipulating the Request-URI.


17.4.14. 415 Unsupported Media Type
17.4.14. 415サポートされていないメディアタイプ

The server is refusing to service the request because the message body of the request is in a format not supported by the requested resource for the requested method.


17.4.15. 451 Parameter Not Understood
17.4.15. 451パラメータが理解されていません

The recipient of the request does not support one or more parameters contained in the request. When returning this error message the agent SHOULD return a message body containing the offending parameter(s).


17.4.16. 452 Illegal Conference Identifier
17.4.16. 452違法な会議識別子

This status code MUST NOT be used in RTSP 2.0. However, it was allowed in RTSP 1.0 [RFC2326].

このステータスコードは、RTSP 2.0では使用してはなりません(MUST NOT)。ただし、RTSP 1.0 [RFC2326]では許可されていました。

17.4.17. 453 Not Enough Bandwidth
17.4.17. 453帯域幅が不十分です

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


17.4.18. 454 Session Not Found
17.4.18. 454セッションが見つかりません

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


17.4.19. 455 Method Not Valid in This State
17.4.19. この状態では455メソッドは無効です

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


17.4.20. 456 Header Field Not Valid for Resource
17.4.20. 456ヘッダーフィールドがリソースに対して無効です

The targeted agent could not act on a required request-header. For example, if PLAY request contains the Range header field but the stream does not allow seeking. This error message may also be used for specifying when the time format in Range is impossible for the resource. In that case, the Accept-Ranges header MUST be returned to inform the agent of which formats are allowed.


17.4.21. 457 Invalid Range
17.4.21. 457無効な範囲

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


17.4.22. 458 Parameter Is Read-Only
17.4.22. 458パラメータは読み取り専用です

The parameter to be set by SET_PARAMETER can be read but not modified. When returning this error message, the sender SHOULD return a message body containing the offending parameter(s).


17.4.23. 459 Aggregate Operation Not Allowed
17.4.23. 459集計操作は許可されていません

The requested method may not be applied on the URI in question since it is an aggregate (presentation) URI. The method may be applied on a media URI.


17.4.24. 460 Only Aggregate Operation Allowed
17.4.24. 460集約操作のみ許可

The requested method may not be applied on the URI in question since it is not an aggregate control (presentation) URI. The method may be applied on the aggregate control URI.


17.4.25. 461 Unsupported Transport
17.4.25. 461サポートされていないトランスポート

The Transport field did not contain a supported transport specification.


17.4.26. 462 Destination Unreachable
17.4.26. 462宛先に到達できません

The data transmission channel could not be established because the agent address could not be reached. This error will most likely be the result of an agent attempt to place an invalid dest_addr parameter in the Transport field.


17.4.27. 463 Destination Prohibited
17.4.27. 463宛先禁止

The data transmission channel was not established because the server prohibited access to the agent address. This error is most likely the result of an agent attempt to redirect media traffic to another destination with a dest_addr parameter in the Transport header.


17.4.28. 464 Data Transport Not Ready Yet
17.4.28. 464データ転送はまだ準備ができていません

The data transmission channel to the media destination is not yet ready for carrying data. However, the responding agent still expects that the data transmission channel will be established at some point in time. Note, however, that this may result in a permanent failure like 462 (Destination Unreachable).

メディア宛先へのデータ伝送チャネルは、まだデータを伝送する準備ができていません。ただし、応答エージェントは、データ送信チャネルがいずれかの時点で確立されることを期待しています。ただし、これにより462(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.


17.4.29. 465 Notification Reason Unknown
17.4.29. 465通知理由不明

This indicates that the client has received a PLAY_NOTIFY (Section 13.5) with a Notify-Reason header (Section 18.32) unknown to the client.


17.4.30. 466 Key Management Error
17.4.30. 466キー管理エラー

This indicates that there has been an error in a Key Management function used in conjunction with a request. For example, usage of Multimedia Internet KEYing (MIKEY) [RFC3830] according to Appendix C.1.4.1 may result in this error.


17.4.31. 470 Connection Authorization Required
17.4.31. 470接続認証が必要です

The secured connection attempt needs user or client authorization before proceeding. The next hop's certificate is included in this response in the Accept-Credentials header.


17.4.32. 471 Connection Credentials Not Accepted
17.4.32. 471接続資格情報が受け入れられない

When performing a secure connection over multiple connections, an intermediary has refused to connect to the next hop and carry out the request due to unacceptable credentials for the used policy.


17.4.33. 472 Failure to Establish Secure Connection
17.4.33. 472安全な接続の確立の失敗

A proxy fails to establish a secure connection to the next-hop RTSP agent. This is primarily caused by a fatal failure at the TLS handshake, for example, due to the agent not accepting any cipher suites.


17.5. Server Error 5xx
17.5. サーバーエラー5xx

Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. The server SHOULD include a message body containing an explanation of the error situation and whether it is a temporary or permanent condition. User agents SHOULD display any included message body to the user. These response codes are applicable to any request method.


17.5.1. 500 Internal Server Error
17.5.1. 500内部サーバーエラー

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


17.5.2. 501 Not Implemented
17.5.2. 501実装されていません

The agent does not support the functionality required to fulfill the request. This is the appropriate response when the agent does not recognize the request method and is not capable of supporting it for any resource.


17.5.3. 502 Bad Gateway
17.5.3. 502不正なゲートウェイ

The agent, while acting as a gateway or proxy, received an invalid response from the upstream agent it accessed in attempting to fulfill the request.


17.5.4. 503 Service Unavailable
17.5.4. 503サービスを利用できません

The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition that will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the agent SHOULD handle the response as it would for a 500 response. The agent MUST honor the length, if given, in the Retry-After header.

サーバーの一時的な過負荷またはメンテナンスのため、サーバーは現在リクエストを処理できません。これは、これが一時的な状態であり、しばらくすると緩和されることを意味しています。既知の場合、遅延の長さはRetry-Afterヘッダーで示される場合があります。 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.


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.


17.5.5. 504 Gateway Timeout
17.5.5. 504ゲートウェイのタイムアウト

The agent, while acting as a proxy, did not receive a timely response from the upstream agent specified by the URI or some other auxiliary server (e.g., DNS) that it needed to access in attempting to complete the request.


17.5.6. 505 RTSP Version Not Supported
17.5.6. 505 RTSPバージョンはサポートされていません

The agent does not support, or refuses to support, the RTSP version that was used in the request message. The agent is indicating that it is unable or unwilling to complete the request using the same major version as the agent other than with this error message. The response SHOULD contain a message body describing why that version is not supported and what other protocols are supported by that agent.


17.5.7. 551 Option Not Supported
17.5.7. 551オプションはサポートされていません

A feature tag given in the Require or the Proxy-Require fields was not supported. The Unsupported header MUST be returned stating the feature for which there is no support.

RequireまたはProxy-Requireフィールドで指定された機能タグはサポートされていませんでした。 Unsupportedヘッダーは、サポートされていない機能を示すために返される必要があります。

17.5.8. 553 Proxy Unavailable
17.5.8. 553プロキシを使用できません

The proxy is currently unable to handle the request due to a temporary overloading or maintenance of the proxy. The implication is that this is a temporary condition that will be alleviated after some delay. If known, the length of the delay MAY be indicated in a Retry-After header. If no Retry-After is given, the agent SHOULD handle the response as it would for a 500 response. The agent MUST honor the length, if given in the Retry-After header.

プロキシの一時的な過負荷またはメンテナンスのため、プロキシは現在リクエストを処理できません。これは、これが一時的な状態であり、しばらくすると緩和されることを意味しています。既知の場合、遅延の長さはRetry-Afterヘッダーで示される場合があります。 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.


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.


18. Header Field Definitions
18. ヘッダーフィールドの定義
       | method        | direction      | object | acronym | Body |
       | DESCRIBE      | C -> S         | P,S    | DES     | r    |
       |               |                |        |         |      |
       | GET_PARAMETER | C -> S, S -> C | P,S    | GPR     | R,r  |
       |               |                |        |         |      |
       | OPTIONS       | C -> S, S -> C | P,S    | OPT     |      |
       |               |                |        |         |      |
       | PAUSE         | C -> S         | P,S    | PSE     |      |
       |               |                |        |         |      |
       | PLAY          | C -> S         | P,S    | PLY     |      |
       |               |                |        |         |      |
       | PLAY_NOTIFY   | S -> C         | P,S    | PNY     | R    |
       |               |                |        |         |      |
       | REDIRECT      | S -> C         | P,S    | RDR     |      |
       |               |                |        |         |      |
       | SETUP         | C -> S         | S      | STP     |      |
       |               |                |        |         |      |
       | SET_PARAMETER | C -> S, S -> C | P,S    | SPR     | R,r  |
       |               |                |        |         |      |
       | TEARDOWN      | C -> S         | P,S    | TRD     |      |
       |               |                |        |         |      |
       |               | S -> C         | P      | TRD     |      |

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


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.


Information about header fields in relation to methods and proxy processing is summarized in Figures 2, 3, 4, and 5.


The "where" column describes the request and response types in which the header field can be used. Values in this column are:


R: header field may only appear in requests;


r: header field may only appear in responses;


2xx, 4xx, etc.: numerical value or range indicates response codes with which the header field can be used;


c: header field is copied from the request to the response.


G: header field is a general-header and may be present in both requests and responses.


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


The "proxy" column describes the operations a proxy may perform on a header field. An empty proxy column indicates that the proxy MUST NOT make any changes to that header, all allowed operations are explicitly stated:


a: A proxy can add or concatenate the header field if not present.


m: A proxy can modify an existing header field value.


d: A proxy can delete a header field-value.


r: A proxy needs to be able to read the header field; thus, this header field cannot be encrypted.


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:


c: Conditional; requirements on the header field depend on the context of the message.


m: The header field is mandatory.


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.


*: The header field MUST be present if the message body is not empty. See Sections 18.17, 18.19 and 5.3 for details.


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


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


   | 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


   | 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


 | 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


18.1. Accept
18.1. 受け入れる

The Accept request-header field can be used to specify certain presentation description and parameter media types [RFC6838] that are acceptable for the response to the DESCRIBE request.

Accept request-headerフィールドを使用して、DESCRIBE要求への応答に受け入れられる特定のプレゼンテーションの説明とパラメータメディアタイプ[RFC6838]を指定できます。

See Section 20.2.3 for the syntax.


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

18.2. Accept-Credentials
18.2. 資格情報を受け入れる

The Accept-Credentials header is a request-header used to indicate to any trusted intermediary how to handle further secured connections to proxies or servers. It MUST NOT be included in server-to-client requests. See Section 19 for the usage of this header


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.




18.3. Accept-Encoding
18.3. Accept-Encoding

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.


A server tests whether a content-coding is acceptable, according to an Accept-Encoding field, using these rules:


1. If the content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable, unless it is accompanied by a qvalue of 0. (As defined in Section 5.3.1 of [RFC7231], a qvalue of 0 means "not acceptable.")

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


18.4. Accept-Language
18.4. 受け入れ言語

The Accept-Language request-header field is similar to Accept, but restricts the set of natural languages that are preferred as a response to the request. Note that the language specified applies to the presentation description (response message body) and any reason phrases, but not the media content.


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より大きい修飾係数が割り当てられているすべての言語が受け入れ可能です。

18.5. Accept-Ranges
18.5. Accept-Ranges

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


The syntax is defined in Section 20.2.3.


18.6. Allow
18.6. 許可する

The Allow message body header field lists the methods supported by the resource identified by the Request-URI. The purpose of this field is to inform the recipient of the complete set of valid methods associated with the resource. An Allow header field MUST be present in a 405 (Method Not Allowed) response. The Allow header MUST also be present in all OPTIONS responses where the content of the header will not include exactly the same methods as listed in the Public header.

[Allow message body header]フィールドには、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.


Example of use:




18.7. Authentication-Info
18.7. 認証情報

The Authentication-Info response-header is used by the server to communicate some information regarding the successful HTTP authentication [RFC7235] in the response message. The definition of the header is in [RFC7615], and any applicable HTTP authentication schemes appear in other RFCs, such as Digest [RFC7616]. This header MUST only be used in response messages related to client to server requests.


18.8. Authorization
18.8. 認可

An RTSP client that wishes to authenticate itself with a server using the authentication mechanism from HTTP [RFC7235], usually (but not necessarily) after receiving a 401 response, does so by including an Authorization request-header field with the request. The Authorization field-value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested. The definition of the header is in

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.


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. 応答に「パブリック」キャッシュディレクティブが含まれている場合、後続の要求への応答として返される場合があります。

18.9. Bandwidth
18.9. 帯域幅

The Bandwidth request-header field describes the estimated bandwidth available to the client, expressed as a positive integer and measured in kilobits per second. The bandwidth available to the client may change during an RTSP session, e.g., due to mobility, congestion, etc.

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.


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.




Bandwidth: 62360


18.10. Blocksize
18.10. ブロックサイズ

The Blocksize request-header field is sent from the client to the media server asking the server for a particular media packet size. This packet size does not include lower-layer headers such as IP, UDP, or RTP. The server is free to use a blocksize that is lower than the one requested. The server MAY truncate this packet size to the closest multiple of the minimum, media-specific block size or override it with the media-specific size, if necessary. The block size MUST be a positive decimal number measured in octets. The server only returns an error (4xx) if the value is syntactically invalid.


18.11. Cache-Control
18.11. キャッシュ制御

The Cache-Control general-header field is used to specify directives that MUST be obeyed by all caching mechanisms along the request/ response chain.

Cache-Control general-headerフィールドは、要求/応答チェーンに沿ったすべてのキャッシングメカニズムに従う必要があるディレクティブを指定するために使用されます。

Cache directives MUST be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives may be applicable to all recipients along the request/response chain. It is not possible to specify a cache-directive for a specific cache.


Cache-Control should only be specified in a DESCRIBE, GET_PARAMETER, SET_PARAMETER, and SETUP request and its response. Note: Cache-Control does not govern only the caching of responses for the RTSP messages, instead it also applies to the media stream identified by 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.


public: Indicates that the media stream or RTSP response is cacheable by any cache.


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.


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.


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.


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.


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)応答で新しいメッセージ本文を返します。

18.12. Connection
18.12. 接続

The Connection general-header field allows the sender to specify options that are desired for that particular connection. It MUST NOT be communicated by proxies over further connections.


RTSP 2.0 proxies MUST parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a connection-token in the Connection header field, not by any corresponding additional header field(s), since the additional header field may not be sent if there are no parameters associated with that connection option.

RTSP 2.0プロキシは、メッセージが転送される前に接続ヘッダーフィールドを解析し、このフィールドの各接続トークンについて、接続トークンと同じ名前のメッセージからヘッダーフィールドを削除する必要があります。接続オプションは、対応する追加ヘッダーフィールドではなく、接続ヘッダーフィールドに接続トークンが存在することで通知されます。その接続オプションに関連付けられたパラメーターがない場合、追加ヘッダーフィールドは送信されない可能性があるためです。

Message headers listed in the Connection header MUST NOT include end-to-end headers, such as Cache-Control.


RTSP 2.0 defines the "close" connection option for the sender to signal that the connection will be closed after completion of the response. For example, "Connection: close in either the request or the response-header fields" indicates that the connection SHOULD NOT be considered "persistent" (Section 10.2) after the current request/ response is complete.

RTSP 2.0は、送信者が応答の完了後に接続が閉じられることを通知する「閉じる」接続オプションを定義しています。たとえば、「接続:要求フィールドまたは応答ヘッダーフィールドのいずれかで閉じる」は、現在の要求/応答が完了した後、接続が「永続的」(セクション10.2)と見なされるべきではないことを示します。

The use of the connection option "close" in RTSP messages SHOULD be limited to error messages when the server is unable to recover and therefore sees it necessary to close the connection. The reason being that the client has the choice of continuing using a connection indefinitely, as long as it sends valid messages.


18.13. Connection-Credentials
18.13. 接続資格情報

The Connection-Credentials response-header is used to carry the chain of credentials for any next hop that needs to be approved by the requester. It MUST only be used in server-to-client responses.


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.





Connection-Credentials: "rtsps://"; 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


18.14. Content-Base
18.14. コンテンツベース

The Content-Base message body header field may be used to specify the base URI for resolving relative URIs within the message body.


Content-Base: rtsp:// 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:// Content-Baseフィールドが存在しない場合、メッセージ本文のベースURIは、そのContent-Location(そのContent-Location URIが絶対URI)または要求を開始するために使用されたURI(優先順位の高い順)。ただし、メッセージ本文内のコンテンツのベースURIは、そのメッセージ本文内で再定義できることに注意してください。

18.15. Content-Encoding
18.15. コンテンツエンコーディング

The Content-Encoding message body header field is used as a modifier of the media-type. When present, its value indicates what additional content-codings have been applied to the message body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type.

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.


If the content-coding of a message body is not "identity", then the message MUST include a Content-Encoding message body header that lists the non-identity content-coding(s) used.


If the content-coding of a message body in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type).


If multiple encodings have been applied to a message body, the content-codings MUST be listed in the order in which they were applied, first to last from left to right. Additional information about the encoding parameters MAY be provided by other header fields not defined by this specification.


18.16. Content-Language
18.16. コンテンツ言語

The Content-Language message body header field describes the natural language(s) of the intended audience for the enclosed message body. Note that this might not be equivalent to all the languages used within the message body.


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


If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean that the sender does not consider it to be specific to any natural language or that the sender does not know for which language it is intended.


Multiple languages MAY be listed for content that is intended for multiple audiences. For example, a rendition of the "Treaty of Waitangi", presented simultaneously in the original Maori and English versions, would call for


Content-Language: mi, en


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 MAY be applied to any media type -- it is not limited to textual documents.


18.17. Content-Length
18.17. コンテンツの長さ

The Content-Length message body header field contains the length of the message body of the RTSP message (i.e., after the double CRLF following the last header) in octets of bits. Unlike HTTP, it MUST be included in all messages that carry a message body beyond the header portion of the RTSP message. If it is missing, a default value of zero is assumed. Any Content-Length greater than or equal to zero is a valid value.

Content-Lengthメッセージ本文のヘッダーフィールドには、RTSPメッセージのメッセージ本文の長さ(つまり、最後のヘッダーに続く二重CRLFの後)がビットのオクテットで含まれています。 HTTPとは異なり、RTSPメッセージのヘッダー部分を超えてメッセージ本文を運ぶすべてのメッセージに含める必要があります。それがない場合は、デフォルト値のゼロが想定されます。ゼロ以上のContent-Lengthは有効な値です。

18.18. Content-Location
18.18. コンテンツの場所

The Content-Location message body header field MAY be used to supply the resource location for the message body enclosed in the message when that body is accessible from a location separate from the requested resource's URI. A server SHOULD provide a Content-Location for the variant corresponding to the response message body; especially in the case where a resource has multiple variants associated with it, and those entities actually have separate locations by which they might be individually accessed, the server SHOULD provide a Content-Location for the particular variant that is returned.


As an example, if an RTSP client performs a DESCRIBE request on a given resource, e.g., "rtsp:// 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://") 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:// Plan9FromOuterSpace」などの特定のリソースに対してDESCRIBEリクエストを実行する場合、サーバーはUser-Agentヘッダーなどの追加情報を使用できます。 、エージェントの機能を判別します。サーバーは、そのクラスのRTSPエージェントに合わせたメディアの説明を返します。エージェントが受け取る特定の説明を示すために、リソース識別子( "rtsp://")が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.


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を作成することが含まれます。

18.19. Content-Type
18.19. コンテンツタイプ

The Content-Type message body header indicates the media type of the message body sent to the recipient. Note that the content types suitable for RTSP are likely to be restricted in practice to presentation descriptions and parameter-value types.

Content-Typeメッセージ本文ヘッダーは、受信者に送信されるメッセージ本文のメディアタイプを示します。 RTSPに適したコンテンツタイプは、実際にはプレゼンテーションの説明とパラメータ値タイプに制限される可能性が高いことに注意してください。

18.20. CSeq
18.20. CSeq

The CSeq general-header field specifies the sequence number (integer) for an RTSP request/response pair. This field MUST be present in all requests and responses. RTSP agents maintain a sequence number series for each responder to which they have an open message transport channel. For each new RTSP request an agent originates on a particular RTSP message transport, the CSeq value MUST be incremented by one. The initial sequence number can be any number; however, it is RECOMMENDED to start at 0. Each sequence number series is unique between each requester and responder, i.e., the client has one series for its requests to a server and the server has another when sending requests to the client. Each requester and responder is identified by its socket address (IP address and port number), i.e., per direction of a TCP connection. Any retransmitted request MUST contain the same sequence number as the original, i.e., the sequence number is not incremented for retransmissions of the same request. The RTSP agent receiving requests MUST process the requests arriving on a particular transport in the order of the sequence numbers. Responses are sent in the order that they are generated. The RTSP response MUST have the same sequence number as was present in the corresponding request. An RTSP agent receiving a response MAY receive the responses out of order compared to the order of the requests it sent. Thus, the agent MUST use the sequence number in the response to pair it with the corresponding request.

CSeq general-headerフィールドは、RTSP要求/応答ペアのシーケンス番号(整数)を指定します。このフィールドは、すべての要求と応答に存在する必要があります。 RTSPエージェントは、オープンメッセージトランスポートチャネルを持つ各レスポンダのシーケンス番号シリーズを維持します。エージェントが特定のRTSPメッセージトランスポートで発信する新しいRTSP要求ごとに、CSeq値を1ずつ増やす必要があります。最初のシーケンス番号は任意の番号にすることができます。ただし、0から開始することをお勧めします。各シーケンス番号シリーズは、各リクエスターとレスポンダーの間で一意です。つまり、クライアントはサーバーへの要求に対して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.


The above rules relating to the initial sequence number may appear unnecessarily loose. The reason for this is to cater to some common behavior of existing implementations: when using multiple reliable connections in sequence, it may still be easiest to use a single sequence-number series for a client connecting with a particular server. Thus, the initial sequence number may be arbitrary depending on the number of previous requests. For any unreliable transport, a stricter definition or other solution will be required to enable detection of any loss of the first request.


When using multiple sequential transport connections, there is no protocol mechanism to ensure in-order processing as the sequence number is scoped on the individual transport connection and its five tuple. Thus, there are potential issues with opening a new transport connection to the same host for which there already exists a transport connection with outstanding requests and previously dispatched requests related to the same RTSP session.


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


A client connected to a proxy, and using that transport to send requests to multiple servers, creates a situation where it is quite likely to receive the responses out of order. This is because the proxy will establish separate transports from the proxy to the servers on which to forward the client's requests. When the responses arrive from the different servers, they will be forwarded to the client in the order they arrive at the proxy and can be processed, not the order of the client's original sequence numbers. This is intentional to avoid some session's requests being blocked by another server's slow processing of requests.


18.21. Date
18.21. 日付

The Date general-header field represents the date and time at which the message was originated. The inclusion of the Date header in an RTSP message follows these rules:

日付の一般ヘッダーフィールドは、メッセージが発信された日時を表します。 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.


18.22. Expires
18.22. 期限切れ

The Expires message body header field gives a date and time after which the description or media-stream should be considered stale. The interpretation depends on the method:


DESCRIBE response: The Expires header indicates a date and time after which the presentation description (body) SHOULD be considered stale.


SETUP response: The Expires header indicates a date and time after which the media stream SHOULD be considered stale.


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.


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.


The format is an absolute date and time as defined by RTSP-date. An example of its use is


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

18.23. From
18.23. から

The From request-header field, if given, SHOULD contain an Internet email address for the human user who controls the requesting user agent. The address SHOULD be machine usable, as defined by "mailbox" in [RFC1123].

Fromリクエストヘッダーフィールドが指定されている場合、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.


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.


The client SHOULD NOT send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at any time prior to a request.


18.24. If-Match
18.24. イフマッチ

The If-Match request-header field is especially useful for ensuring the integrity of the presentation description, independent of how the presentation description was received. The presentation description can be fetched via means external to RTSP (such as HTTP) or via the DESCRIBE message. In the case of retrieving the presentation description via RTSP, the server implementation is guaranteeing the integrity of the description between the time of the DESCRIBE message and the SETUP message. By including the MTag given in or with the session description in an If-Match header part of the SETUP request, the client ensures that resources set up are matching the description. A SETUP request with the If-Match header for which the MTag validation check fails MUST generate a response using 412 (Precondition Failed).

If-Match要求ヘッダーフィールドは、プレゼンテーションの説明がどのように受信されたかに関係なく、プレゼンテーションの説明の整合性を保証するのに特に役立ちます。プレゼンテーションの説明は、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.


18.25. If-Modified-Since
18.25. If-Modified-Since

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
18.26. If-None-Match
18.26. If-None-Match

This request-header can be used with one or several message body tags to make DESCRIBE requests conditional. A client that has one or more message bodies previously obtained from the resource can verify that none of those entities is current by including a list of their associated message body tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. As a special case, the value "*" matches any current entity of the resource.


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


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.


18.27. Last-Modified
18.27. 最終更新日

The Last-Modified message body header field indicates the date and time at which the origin server believes the presentation description or media stream was last modified. For the DESCRIBE method, the header field indicates the last modification date and time of the description, for the SETUP of the media stream.

Last-Modifiedメッセージ本文のヘッダーフィールドは、オリジンサーバーがプレゼンテーションの説明またはメディアストリームが最後に変更されたと信じる日時を示します。 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.


RTSP servers SHOULD send Last-Modified whenever feasible.


18.28. Location
18.28. ロケーション

The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 3rr responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field-value consists of a single absolute URI.

Location応答ヘッダーフィールドは、要求の完了または新しいリソースの識別のために、受信者を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.


18.29. Media-Properties
18.29. メディアプロパティ

This general-header is used in SETUP responses or PLAY_NOTIFY requests to indicate the media's properties that currently are applicable to the RTSP session. PLAY_NOTIFY MAY be used to modify these properties at any point. However, the client SHOULD have received the update prior to any action related to the new media properties taking effect. For aggregated sessions, the Media-Properties header will be returned in each SETUP response. The header received in the latest response is the one that applies on the 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.


The header contains a list of property values that are applicable to the currently setup media or aggregate of media as indicated by the RTSP URI in the request. No ordering is enforced within the header. Property values should be placed into a single group that handles a particular orthogonal property. Values or groups that express multiple properties SHOULD NOT be used. The list of properties that can be expressed MAY be extended at any time. Unknown property values MUST be ignored.

ヘッダーには、リクエストのRTSP URIで示されている、現在設定されているメディアまたはメディアの集合体に適用できるプロパティ値のリストが含まれています。ヘッダー内では順序付けは強制されません。プロパティ値は、特定の直交プロパティを処理する単一のグループに配置する必要があります。複数のプロパティを表す値またはグループは使用しないでください。表現できるプロパティのリストはいつでも拡張できます。不明なプロパティ値は無視する必要があります。

This specification defines the following four groups and their property values:


Random Access:


Random-Access: Indicates that random access is possible. May optionally include a floating-point value in seconds indicating the longest duration between any two random access points in the media.


Beginning-Only: Seeking is limited to the beginning only.


No-Seeking: No seeking is possible.


Content Modifications:


Immutable: The content will not be changed during the lifetime of the RTSP session.


Dynamic: The content may be changed based on external methods or triggers.


Time-Progressing: The media accessible progresses as wallclock time progresses.




Unlimited: Content will be retained for the duration of the lifetime of the RTSP session.


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.


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.


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:


   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
18.30. Media-Range
18.30. メディア範囲

The Media-Range general-header is used to give the range of the media at the time of sending the RTSP message. This header MUST be included in the SETUP response, PLAY and PAUSE responses for media that are time-progressing, PLAY and PAUSE responses after any change for media that are Dynamic, and in PLAY_NOTIFY requests that are sent 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.


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.


18.31. MTag
18.31. MTag

The MTag response-header MAY be included in DESCRIBE, GET_PARAMETER, or SETUP responses. The message body tags (Section 4.6) returned in a DESCRIBE response and the one in SETUP refer to the presentation, i.e., both the returned session description and the media stream. This allows for verification that one has the right session description to a media resource at the time of the SETUP request. However, it has the disadvantage that a change in any of the parts results in invalidation of all the parts.

MTag応答ヘッダーは、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).


18.32. Notify-Reason
18.32. 通知理由

The Notify-Reason response-header is solely used in the PLAY_NOTIFY method. It indicates the reason why the server has sent the asynchronous PLAY_NOTIFY request (see Section 13.5).


18.33. Pipelined-Requests
18.33. パイプライン化されたリクエスト

The Pipelined-Requests general-header is used to indicate that a request is to be executed in the context created by a previous request(s). The primary usage of this header is to allow pipelining of SETUP requests so that any additional SETUP request after the first one does not need to wait for the session ID to be sent back to the requesting agent. The header contains a unique identifier that is scoped by the persistent connection used to send the requests.

Pipelined-Requests general-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.


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.


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.


18.34. Proxy-Authenticate
18.34. プロキシ認証

The Proxy-Authenticate response-header field MUST be included as part of a 407 (Proxy Authentication Required) response. The field-value consists of a challenge that indicates the authentication scheme and parameters applicable to the proxy for this Request-URI. The definition of the header is in [RFC7235], and any applicable HTTP authentication schemes appear in other RFCs, such as Digest [RFC7616] and Basic [RFC7617].

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.


18.35. Proxy-Authentication-Info
18.35. プロキシ認証情報

The Proxy-Authentication-Info response-header is used by the proxy to communicate some information regarding the successful authentication to the proxy in the message response in some authentication schemes, such as the Digest scheme [RFC7616]. The definition of the header is in [RFC7615], and any applicable HTTP authentication schemes appear in other RFCs. This header MUST only be used in response messages related to client-to-server requests. This header has hop-by-hop scope.


18.36. Proxy-Authorization
18.36. プロキシ承認

The Proxy-Authorization request-header field allows the client to identify itself (or its user) to a proxy that requires authentication. The Proxy-Authorization field-value consists of credentials containing the authentication information of the user agent for the proxy or realm of the resource being requested. The definition of the header is in [RFC7235], and any applicable HTTP authentication schemes appear in other RFCs, such as Digest [RFC7616] and Basic [RFC7617].

Proxy-Authorizationリクエストヘッダーフィールドを使用すると、認証を必要とするプロキシに対してクライアント(またはそのユーザー)を識別できます。 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ヘッダーフィールドはネクストホッププロキシにのみ適用されます。このヘッダーは、クライアントからサーバーへのリクエストでのみ使用する必要があります。

18.37. Proxy-Require
18.37. プロキシが必要

The Proxy-Require request-header field is used to indicate proxy-sensitive features that MUST be supported by the proxy. Any Proxy-Require header features that are not supported by the proxy MUST be negatively acknowledged by the proxy to the client using the Unsupported header. The proxy MUST use the 551 (Option Not Supported) status code in the response. Any feature tag included in the Proxy-Require does not apply to the endpoint (server or client). To ensure that a feature is supported by both proxies and servers, the tag needs to be included in also a Require header.

Proxy-Requireリクエストヘッダーフィールドは、プロキシによってサポートされる必要があるプロキシ依存の機能を示すために使用されます。プロキシーでサポートされていない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.


Example of use:


Proxy-Require: play.basic


18.38. Proxy-Supported
18.38. プロキシ対応

The Proxy-Supported general-header field enumerates all the extensions supported by the proxy using feature tags. The header carries the intersection of extensions supported by the forwarding proxies. The Proxy-Supported header MAY be included in any request by a proxy. It MUST be added by any proxy if the Supported header is present in a request. When present in a request, the receiver MUST copy the received Proxy-Supported header in the response.

Proxy-Supported general-headerフィールドは、機能タグを使用してプロキシがサポートするすべての拡張機能を列挙します。ヘッダーは、転送プロキシがサポートする拡張機能の共通部分を伝送します。 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.




     C->P1: OPTIONS rtsp:// RTSP/2.0
            Supported: foo, bar, blech
            User-Agent: PhonyClient/1.2
    P1->P2: OPTIONS rtsp:// RTSP/2.0
            Supported: foo, bar, blech
            Proxy-Supported: proxy-foo, proxy-bar, proxy-blech
            Via: 2.0
    P2->S:  OPTIONS rtsp:// RTSP/2.0
            Supported: foo, bar, blech
            Proxy-Supported: proxy-foo, proxy-blech
            Via: 2.0, 2.0
     S->C:  RTSP/2.0 200 OK
            Supported: foo, bar, baz
            Proxy-Supported: proxy-foo, proxy-blech
            Via: 2.0, 2.0
18.39. Public
18.39. 公衆

The Public response-header field lists the set of methods supported by the response sender. This header applies to the general capabilities of the sender, and its only purpose is to indicate the sender's capabilities to the recipient. The methods listed may or may not be applicable to the Request-URI; the Allow header field (Section 18.6) MAY be used to indicate methods allowed for a particular URI.

Public response-headerフィールドには、応答の送信者がサポートする一連のメソッドが一覧表示されます。このヘッダーは送信者の一般的な機能に適用され、その唯一の目的は送信者の機能を受信者に示すことです。リストされているメソッドは、Request-URIに適用できる場合と適用できない場合があります。 Allowヘッダーフィールド(セクション18.6)は、特定のURIで許可されるメソッドを示すために使用できます(MAY)。

Example of use:




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.


18.40. Range
18.40. 範囲

The Range general-header specifies a time range in PLAY (Section 13.4), PAUSE (Section 13.6), SETUP (Section 13.3), and PLAY_NOTIFY (Section 13.5) requests and responses. It MAY be included in GET_PARAMETER requests from the client to the server with only a Range format and no value to request the current media position, whether the session is in Play or Ready state in the included format. The server SHALL, if supporting the range format, respond with the current playing point or pause point as the start of the range. If an explicit stop point was used in the previous PLAY request, then that value shall be included as stop point. Note that if the server is currently under any type of media playback manipulation affecting the interpretation of the Range header, like scale value other than 1, that fact is also required to be included in any GET_PARAMETER response by including the Scale header to provide complete information.

Range汎用ヘッダーは、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ヘッダーを含める必要があります。



Range: clock=19960213T143205Z-

範囲:時計= 19960213T143205Z-

The Range header contains a range of one single range format. A range is a half-open interval with a start and an end point, including the start point but excluding the end point. A range may either be fully specified with explicit values for start point and end point or have either the start or end point be implicit. An implicit start point indicates the session's pause point, and if no pause point is set, the start of the content. An implicit end point indicates the end of the content. The usage of both implicit start and end points is not allowed in the same Range header; however, the omission of the Range header has that meaning, i.e., from pause point (or start) until end of content.


As noted, Range headers define half-open intervals. A range of A-B starts exactly at time A, but ends just before B. Only the start time of a media unit such as a video or audio frame is relevant. For example, assume that video frames are generated every 40 ms. A range of 10.0-10.1 would include a video frame starting at 10.0 or later time and would include a video frame starting at 10.08, even though it lasted beyond the interval. A range of 10.0-10.08, on the other hand, would exclude the frame at 10.08.

前述のように、範囲ヘッダーはハーフオープン間隔を定義します。 A〜Bの範囲は、正確に時刻Aで始まり、Bの直前で終わります。関連するのは、ビデオやオーディオフレームなどのメディアユニットの開始時刻のみです。たとえば、ビデオフレームが40ミリ秒ごとに生成されると仮定します。 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.


By default, range intervals increase, where the second point is larger than the first point.




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.




       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に到達する方法はありません。



       Scale: -1
       Range: npt=15-0

In this range, both 15 and 0 are closed.


A decreasing range interval without a corresponding negative value in the Scale header is not valid.


18.41. Referrer
18.41. リファラー

The Referrer request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained. The URI refers to that of the presentation description, typically retrieved via HTTP. The Referrer request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referrer field MUST NOT be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.

クライアントは、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.


Clients SHOULD NOT include a Referrer header field in an (non-secure) RTSP request if the referring page was transferred with a secure protocol.


18.42. Request-Status
18.42. リクエストステータス

This request-header is used to indicate the end result for requests that take time to complete, such as PLAY (Section 13.4). It is sent in PLAY_NOTIFY (Section 13.5) with the end-of-stream reason to report how the PLAY request concluded, either in success or in failure. The header carries a reference to the request it reports on using the CSeq number and the Session ID used in the request reported on. This is not ensured to be unambiguous due to the fact that the CSeq number is scoped by the transport connection. Agents originating requests 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.


   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.


18.43. Require
18.43. 必要とする

The Require request-header field is used by agents to ensure that the other endpoint supports features that are required in respect to this request. It can also be used to query if the other endpoint supports certain features; however, the use of the Supported general-header (Section 18.51) is much more effective in this purpose. In case any of the feature tags listed by the Require header are not supported by the server or client receiving the request, it MUST respond to the request using the error code 551 (Option Not Supported) and include the Unsupported header listing those feature tags that are NOT supported. This header does not apply to proxies; for the same functionality with respect to proxies, see the Proxy-Require header (Section 18.37) with the exception of media-modifying proxies. Media-modifying proxies, due to their nature of handling media in a way that is very similar to a server, do need to understand also the server's features to correctly serve the client.

Require request-headerフィールドは、他のエンドポイントがこのリクエストに関して必要な機能を確実にサポートするためにエージェントによって使用されます。また、他のエンドポイントが特定の機能をサポートしているかどうかを照会するためにも使用できます。ただし、この目的では、サポートされている一般ヘッダー(セクション18.51)を使用する方がはるかに効果的です。 Requireヘッダーにリストされている機能タグのいずれかがリクエストを受信するサーバーまたはクライアントでサポートされていない場合は、エラーコード551(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:// 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.


18.44. Retry-After
18.44. 再試行後

The Retry-After response-header field can be used with a 503 (Service Unavailable) or 553 (Proxy Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. This field MAY also be used with any 3rr (Redirection) response to indicate the minimum time the user agent is asked to wait before issuing the redirected request. A response using 413 (Request Message Body Too Large) when the restriction is temporary MAY also include the Retry-After header. The value of this field can be either an RTSP-date or an integer number of seconds (in decimal) after the time of the response.

Retry-After応答ヘッダーフィールドを503(Service Unavailable)または553(Proxy Unavailable)応答と共に使用して、要求元のクライアントがサービスを利用できないと予想される期間を示すことができます。このフィールドは、リダイレクトされた要求を発行する前にユーザーエージェントが待機するように求められる最小時間を示すために、任意の3rr(リダイレクト)応答と共に使用される場合があります。制限が一時的なものである場合に413(Request Message Body Too Large)を使用する応答には、Retry-Afterヘッダーも含まれる場合があります。このフィールドの値は、RTSP日付、または応答時間後の秒数(10進数)の整数のいずれかです。



   Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
   Retry-After: 120

In the latter example, the delay is 2 minutes.


18.45. RTP-Info
18.45. RTP情報

The RTP-Info general-header field is used to set RTP-specific parameters in the PLAY and GET_PARAMETER responses or PLAY_NOTIFY and GET_PARAMETER requests. For streams using RTP as transport protocol, the RTP-Info header SHOULD be part of a 200 response to PLAY.


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.


ssrc: The SSRC to which the RTP timestamp and sequence number provided applies. This parameter MUST be present.


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.


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.


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.


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.




   RTP-Info:url="rtsp://" ssrc=0A13C760:seq=45102;

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

The Scale general-header indicates the requested or used view rate for the media resource being played back. A scale value of 1 indicates normal play at the normal forward viewing rate. If not 1, the value corresponds to the rate with respect to normal viewing rate. For example, a value of 2 indicates twice the normal viewing rate ("fast forward") and a value of 0.5 indicates half the normal viewing rate. In other words, a value of 2 has content time increase at twice the playback time. For every second of elapsed (wallclock) time, 2 seconds of content time will be delivered. A negative value indicates reverse direction. For certain media transports, this may require certain considerations to work consistently; see Appendix C.1 for description on how RTP handles this.

スケール一般ヘッダーは、再生されているメディアリソースの要求または使用された視聴率を示します。スケール値1は、通常の順方向視聴率での通常の再生を示します。 1でない場合、値は通常の視聴率に対する比率に対応します。たとえば、値2は通常の表示レートの2倍(「早送り」)を示し、値0.5は通常の表示レートの半分を示します。つまり、値が2の場合、再生時間の2倍でコンテンツ時間が増加します。経過時間(壁時計)の1秒ごとに、2秒のコンテンツ時間が配信されます。負の値は逆方向を示します。特定のメディアトランスポートでは、これが一貫して機能するために特定の考慮事項が必要になる場合があります。 RTPがこれを処理する方法については