RFC2326 日本語訳
2326 Real Time Streaming Protocol (RTSP). H. Schulzrinne, A. Rao, R.Lanphier. April 1998. (Format: TXT=195010 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group H. Schulzrinne
Request for Comments: 2326 Columbia U.
Category: Standards Track A. Rao
Netscape
R. Lanphier
RealNetworks
April 1998
Schulzrinneがコメントのために要求するワーキンググループH.をネットワークでつないでください: 2326年のコロンビアU.カテゴリ: 標準化過程A.ラオNetscape R.Lanphierリアルネットワークス1998年4月
Real Time Streaming Protocol (RTSP)
リアルタイムのストリーミングのプロトコル(RTSP)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
The Real Time Streaming Protocol, or RTSP, is an application-level protocol for control over 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 1889).
レアルのTime Streamingプロトコル、またはRTSPがリアルタイムの特性があるデータの配送のコントロールのためのアプリケーションレベルプロトコルです。 RTSPは、オーディオやビデオなどのリアルタイムデータの制御されて、要求次第の配送を可能にするために広げることができる枠組みを提供します。 データの源はライブデータ給送と格納されたクリップの両方を含むことができます。 このプロトコルは、複数のデータ配送セッションを制御して、UDPや、マルチキャストUDPやTCPなどの流通チャネルを選ぶのに手段を提供して、RTP(RFC1889)に基づく排紙機構を選ぶのに手段を提供することを意図します。
Table of Contents
目次
* 1 Introduction ................................................. 5
+ 1.1 Purpose ............................................... 5
+ 1.2 Requirements .......................................... 6
+ 1.3 Terminology ........................................... 6
+ 1.4 Protocol Properties ................................... 9
+ 1.5 Extending RTSP ........................................ 11
+ 1.6 Overall Operation ..................................... 11
+ 1.7 RTSP States ........................................... 12
+ 1.8 Relationship with Other Protocols ..................... 13
* 2 Notational Conventions ....................................... 14
* 3 Protocol Parameters .......................................... 14
+ 3.1 RTSP Version .......................................... 14
* 1つの序論… 5+1.1目的… 5+1.2の要件… 6+1.3用語… 6+1.4は特性について議定書の中で述べます… 9+1.5広がりRTSP… 11+1.6の総合的な操作… 11+1.7のRTSP州… 他のプロトコルとの12+1.8関係… 13*2つの記号法のコンベンション… 14*3はパラメタについて議定書の中で述べます… 14+3.1RTSPバージョン… 14
Schulzrinne, et. al. Standards Track [Page 1] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[1ページ]RFC2326リアルタイム
+ 3.2 RTSP URL .............................................. 14
+ 3.3 Conference Identifiers ................................ 16
+ 3.4 Session Identifiers ................................... 16
+ 3.5 SMPTE Relative Timestamps ............................. 16
+ 3.6 Normal Play Time ...................................... 17
+ 3.7 Absolute Time ......................................... 18
+ 3.8 Option Tags ........................................... 18
o 3.8.1 Registering New Option Tags with IANA .......... 18
* 4 RTSP Message ................................................. 19
+ 4.1 Message Types ......................................... 19
+ 4.2 Message Headers ....................................... 19
+ 4.3 Message Body .......................................... 19
+ 4.4 Message Length ........................................ 20
* 5 General Header Fields ........................................ 20
* 6 Request ...................................................... 20
+ 6.1 Request Line .......................................... 21
+ 6.2 Request Header Fields ................................. 21
* 7 Response ..................................................... 22
+ 7.1 Status-Line ........................................... 22
o 7.1.1 Status Code and Reason Phrase .................. 22
o 7.1.2 Response Header Fields ......................... 26
* 8 Entity ....................................................... 27
+ 8.1 Entity Header Fields .................................. 27
+ 8.2 Entity Body ........................................... 28
* 9 Connections .................................................. 28
+ 9.1 Pipelining ............................................ 28
+ 9.2 Reliability and Acknowledgements ...................... 28
* 10 Method Definitions .......................................... 29
+ 10.1 OPTIONS .............................................. 30
+ 10.2 DESCRIBE ............................................. 31
+ 10.3 ANNOUNCE ............................................. 32
+ 10.4 SETUP ................................................ 33
+ 10.5 PLAY ................................................. 34
+ 10.6 PAUSE ................................................ 36
+ 10.7 TEARDOWN ............................................. 37
+ 10.8 GET_PARAMETER ........................................ 37
+ 10.9 SET_PARAMETER ........................................ 38
+ 10.10 REDIRECT ............................................ 39
+ 10.11 RECORD .............................................. 39
+ 10.12 Embedded (Interleaved) Binary Data .................. 40
* 11 Status Code Definitions ..................................... 41
+ 11.1 Success 2xx .......................................... 41
o 11.1.1 250 Low on Storage Space ...................... 41
+ 11.2 Redirection 3xx ...................................... 41
+ 11.3 Client Error 4xx ..................................... 42
o 11.3.1 405 Method Not Allowed ........................ 42
o 11.3.2 451 Parameter Not Understood .................. 42
o 11.3.3 452 Conference Not Found ...................... 42
+ 3.2RTSP URL… 14+3.3のコンファレンス識別子… 16+3.4のセッション識別子… 16+3.5のSMPTEの相対的なタイムスタンプ… 16+3.6の正常なプレー時間… 17+3.7絶対時間… 18+3.8個のオプションタグ… 18 IANAとo3.8.1Registering New Option Tags… 18*4RTSPメッセージ… 19+4.1のメッセージタイプ… 19+4.2個のメッセージヘッダー… 19+4.3メッセージ本体… 19+4.4メッセージ長… 20*5つの一般ヘッダーフィールド… 20*6要求… 20+6.1は線を要求します… 21+6.2はヘッダーフィールドを要求します… 21*7応答… 22+7.1状況表示行… 22 o7.1.1のStatus CodeとReason Phrase… 22 o7.1.2Response Headerフィールズ… 26*8実体… 27+8.1の実体ヘッダーフィールド… 27+8.2実体本体… 28*9コネクションズ… 28+9.1パイプライン処理… 28+9.2の信頼性と承認… 28*10の方法定義… 29+10.1のオプション… + 10.2が説明する30… 31+10.3は発表します… 32+10.4はセットアップされます… 33+10.5はプレーします… 34+10.6は止まります… 36+10.7分解… 37+10.8は_パラメタを得ます… 37+10.9は_パラメタを設定します… + 10.10が向け直す38… 39+10.11は記録します… 39+10.12の埋め込まれた(はさみ込まれる)2進のデータ… 40*11のステータスコード定義… 41+11.1成功2xx… 41 11.1.1 250 Storage Spaceの上のo Low… 41+11.2リダイレクション3xx… 41+11.3クライアント誤り4xx… 42 11.3.1 405 o Method Not Allowed… 42 11.3.2 451 o Parameter Not Understood… 42 o11.3.3 452コンファレンスNot Found… 42
Schulzrinne, et. al. Standards Track [Page 2] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[2ページ]RFC2326リアルタイム
o 11.3.4 453 Not Enough Bandwidth ...................... 42
o 11.3.5 454 Session Not Found ......................... 42
o 11.3.6 455 Method Not Valid in This State ............ 42
o 11.3.7 456 Header Field Not Valid for Resource ....... 42
o 11.3.8 457 Invalid Range ............................. 43
o 11.3.9 458 Parameter Is Read-Only .................... 43
o 11.3.10 459 Aggregate Operation Not Allowed .......... 43
o 11.3.11 460 Only Aggregate Operation Allowed ......... 43
o 11.3.12 461 Unsupported Transport .................... 43
o 11.3.13 462 Destination Unreachable .................. 43
o 11.3.14 551 Option not supported ..................... 43
* 12 Header Field Definitions .................................... 44
+ 12.1 Accept ............................................... 46
+ 12.2 Accept-Encoding ...................................... 46
+ 12.3 Accept-Language ...................................... 46
+ 12.4 Allow ................................................ 46
+ 12.5 Authorization ........................................ 46
+ 12.6 Bandwidth ............................................ 46
+ 12.7 Blocksize ............................................ 47
+ 12.8 Cache-Control ........................................ 47
+ 12.9 Conference ........................................... 49
+ 12.10 Connection .......................................... 49
+ 12.11 Content-Base ........................................ 49
+ 12.12 Content-Encoding .................................... 49
+ 12.13 Content-Language .................................... 50
+ 12.14 Content-Length ...................................... 50
+ 12.15 Content-Location .................................... 50
+ 12.16 Content-Type ........................................ 50
+ 12.17 CSeq ................................................ 50
+ 12.18 Date ................................................ 50
+ 12.19 Expires ............................................. 50
+ 12.20 From ................................................ 51
+ 12.21 Host ................................................ 51
+ 12.22 If-Match ............................................ 51
+ 12.23 If-Modified-Since ................................... 52
+ 12.24 Last-Modified........................................ 52
+ 12.25 Location ............................................ 52
+ 12.26 Proxy-Authenticate .................................. 52
+ 12.27 Proxy-Require ....................................... 52
+ 12.28 Public .............................................. 53
+ 12.29 Range ............................................... 53
+ 12.30 Referer ............................................. 54
+ 12.31 Retry-After ......................................... 54
+ 12.32 Require ............................................. 54
+ 12.33 RTP-Info ............................................ 55
+ 12.34 Scale ............................................... 56
+ 12.35 Speed ............................................... 57
+ 12.36 Server .............................................. 57
o 11.3.4 453 十分な帯域幅でない… 42 11.3.5 454 o Session Not Found… 42 11.3.6 455 This州におけるo Method Not Valid… 42 11.3.7 456 Resourceのためのo Header Field Not Valid… 42 11.3.8 457 o Invalid Range… 43 o11.3.9 458Parameter Is Read専用… 43 11.3.10 459 o Aggregate Operation Not Allowed… 43 11.3.11 460 o Only Aggregate Operation Allowed… 43 11.3.12 461 o Unsupported Transport… 43 11.3.13 462 o Destination Unreachable… 43 Optionが支持しなかった○11.3.14 551… 43*12のヘッダーフィールド定義… 44+12.1は受け入れます… 46+、12.2 コード化を受け入れます… 46+、12.3 言語を受け入れます… + 12.4が許容する46… 46+12.5認可… 46+12.6帯域幅… 46+12.7はBlocksizeされます… 47+12.8キャッシュ制御… 47+12.9コンファレンス… 49+12.10接続… 49+12.11の満足している基地… 49 + …を内容でコード化する12.12… 49+12.13の満足している言語… 50+12.14コンテンツの長さ… 50+12.15の満足している位置… 50+12.16コンテントタイプ… 50+12.17CSeq… 50+12.18はデートされます… 50+12.19は期限が切れます… 50+12.20、… 51+12.21ホスト… 51+12.22、-合ってください、… 51+、12.23 以来変更されるなら… 52+12.24は最後に…を変更しました… 52+12.25位置… 52+12.26は…をプロキシで認証します… 52+12.27は…をプロキシで必要とします… 52+12.28公衆… 53+12.29は及びます… 53+12.30Referer… 54+12.31は-後に再試行されます… + 12.32が必要とする54… 54+12.33RTP-インフォメーション… 55+12.34は比例します… 56+12.35は疾走します… 57+12.36サーバ… 57
Schulzrinne, et. al. Standards Track [Page 3] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[3ページ]RFC2326リアルタイム
+ 12.37 Session ............................................. 57
+ 12.38 Timestamp ........................................... 58
+ 12.39 Transport ........................................... 58
+ 12.40 Unsupported ......................................... 62
+ 12.41 User-Agent .......................................... 62
+ 12.42 Vary ................................................ 62
+ 12.43 Via ................................................. 62
+ 12.44 WWW-Authenticate .................................... 62
* 13 Caching ..................................................... 62
* 14 Examples .................................................... 63
+ 14.1 Media on Demand (Unicast) ............................ 63
+ 14.2 Streaming of a Container file ........................ 65
+ 14.3 Single Stream Container Files ........................ 67
+ 14.4 Live Media Presentation Using Multicast .............. 69
+ 14.5 Playing media into an existing session ............... 70
+ 14.6 Recording ............................................ 71
* 15 Syntax ...................................................... 72
+ 15.1 Base Syntax .......................................... 72
* 16 Security Considerations ..................................... 73
* A RTSP Protocol State Machines ................................. 76
+ A.1 Client State Machine .................................. 76
+ A.2 Server State Machine .................................. 77
* B Interaction with RTP ......................................... 79
* C Use of SDP for RTSP Session Descriptions ..................... 80
+ C.1 Definitions ........................................... 80
o C.1.1 Control URL .................................... 80
o C.1.2 Media streams .................................. 81
o C.1.3 Payload type(s) ................................ 81
o C.1.4 Format-specific parameters ..................... 81
o C.1.5 Range of presentation .......................... 82
o C.1.6 Time of availability ........................... 82
o C.1.7 Connection Information ......................... 82
o C.1.8 Entity Tag ..................................... 82
+ C.2 Aggregate Control Not Available ....................... 83
+ C.3 Aggregate Control Available ........................... 83
* D Minimal RTSP implementation .................................. 85
+ D.1 Client ................................................ 85
o D.1.1 Basic Playback ................................. 86
o D.1.2 Authentication-enabled ......................... 86
+ D.2 Server ................................................ 86
o D.2.1 Basic Playback ................................. 87
o D.2.2 Authentication-enabled ......................... 87
* E Authors' Addresses ........................................... 88
* F Acknowledgements ............................................. 89
* References ..................................................... 90
* Full Copyright Statement ....................................... 92
+ 12.37セッション… 57+12.38タイムスタンプ… 58+12.39輸送… 58 +12.40サポートされない… 62+12.41ユーザエージェント… 62+12.42は異なります… を通して62+12.43、… 62+12.44は…をWWW認証します… 62 *13キャッシュ… 62*14の例… 要求(ユニキャスト)に関する63+14.1のメディア… Containerファイルの63+14.2ストリーミング… 65+14.3の単一の流れの容器はファイルされます… マルチキャストを使用する67+14.4のライブメディアプレゼンテーション… 69+14.5の既存のセッションまでのプレーメディア… 70+14.6録音… 71*15構文… 72+15.1は構文を基礎づけます… 72*16のセキュリティ問題… RTSPプロトコル州が機械加工する73*… 76+A.1属国マシン… 76+A.2サーバ州のマシン… RTPとの77*B相互作用… SDPのRTSPセッション記述の79*C使用… 80+C.1定義… 80o C.1.1 Control URL… 80 o C.1.2メディアの流れ… 81 o C.1.3有効搭載量タイプ… 81 o C.1.4 Format特有のパラメタ… 81 プレゼンテーションのo C.1.5 Range… 82 有用性のo C.1.6 Time… 82 o C.1.7 Connection情報… 82 o C.1.8 Entity Tag… 利用可能でない82+C.2集合コントロール… 利用可能な83+C.3集合コントロール… 83*D最小量のRTSP実現… 85+D.1クライアント… 85 o D.1.1 Basic Playback… 86 oは…をD.1.2 Authentication可能にしました… 86+D.2サーバ… 86 o D.2.1 Basic Playback… 87 oは…をD.2.2 Authentication可能にしました… 87*E作者のアドレス… 88*F承認… 89 *参照… 90 *完全な著作権宣言文… 92
Schulzrinne, et. al. Standards Track [Page 4] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[4ページ]RFC2326リアルタイム
1 Introduction
1つの序論
1.1 Purpose
1.1 目的
The Real-Time Streaming Protocol (RTSP) establishes and controls either a single or several time-synchronized streams of continuous media such as audio and video. It does not typically deliver the continuous streams itself, although interleaving of the continuous media stream with the control stream is possible (see Section 10.12). In other words, RTSP acts as a "network remote control" for multimedia servers.
レアル-時間Streamingプロトコル(RTSP)は、オーディオやビデオなどの連続したメディアのシングルかいくつかの時間で連動している流れのどちらかを確立して、制御します。 それ自体は連続した流れを通常届けません、制御ストリームによる連続したメディアの流れのインターリービングが可能ですが(セクション10.12を見てください)。 言い換えれば、RTSPはマルチメディアのための「遠隔操作をネットワークでつないでください」というサーバとして機能します。
The set of streams to be controlled is defined by a presentation description. This memorandum does not define a format for a presentation description.
制御されるべき流れのセットはプレゼンテーション記述で定義されます。 このメモはプレゼンテーション記述のために書式を定義しません。
There is no notion of an RTSP connection; instead, a server maintains a session labeled by an identifier. An RTSP session is in no way tied to a transport-level connection such as a TCP connection. During an RTSP session, an RTSP client may open and close many reliable transport connections to the server to issue RTSP requests. Alternatively, it may use a connectionless transport protocol such as UDP.
RTSP接続の概念が全くありません。 代わりに、サーバは識別子によってラベルされたセッションを維持します。 RTSPセッションはTCP接続などの輸送レベル接続に決して結ばれません。 RTSPセッションの間、RTSPクライアントは、RTSPに要求を出すために多くの頼もしい輸送の接続をサーバに開いて、終えるかもしれません。 あるいはまた、それはUDPなどのコネクションレスなトランスポート・プロトコルを使用するかもしれません。
The streams controlled by RTSP may use RTP [1], but the operation of RTSP does not depend on the transport mechanism used to carry continuous media. The protocol is intentionally similar in syntax and operation to HTTP/1.1 [2] so that extension mechanisms to HTTP can in most cases also be added to RTSP. However, RTSP differs in a number of important aspects from HTTP:
RTSPによって制御された流れはRTP[1]を使用するかもしれませんが、RTSPの操作は連続したメディアを運ぶのに使用される移送機構によりません。 プロトコルは、[2] また、多くの場合、HTTPへの拡大メカニズムをRTSPに加えることができるくらい故意に構文と操作においてHTTP/1.1と同様です。 しかしながら、RTSPは多くの重要な一面でHTTPと異なります:
* RTSP introduces a number of new methods and has a different
protocol identifier.
* An RTSP server needs to maintain state by default in almost all
cases, as opposed to the stateless nature of HTTP.
* Both an RTSP server and client can issue requests.
* Data is carried out-of-band by a different protocol. (There is an
exception to this.)
* RTSP is defined to use ISO 10646 (UTF-8) rather than ISO 8859-1,
consistent with current HTML internationalization efforts [3].
* The Request-URI always contains the absolute URI. Because of
backward compatibility with a historical blunder, HTTP/1.1 [2]
carries only the absolute path in the request and puts the host
name in a separate header field.
* RTSPは多くの新しいメソッドを導入して、異なったプロトコル識別子を持っています。 * RTSPサーバは、デフォルトでほとんどすべての場合状態を維持する必要があります、HTTPの状態がない本質と対照的に。 * ともに、RTSPサーバとクライアントは要求を出すことができます。 * データは異なったプロトコルによってバンドの外まで運ばれます。 (これへの例外があります。) * RTSPは、現在のHTML国際化取り組み[3]と一致したISO8859-1よりむしろISO10646(UTF-8)を使用するために定義されます。 * Request-URIはいつも絶対URIを含んでいます。 歴史的な大失敗との後方の互換性のために、HTTP/1.1[2]は要求における絶対パスだけを運んで、別々のヘッダーフィールドにホスト名を入れます。
This makes "virtual hosting" easier, where a single host with one
IP address hosts several document trees.
これで、1つのIPアドレスをもっている独身のホストがいくつかのドキュメント木を接待するところで「仮想の接待」は、より簡単になります。
Schulzrinne, et. al. Standards Track [Page 5] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[5ページ]RFC2326リアルタイム
The protocol supports the following operations:
プロトコルは以下の操作をサポートします:
Retrieval of media from media server:
The client can request a presentation description via HTTP or
some other method. If the presentation is being multicast, the
presentation description contains the multicast addresses and
ports to be used for the continuous media. If the presentation
is to be sent only to the client via unicast, the client
provides the destination for security reasons.
メディアサーバからのメディアの検索: クライアントはHTTPかある他のメソッドでプレゼンテーション記述を要求できます。 プレゼンテーションがマルチキャストであるなら、プレゼンテーション記述は連続したメディアに使用されるべきマルチキャストアドレスとポートを含んでいます。 プレゼンテーションがユニキャストでクライアントだけに送ることであるなら、クライアントは安全保障上の理由で目的地を提供します。
Invitation of a media server to a conference:
A media server can be "invited" to join an existing
conference, either to play back media into the presentation or
to record all or a subset of the media in a presentation. This
mode is useful for distributed teaching applications. Several
parties in the conference may take turns "pushing the remote
control buttons."
メディアサーバの会議への招待: 既存の会議、メディアをプレゼンテーションに再生するか、またはすべてを記録するどちらかまたはメディアの部分集合にプレゼンテーションに参加するようにメディアサーバを「招待できます」。 このモードは分配された教育アプリケーションの役に立ちます。 会議における数人のパーティーが、「遠隔操作ボタンを押し」ながら、角を曲がるかもしれません。
Addition of media to an existing presentation:
Particularly for live presentations, it is useful if the
server can tell the client about additional media becoming
available.
既存のプレゼンテーションへのメディアの参加: 特にライブプレゼンテーションに、サーバが利用可能になる追加メディアに関してクライアントに示すことができるなら、役に立ちます。
RTSP requests may be handled by proxies, tunnels and caches as in HTTP/1.1 [2].
RTSP要求はHTTP/1.1[2]のようにプロキシ、トンネル、およびキャッシュによって扱われるかもしれません。
1.2 Requirements
1.2 要件
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[4]で説明されるように本書では解釈されることであるべきですか?
1.3 Terminology
1.3 用語
Some of the terminology has been adopted from HTTP/1.1 [2]. Terms not listed here are defined as in HTTP/1.1.
用語のいくつかがHTTP/1.1[2]から採用されました。 ここにリストアップされなかった用語はHTTP/1.1のように定義されます。
Aggregate control:
The control of the multiple streams using a single timeline by
the server. For audio/video feeds, this means that the client
may issue a single play or pause message to control both the
audio and video feeds.
コントロールに集めてください: 倍数のコントロールは、サーバでただ一つのスケジュールを使用することで流れます。オーディオ/ビデオ給送のために、これは、クライアントがただ一つのプレーかオーディオとビデオ給送の両方を制御するくぎりのメッセージを発行するかもしれないことを意味します。
Conference:
a multiparty, multimedia presentation, where "multi" implies
greater than or equal to one.
コンファレンス: 「マルチ-パーティー」、マルチメディアを使ったプレゼンテーション。(そこでは、「マルチ」が1以上を含意します)。
Schulzrinne, et. al. Standards Track [Page 6] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[6ページ]RFC2326リアルタイム
Client:
The client requests continuous media data from the media
server.
クライアント: クライアントはメディアサーバから連続したメディアデータを要求します。
Connection:
A transport layer virtual circuit established between two
programs for the purpose of communication.
接続: トランスポート層の仮想の回路は2の間にコミュニケーションの目的のためのプログラムを設立しました。
Container file:
A file which may contain multiple media streams which often
comprise a presentation when played together. RTSP servers may
offer aggregate control on these files, though the concept of
a container file is not embedded in the protocol.
コンテナファイル: 一緒にプレーされるとしばしばプレゼンテーションを包括するマルチメディアストリームを含むかもしれないファイル。 RTSPサーバはこれらのファイルに対しては集合コントロールを提供するかもしれません、コンテナファイルの概念がプロトコルに埋め込まれていませんが。
Continuous media:
Data where there is a timing relationship between source and
sink; that is, the sink must 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), where there is a "tight"
timing relationship between source and sink, or streaming
(playback), where the relationship is less strict.
連続したメディア: ソースと流し台とのタイミング関係があるデータ。 すなわち、流し台はソースに存在したタイミング関係を再生させなければなりません。 連続したメディアの最も一般的な例は、オーディオと動画ビデオです。 連続したメディアはリアルタイムの(インタラクティブ)であることができます。(そこに、ソースと流し台か、ストリーミング(再生)との「きつい」タイミング関係があります)。そこでは、関係がそれほど厳しくはありません。
Entity:
The information transferred as the payload of a request or
response. An entity consists of metainformation in the form of
entity-header fields and content in the form of an entity-
body, as described in Section 8.
実体: 情報は要求か応答のペイロードとして移されました。 実体は実体本体の形で実体ヘッダーフィールドと内容の形でmetainformationから成ります、セクション8で説明されるように。
Media initialization:
Datatype/codec specific initialization. This includes such
things as clockrates, color tables, etc. Any transport-
independent information which is required by a client for
playback of a media stream occurs in the media initialization
phase of stream setup.
メディア初期化: データ型式/コーデックの特定の初期化。 これはclockratesのようなもの、カラーテーブルなどを含んでいます。 メディアストリームの再生のためにクライアントによって必要とされる輸送の独立している情報はストリームセットアップのメディア初期設定段階で現れます。
Media parameter:
Parameter specific to a media type that may be changed before
or during stream playback.
メディアパラメタ: 再生の前かストリーム再生間に変えられるかもしれないメディアタイプに、特定のパラメタ。
Media server:
The server providing playback or recording 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 or a different host as the
web server the presentation is invoked from.
メディアサーバ: 1つ以上のメディアのために再生を提供するか、またはサービスを記録するサーバは流れます。プレゼンテーションの中の異なったメディアストリームは異なったメディアサーバから発するかもしれません。 メディアサーバはプレゼンテーションが呼び出されるウェブサーバーとして同じくらいか異なったホストの上にあるかもしれません。
Schulzrinne, et. al. Standards Track [Page 7] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[7ページ]RFC2326リアルタイム
Media server indirection:
Redirection of a media client to a different media server.
メディアサーバ間接指定: 異なったメディアサーバへのメディアクライアントのリダイレクション。
(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 source within an RTP session. This is
equivalent to the definition of a DSM-CC stream([5]).
(メディア)は流れます: ただ一つのメディアインスタンス、例えば、オーディオストリームまたはビデオが単一のホワイトボードか共有された応用グループと同様に流れます。 RTPを使用するとき、ストリームはRTPセッション以内にソースによって作成されたすべてのRTPとRTCPパケットから成ります。 これはDSM-CCストリーム([5])の定義に同等です。
Message:
The basic unit of RTSP communication, consisting of a
structured sequence of octets matching the syntax defined in
Section 15 and transmitted via a connection or a
connectionless protocol.
メッセージ: RTSPコミュニケーションの原単位、構文に合っている八重奏の構造化された系列から成るのは、接続かコネクションレスプロトコルをセクション15で定義して、伝わりました。
Participant:
Member of a conference. A participant may be a machine, e.g.,
a media record or playback server.
関係者: 会議のメンバー。 関係者はマシン、例えば、メディア記録であるかもしれませんか再生がサーバです。
Presentation:
A set of one or more streams presented to the client as a
complete media feed, using a presentation description as
defined below. In most cases in the RTSP context, this implies
aggregate control of those streams, but does not have to.
プレゼンテーション: 以下で定義されるようにプレゼンテーション記述を使用して、完全なメディア給送としてクライアントに提示された1つ以上のストリームのセット。 多くの場合RTSP文脈では、含意する必要はないのを除いて、これはそれらのストリームの集合コントロールを含意します。
Presentation description:
A presentation description contains information about one or
more media streams within a presentation, such as the set of
encodings, network addresses and information about the
content. Other IETF protocols such as SDP (RFC 2327 [6]) use
the term "session" for a live presentation. The presentation
description may take several different formats, including but
not limited to the session description format SDP.
プレゼンテーション記述: プレゼンテーション記述が1時頃に情報を含むか、またはencodingsのセットなどのプレゼンテーションの中の、より多くのメディアストリームが内容のアドレスと情報をネットワークでつなぎます。 SDPなどの他のIETFプロトコル、(RFC2327[6])はaライブプレゼンテーションに「セッション」という用語を使用します。 プレゼンテーション記述はいくつかの異なった形式、他を含んでいるのにセッション記述形式SDPを取るかもしれません。
Response:
An RTSP response. If an HTTP response is meant, that is
indicated explicitly.
応答: RTSP応答。 HTTP応答が意味されるなら、それは明らかに示されます。
Request:
An RTSP request. If an HTTP request is meant, that is
indicated explicitly.
以下を要求してください。 RTSP要求。 HTTP要求が意味されるなら、それは明らかに示されます。
RTSP session:
A complete RTSP "transaction", e.g., the viewing of a movie.
A session typically consists of a client setting up a
transport mechanism for the continuous media stream (SETUP),
starting the stream with PLAY or RECORD, and closing the
RTSPセッション: 完全なRTSP「トランザクション」、例えば、映画を見ること。 セッションは連続したメディアストリーム(SETUP)のために移送機構をセットアップしているクライアントから通常成ります、PLAYかRECORDと、閉鎖があるストリームを始めて
Schulzrinne, et. al. Standards Track [Page 8] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[8ページ]RFC2326リアルタイム
stream with TEARDOWN.
TEARDOWNであふれてください。
Transport initialization:
The negotiation of transport information (e.g., port numbers,
transport protocols) between the client and the server.
初期化を輸送してください: クライアントとサーバの間の輸送情報(例えば、ポートナンバー、トランスポート・プロトコル)の交渉。
1.4 Protocol Properties
1.4 プロトコルの特性
RTSP has the following properties:
RTSPには、以下の特性があります:
Extendable:
New methods and parameters can be easily added to RTSP.
Extendable: 容易に新しいメソッドとパラメタをRTSPに加えることができます。
Easy to parse:
RTSP can be parsed by standard HTTP or MIME parsers.
分析する簡単: 標準のHTTPかMIMEパーサがRTSPを分析できます。
Secure:
RTSP re-uses web security mechanisms. All HTTP authentication
mechanisms such as basic (RFC 2068 [2, Section 11.1]) and
digest authentication (RFC 2069 [8]) are directly applicable.
One may also reuse transport or network layer security
mechanisms.
機密保護します: RTSPは基本的であるように(RFC2068[2、セクション11.1])ウェブセキュリティー対策すべてのHTTP認証機構を再使用して、認証を読みこなします。(RFC2069[8])は直接適切です。 また、輸送かネットワーク層セキュリティー対策を再利用するかもしれません。
Transport-independent:
RTSP may use either an unreliable datagram protocol (UDP) (RFC
768 [9]), a reliable datagram protocol (RDP, RFC 1151, not
widely used [10]) or a reliable stream protocol such as TCP
(RFC 793 [11]) as it implements application-level reliability.
輸送独立者: RDP(RFC1151)は広く[10])かTCPなどの信頼できるストリームプロトコルを使用しませんでした。RTSPが頼り無いデータグラムプロトコル(UDP)を使用するかもしれない、(RFC768[9])、信頼できるデータグラムプロトコル、((それとしてのRFC793[11])はアプリケーションレベルの信頼性を実装します。
Multi-server capable:
Each media stream within a presentation can reside on a
different server. The client automatically establishes several
concurrent control sessions with the different media servers.
Media synchronization is performed at the transport level.
できるマルチサーバ: プレゼンテーションの中のそれぞれのメディアストリームは異なったサーバにあることができます。クライアントは自動的に異なったメディアサーバとのいくつかの同時発生のコントロールセッションを確立します。 メディア同期は輸送レベルで実行されます。
Control of recording devices:
The protocol can control both recording and playback devices,
as well as devices that can alternate between the two modes
("VCR").
録音装置のコントロール: プロトコルは録音と再生デバイスの両方を制御できます、2つのモード("VCR")の間を行き来することができるデバイスと同様に。
Separation of stream control and conference initiation:
Stream control is divorced from inviting a media server to a
conference. The only requirement is that the conference
initiation protocol either provides or can be used to create a
unique conference identifier. In particular, SIP [12] or H.323
[13] may be used to invite a server to a conference.
ストリームコントロールと会議の開始の離別: ストリームコントロールはメディアサーバを会議に招待するのと離婚します。 唯一の要件は会議開始プロトコルを提供するか、またはユニークな会議識別子を作成するのに使用できるということです。 特に、SIP[12]かH.323[13]が、会議にサーバを招待するのに使用されるかもしれません。
Schulzrinne, et. al. Standards Track [Page 9] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[9ページ]RFC2326リアルタイム
Suitable for professional applications:
RTSP supports frame-level accuracy through SMPTE time stamps
to allow remote digital editing.
プロのアプリケーションに適する: RTSPは、リモートデジタル編集を許すためにSMPTEタイムスタンプを通してフレーム平らな精度をサポートします。
Presentation description neutral:
The protocol does not impose a particular presentation
description or metafile format and can convey the type of
format to be used. However, the presentation description must
contain at least one RTSP URI.
プレゼンテーション記述中立: プロトコルは、特定のプレゼンテーション記述かメタファイル形式を課さないで、使用されるために形式のタイプを伝えることができます。 しかしながら、プレゼンテーション記述は少なくとも1RTSP URIを含まなければなりません。
Proxy and firewall friendly:
The protocol should be readily handled by both application and
transport-layer (SOCKS [14]) firewalls. A firewall may need to
understand the SETUP method to open a "hole" for the UDP media
stream.
プロキシとファイアウォール好意的: アプリケーションとトランスポート層の両方によって扱われて、プロトコルは容易にそうであるべきです。(SOCKS[14])ファイアウォール。 ファイアウォールは、UDPメディアストリームのために「穴」を開くSETUPメソッドを理解する必要があるかもしれません。
HTTP-friendly:
Where sensible, RTSP reuses HTTP concepts, so that the
existing infrastructure can be reused. This infrastructure
includes PICS (Platform for Internet Content Selection
[15,16]) for associating labels with content. However, RTSP
does not just add methods to HTTP since the controlling
continuous media requires server state in most cases.
HTTPに優しい: 分別があるところでは、RTSPが、既存のインフラストラクチャを再利用できるようにHTTP概念を再利用します。 このインフラストラクチャはラベルを内容に関連づけるためのPICS(インターネットContent Selection[15、16]のためのプラットホーム)を含んでいます。 しかしながら、制御の連続したメディアが多くの場合サーバ状態を必要とするので、RTSPはただメソッドをHTTPに追加しません。
Appropriate server control:
If a client can start a stream, it must be able to stop a
stream. Servers should not start streaming to clients in such
a way that clients cannot stop the stream.
サーバ制御装置を当ててください: クライアントがストリームを始めることができるなら、流れを止めることができなければなりません。 サーバは、クライアントがストリームを止めることができないような方法でクライアントに流れ始めるべきではありません。
Transport negotiation:
The client can negotiate the transport method prior to
actually needing to process a continuous media stream.
交渉を輸送してください: クライアントは実際に連続したメディアストリームを処理するのが必要である前に、輸送メソッドを交渉できます。
Capability negotiation:
If basic features are disabled, there must be some clean
mechanism for the client to determine which methods are not
going to be implemented. This allows clients to present the
appropriate user interface. For example, if seeking is not
allowed, the user interface must be able to disallow moving a
sliding position indicator.
能力交渉: 基本的特徴は障害があるなら、メソッドが実装されないクライアントが決定する何らかの清潔なメカニズムがあるに違いありません。 これで、クライアントは適切なユーザーインタフェースを提示できます。 例えば、探知が許されていないなら、ユーザーインタフェースは、滑っている位置のインディケータを動かすのを禁じることができなければなりません。
An earlier requirement in RTSP was multi-client capability.
However, it was determined that a better approach was to make sure
that the protocol is easily extensible to the multi-client
scenario. Stream identifiers can be used by several control
streams, so that "passing the remote" would be possible. The
protocol would not address how several clients negotiate access;
this is left to either a "social protocol" or some other floor
RTSPの以前の要件はマルチクライアント能力でした。 しかしながら、プロトコルが容易にマルチクライアントシナリオに広げることができるのをより良いアプローチがことであった確実にするのは決定していました。 「リモートを通過します」が可能であるように、いくつかの制御ストリームでストリーム識別子を使用できます。 プロトコルは数人のクライアントがどうアクセスを交渉するかを扱わないでしょう。 これは「社会的なプロトコル」か床のどちらかにある他の発たれます。
Schulzrinne, et. al. Standards Track [Page 10] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[10ページ]RFC2326リアルタイム
control mechanism.
メカニズムを制御してください。
1.5 Extending RTSP
1.5 RTSPを広げること。
Since not all media servers have the same functionality, media servers by necessity will support different sets of requests. For example:
すべてのメディアサーバには同じ機能性があるというわけではないので、必要に迫られてのメディアサーバは異なったセットの要求をサポートするでしょう。 例えば:
* A server may only be capable of playback thus has no need to
support the RECORD request.
* A server may not be capable of seeking (absolute positioning) if
it is to support live events only.
* Some servers may not support setting stream parameters and thus
not support GET_PARAMETER and SET_PARAMETER.
* サーバは再生ができるだけであるかもしれません。その結果、いいえは、RECORD要求をサポートする必要があらせます。 * ライブイベントだけをサポートするつもりであるなら、サーバは(絶対位置決め方式)を探すことができないかもしれません。 * いくつかのサーバは、GET_PARAMETERとSET_がPARAMETERであると設定がストリームパラメタであるとサポートしないで、またその結果、サポートしないかもしれません。
A server SHOULD implement all header fields described in Section 12.
すべてのヘッダーフィールドがセクション12で説明したサーバSHOULD道具。
It is up to the creators of presentation descriptions not to ask the impossible of a server. This situation is similar in HTTP/1.1 [2], where the methods described in [H19.6] are not likely to be supported across all servers.
サーバの不可能を尋ねないのはプレゼンテーション記述のクリエイターまで達しています。この状況はHTTP/1.1[2]で同様です。そこでは、[H19.6]で説明されたメソッドがすべてのサーバの向こう側にサポートされそうにはありません。
RTSP can be extended in three ways, listed here in order of the magnitude of changes supported:
サポートされた変化の大きさの順にここに記載された3つの方法でRTSPを広げることができます:
* Existing methods can be extended with new parameters, as long as
these parameters can be safely ignored by the recipient. (This is
equivalent to adding new parameters to an HTML tag.) If the
client needs negative acknowledgement when a method extension is
not supported, a tag corresponding to the extension may be added
in the Require: field (see Section 12.32).
* New methods can be added. If the recipient of the message does
not understand the request, it responds with error code 501 (Not
implemented) and the sender should not attempt to use this method
again. A client may also use the OPTIONS method to inquire about
methods supported by the server. The server SHOULD list the
methods it supports using the Public response header.
* A new version of the protocol can be defined, allowing almost all
aspects (except the position of the protocol version number) to
change.
* 受取人が安全にこれらのパラメタを無視できる限り、新しいパラメタで既存の方法を広げることができます。 (これはHTMLタグに新しいパラメタを加えるのに同等です。) メソッド拡大がサポートされないとき、クライアントが否定的承認を必要とするなら、拡大に対応するタグはRequireで加えられるかもしれません: さばきます(セクション12.32を見ます)。 * 新しいメソッドを加えることができます。 メッセージの受取人が要求を理解していないなら、エラーコード501(実装されません)でこたえます、そして、送付者は再びこのメソッドを使用するのを試みるべきではありません。 また、クライアントはサーバによってサポートされたメソッドについて問い合わせをするOPTIONSメソッドを使用するかもしれません。サーバSHOULDは、Public応答ヘッダを使用することでそれがサポートするメソッドを記載します。 * プロトコルの新しいバージョンを定義できます、ほとんどすべての局面(プロトコルバージョン番号の位置を除いた)が変化するのを許容して。
1.6 Overall Operation
1.6 総合的な操作
Each presentation and media stream may be identified by an RTSP URL. The overall presentation and the properties of the media the presentation is made up of are defined by a presentation description file, the format of which is outside the scope of this specification. The presentation description file may be obtained by the client using
それぞれのプレゼンテーションとメディアストリームはRTSP URLによって特定されるかもしれません。 プレゼンテーションが上がるようにされるメディアの総合的なプレゼンテーションと特性はプレゼンテーション記述ファイルによって定義されます。この仕様の範囲の外にその形式はあります。 クライアント使用でプレゼンテーション記述ファイルを入手するかもしれません。
Schulzrinne, et. al. Standards Track [Page 11] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[11ページ]RFC2326リアルタイム
HTTP or other means such as email and may not necessarily be stored on the media server.
何らかのHTTPは、メールとしてそのようなものを意味して、必ずメディアサーバに保存されるかもしれないというわけではありません。
For the purposes of this specification, a presentation description is assumed to describe one or more presentations, each of which maintains a common time axis. For simplicity of exposition and without loss of generality, it is assumed that the presentation description contains exactly one such presentation. A presentation may contain several media streams.
この仕様の目的のために、プレゼンテーション記述が1つ以上のプレゼンテーションについて説明すると思われます。それはそれぞれ一般的な時間軸を維持します。 博覧会の簡単さと一般性の喪失がなければ、プレゼンテーション記述がまさにそのようなプレゼンテーションの1つを含むと思われます。 プレゼンテーションはいくつかのメディアストリームを含むかもしれません。
The presentation description file contains a description of the media streams making up the presentation, including their encodings, language, and other parameters that enable the client to choose the most appropriate combination of media. In this presentation description, each media stream that is individually controllable by RTSP is identified by an RTSP URL, which points to the media server handling that particular media stream and names the stream stored on that server. Several media streams can be located on different servers; for example, audio and video streams can be split across servers for load sharing. The description also enumerates which transport methods the server is capable of.
プレゼンテーション記述ファイルはプレゼンテーションを作るメディアストリームの記述を含んでいます、クライアントがメディアの最も適切な組み合わせを選ぶのを可能にするそれらのencodings、言語、および他のパラメタを含んでいて。 このプレゼンテーション記述では、RTSP URLはそれぞれのRTSPが個別に制御可能なメディアストリームを特定します。(RTSP URLはその特定のメディアストリームを扱うメディアサーバとストリームがそのサーバに保存した名前を示します)。異なったサーバにいくつかのメディアストリームを位置させることができます。 例えば、負荷分割法のためにサーバの向こう側にオーディオとビデオストリームを分けることができます。 また、記述はサーバができるどの輸送メソッドを列挙するか。
Besides the media parameters, the network destination address and port need to be determined. Several modes of operation can be distinguished:
そのうえ、メディアパラメタ、ネットワーク送付先アドレス、およびポートは、断固とする必要があります。 いくつかの運転モードを区別できます:
Unicast:
The media is transmitted to the source of the RTSP request,
with the port number chosen by the client. Alternatively, the
media is transmitted on the same reliable stream as RTSP.
ユニキャスト: ポートナンバーがクライアントによって選ばれている状態で、メディアはRTSP要求の源に伝えられます。 あるいはまた、メディアはRTSPと同じ信頼できるストリームで伝えられます。
Multicast, server chooses address:
The media server picks the multicast address and port. This is
the typical case for a live or near-media-on-demand
transmission.
マルチキャスト、サーバはアドレスを選びます: メディアサーバはマルチキャストアドレスとポートを選びます。 これはライブであるかメディアの近くで要求次第のトランスミッションのための典型的なそうです。
Multicast, client chooses address:
If the server is to participate in an existing multicast
conference, the multicast address, port and encryption key are
given by the conference description, established by means
outside the scope of this specification.
マルチキャスト、クライアントはアドレスを選びます: サーバが既存のマルチキャスト会議に参加することであるなら、この仕様の範囲の外の手段で確立された会議記述でマルチキャストアドレス、ポート、および暗号化キーを与えます。
1.7 RTSP States
1.7 RTSP州
RTSP controls a stream which may be sent via a separate protocol, independent of the control channel. For example, RTSP control may occur on a TCP connection while the data flows via UDP. Thus, data delivery continues even if no RTSP requests are received by the media
RTSPは制御チャンネルの如何にかかわらず別々のプロトコルで送られるかもしれないストリームを制御します。 例えば、データがUDPを通して流れている間、RTSPコントロールはTCP接続のときに起こるかもしれません。 したがって、RTSP要求が全くメディアによって受け取られないでも、データ配送は続きます。
Schulzrinne, et. al. Standards Track [Page 12] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[12ページ]RFC2326リアルタイム
server. Also, during its lifetime, a single media stream may be controlled by RTSP requests issued sequentially on different TCP connections. Therefore, the server needs to maintain "session state" to be able to correlate RTSP requests with a stream. The state transitions are described in Section A.
サーバまた、生涯、ただ一つのメディアストリームは異なったTCP接続のときに連続して出されたRTSP要求で制御されるかもしれません。 したがって、サーバは、「セッション状態」がストリームでRTSP要求を関連させることができると主張する必要があります。 状態遷移はセクションAで説明されます。
Many methods in RTSP do not contribute to state. However, the following play a central role in defining the allocation and usage of stream resources on the server: SETUP, PLAY, RECORD, PAUSE, and TEARDOWN.
RTSPの多くのメソッドは状態に貢献しません。 しかしながら、以下はサーバに関するストリームリソースの配分と用法を定義する際に中心的役割を果たします: セットアップ、プレー、記録、くぎり、および分解。
SETUP:
Causes the server to allocate resources for a stream and start
an RTSP session.
セットアップ: サーバがストリームのためのリソースを割り当てて、RTSPセッションを始めることを引き起こします。
PLAY and RECORD:
Starts data transmission on a stream allocated via SETUP.
プレーしてください、そして、記録してください: ストリームに関するデータ伝送がSETUPを通して割り当てた始め。
PAUSE:
Temporarily halts a stream without freeing server resources.
以下をポーズしてください。 一時、サーバリソースを解放しないで、ストリームを止めます。
TEARDOWN:
Frees resources associated with the stream. The RTSP session
ceases to exist on the server.
分解: ストリームに関連しているリソースを解放します。 RTSPセッションは、サーバに存在するのをやめます。
RTSP methods that contribute to state use the Session header
field (Section 12.37) to identify the RTSP session whose state
is being manipulated. The server generates session identifiers
in response to SETUP requests (Section 10.4).
状態に貢献するRTSPメソッドは、状態が操られているRTSPセッションを特定するのに、Sessionヘッダーフィールド(セクション12.37)を使用します。 サーバはSETUP要求(セクション10.4)に対応してセッション識別子を生成します。
1.8 Relationship with Other Protocols
1.8 他のプロトコルとの関係
RTSP has some overlap in functionality with HTTP. It also may interact with HTTP in that the initial contact with streaming content is often to be made through a web page. The current protocol specification aims to allow different hand-off points between a web server and the media server implementing RTSP. For example, the presentation description can be retrieved using HTTP or RTSP, which reduces roundtrips in web-browser-based scenarios, yet also allows for standalone RTSP servers and clients which do not rely on HTTP at all.
RTSPには、機能性での何らかのオーバラップがHTTPと共にあります。 また、しばしばストリーミングの内容との初期接触がウェブページを通して作られていることになっているので、それはHTTPと対話するかもしれません。 現在のプロトコル仕様は、ウェブサーバーとRTSPを実装するメディアサーバの間の異なったハンドオフポイントを許容することを目指します。 例えば、HTTPかRTSP(ウェブブラウザベースのシナリオにおける往復旅行を抑えて、また、まだスタンドアロンRTSPサーバとクライアントを考慮している)を使用することでプレゼンテーション記述を検索できます(全くHTTPを当てにしません)。
However, RTSP differs fundamentally from HTTP in that data delivery takes place out-of-band in a different protocol. HTTP is an asymmetric protocol where the client issues requests and the server responds. In RTSP, both the media client and media server can issue requests. RTSP requests are also not stateless; they may set parameters and continue to control a media stream long after the
しかしながら、RTSPはデータ配送がバンドの外で異なったプロトコルで行われるという点において基本的にHTTPと異なっています。 HTTPはクライアントが要求を出す非対称のプロトコルです、そして、サーバは反応します。 RTSPでは、メディアクライアントとメディアサーバの両方が要求を出すことができます。 また、RTSP要求も状態がなくはありません。 彼らは、パラメタを設定して、ずっと後にメディアストリームを制御し続けるかもしれません。
Schulzrinne, et. al. Standards Track [Page 13] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[13ページ]RFC2326リアルタイム
request has been acknowledged.
要求は承諾されました。
Re-using HTTP functionality has advantages in at least two areas,
namely security and proxies. The requirements are very similar, so
having the ability to adopt HTTP work on caches, proxies and
authentication is valuable.
HTTPの機能性を再使用するのはすなわち、少なくとも2つの領域、セキュリティ、およびプロキシでうま味があります。 要件が非常に同様であるので、キャッシュ、プロキシ、および認証に対するHTTP仕事を採用する能力を持っているのは貴重です。
While most real-time media will use RTP as a transport protocol, RTSP is not tied to RTP.
ほとんどのリアルタイムのメディアがトランスポート・プロトコルとしてRTPを使用している間、RTSPはRTPに結ばれません。
RTSP assumes the existence of a presentation description format that can express both static and temporal properties of a presentation containing several media streams.
RTSPは静的なものといくつかのメディアストリームを含むプレゼンテーションの同様に時の特性を示すことができるプレゼンテーション記述形式の存在を仮定します。
2 Notational Conventions
2 記号法のコンベンション
Since many of the definitions and syntax are identical to HTTP/1.1, this specification only points to the section where they are defined rather than copying it. For brevity, [HX.Y] is to be taken to refer to Section X.Y of the current HTTP/1.1 specification (RFC 2068 [2]).
定義と構文の多くがHTTP/1.1と同じであるので、この仕様はそれらがそれをコピーするよりむしろ定義されるセクションを示すだけです。 簡潔さにおいて、[HX.Y]は、現在のHTTP/1.1仕様のセクションX.Yについて言及するために取られることになっています。(RFC2068[2])。
All the mechanisms specified in this document are described in both prose and an augmented Backus-Naur form (BNF) similar to that used in [H2.1]. It is described in detail in RFC 2234 [17], with the difference that this RTSP specification maintains the "1#" notation for comma-separated lists.
本書では指定されたすべてのメカニズムが散文と[H2.1]で使用されるそれと同様の増大しているBN記法(BNF)の両方で説明されます。 それはRFC2234[17]で詳細に説明されます、このRTSP仕様が維持する違いで「1#、」 コンマで切り離されたリストのための記法。
In this memo, we use indented and smaller-type paragraphs to provide 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 that they are in RTSP.
このメモでは、私たちは、バックグラウンドと動機を提供するのに入り込まれて、より小さいタイプのパラグラフを使用します。 これがものがRTSPの道である理由に関する理解を仕様の定式化にかかわらなかった読者に与えることを意図します。
3 Protocol Parameters
3 プロトコルパラメタ
3.1 RTSP Version
3.1 RTSPバージョン
[H3.1] applies, with HTTP replaced by RTSP.
[H3.1]はHTTPをRTSPに取り替えていて適用します。
3.2 RTSP URL
3.2 RTSP URL
The "rtsp" and "rtspu" schemes are used to refer to network resources via the RTSP protocol. This section defines the scheme-specific syntax and semantics for RTSP URLs.
"rtsp"と"rtspu"体系は、RTSPプロトコルでネットワーク資源について言及するのに使用されます。 このセクションはRTSP URLのために体系特有の構文と意味論を定義します。
rtsp_URL = ( "rtsp:" | "rtspu:" )
"//" host [ ":" port ] [ abs_path ]
host = <A legal Internet host domain name of IP address
(in dotted decimal form), as defined by Section 2.1
「rtsp_URL=、(「rtsp:」、|、「rtspu:」、)、」 セクション2.1によって定義されるようにIPの<のA法的なインターネット」 ホスト[「:」 ポート][腹筋_経路]ホスト=ホスト・ドメイン名が扱う(ドット付き10進法フォームで)//
Schulzrinne, et. al. Standards Track [Page 14] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[14ページ]RFC2326リアルタイム
of RFC 1123 \cite{rfc1123}>
port = *DIGIT
RFC1123円では、>が移植するrfc1123=*DIGITを引用してください。
abs_path is defined in [H3.2.1].
腹筋_経路は[H3.2.1]で定義されます。
Note that fragment and query identifiers do not have a well-defined
meaning at this time, with the interpretation left to the RTSP
server.
RTSPサーバまで残っている解釈で断片化してください。そうすれば、質問識別子がこのとき明確な意味を持っていないことに注意してください。
The scheme rtsp requires that commands are issued via a reliable protocol (within the Internet, TCP), while the scheme rtspu identifies an unreliable protocol (within the Internet, UDP).
体系rtspは、信頼できるプロトコル(インターネットの中でTCP)でコマンドが発行されるのを必要とします、体系rtspuが頼り無いプロトコル(インターネットの中でUDP)を特定しますが。
If the port is empty or not given, port 554 is assumed. The semantics are that the identified resource can be controlled by RTSP at the server listening for TCP (scheme "rtsp") connections or UDP (scheme "rtspu") packets on that port of host, and the Request-URI for the resource is rtsp_URL.
ポートが人影がないか考えないで、ポート554は想定されます。 意味論はホストのそのポートの上でTCP(体系"rtsp")接続かUDP(体系"rtspu")パケットの聞こうとするサーバにおけるRTSPが特定されたリソースを制御できるということです、そして、リソースのためのRequest-URIはrtsp_URLです。
The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1924 [19]).
可能であるときはいつも、IPアドレスでは、URL SHOULDで避けられてください。使用、(RFC1924[19])を見てください。
A presentation or a stream is identified by a textual media identifier, using the character set and escape conventions [H3.2] of URLs (RFC 1738 [20]). URLs may refer to a stream or an aggregate of streams, i.e., a presentation. Accordingly, requests described in Section 10 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.
文字集合を使用して、プレゼンテーションかストリームが原文のメディア識別子によって特定されます、そして、URLのコンベンション[H3.2]から逃げてください。(RFC1738[20])。 URLはストリームかストリームの集合、すなわち、プレゼンテーションについて言及するかもしれません。 それに従って、プレゼンテーションの中の全体のプレゼンテーションか個々のストリームのどちらかにセクション10で説明された要求は適用できます。 逆もまた同様にいくつかの要求メソッドをプレゼンテーションではなく、ストリームに適用できるだけであることに注意してください。
For example, the RTSP URL:
rtsp://media.example.com:554/twister/audiotrack
例えば、RTSP URL: rtsp://media.example.com: 554/竜巻/audiotrack
identifies the audio stream within the presentation "twister", which can be controlled via RTSP requests issued over a TCP connection to port 554 of host media.example.com.
554ホストmedia.example.comを移植するためにTCP接続の上で出されたRTSP要求で制御できるプレゼンテーション「竜巻」の中でオーディオストリームを特定します。
Also, the RTSP URL:
rtsp://media.example.com:554/twister
RTSP URLも: rtsp://media.example.com: 554/竜巻
identifies the presentation "twister", which may be composed of audio and video streams.
プレゼンテーション「竜巻」を特定します。(それは、オーディオとビデオストリームで構成されるかもしれません)。
This does not imply a standard way to reference streams in URLs. The presentation description defines the hierarchical relationships in the presentation and the URLs for the individual streams. A presentation description may name a stream "a.mov" and the whole presentation "b.mov".
これはURLの参照ストリームへの標準の道を含意しません。 プレゼンテーション記述は個々のストリームのためにプレゼンテーションとURLで上下関係を定義します。プレゼンテーション記述は「a.mov」と全体のプレゼンテーション「b.mov」とストリームを命名するかもしれません。
Schulzrinne, et. al. Standards Track [Page 15] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[15ページ]RFC2326リアルタイム
The path components of the RTSP URL are opaque to the client and do not imply any particular file system structure for the server.
RTSP URLの経路の部品は、クライアントにとって不透明であり、サーバのための少しの特定のファイルシステム構造も含意しません。
This decoupling also allows presentation descriptions to be used
with non-RTSP media control protocols simply by replacing the
scheme in the URL.
また、このデカップリングは、プレゼンテーション記述が非RTSPメディア制御プロトコルと共にURLで単に体系を取り替えることによって使用されるのを許容します。
3.3 Conference Identifiers
3.3 コンファレンス識別子
Conference identifiers are opaque to RTSP and are encoded using standard URI encoding methods (i.e., LWS is escaped with %). They can contain any octet value. The conference identifier MUST be globally unique. For H.323, the conferenceID value is to be used.
コンファレンス識別子は、RTSPに不透明であり、標準のURIコード化メソッドを使用することでコード化されます(すなわち、LWS%で逃げられます)。 それらはどんな八重奏値も含むことができます。 会議識別子はグローバルにユニークでなければなりません。 H.323に関しては、conferenceID値は使用されていることです。
conference-id = 1*xchar
会議イド=1*xchar
Conference identifiers are used to allow RTSP sessions to obtain
parameters from multimedia conferences the media server is
participating in. These conferences are created by protocols
outside the scope of this specification, e.g., H.323 [13] or SIP
[12]. Instead of the RTSP client explicitly providing transport
information, for example, it asks the media server to use the
values in the conference description instead.
コンファレンス識別子は、RTSPセッションがメディアサーバが参加しているマルチメディア会議からパラメタを得るのを許容するのに使用されます。 これらの会議は例えば、この仕様の範囲、H.323[13]かSIP[12]の外にプロトコルによって創設されます。 明らかに輸送情報を提供するRTSPクライアントの代わりに、例えば、それは、代わりに会議記述に値を使用するようにメディアサーバに頼みます。
3.4 Session Identifiers
3.4 セッション識別子
Session identifiers are opaque strings of arbitrary length. Linear white space must be URL-escaped. A session identifier MUST be chosen randomly and MUST be at least eight octets long to make guessing it more difficult. (See Section 16.)
セッション識別子は任意の長さの不透明なストリングです。 直線的な余白はURLで逃げなければなりません。 セッション識別子は、手当たりしだいに選ばなければならなくて、それを推測するのをより難しくするように長い少なくとも8つの八重奏であるに違いありません。 (セクション16を見てください。)
session-id = 1*( ALPHA | DIGIT | safe )
セッションイド=1*(アルファー|DIGIT|金庫)
3.5 SMPTE Relative Timestamps
3.5 SMPTEの相対的なタイムスタンプ
A SMPTE relative timestamp expresses time relative to the start of the clip. Relative timestamps are expressed as SMPTE time codes for frame-level access accuracy. The time code has the format hours:minutes:seconds:frames.subframes, with the origin at the start of the clip. The default smpte format is "SMPTE 30 drop" format, with frame rate is 29.97 frames per second. Other SMPTE codes MAY be supported (such as "SMPTE 25") through the use of alternative use of "smpte time". For 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 value is zero, it may be omitted. Subframes are measured in one-hundredth of a frame.
SMPTEの相対的なタイムスタンプはクリップの始まりに比例して時間を言い表します。 フレーム・レベルのためのSMPTEタイム・コードが精度にアクセスするとき、相対的なタイムスタンプは言い表されます。 時間コードには、形式が何時間もあります: 発生源がクリップの始めにある数分:秒:frames.subframes。 デフォルトsmpte形式が「SMPTE30低下」形式である、フレームで、レートは1秒あたり29.97個のフレームです。 他のSMPTEコードがサポートされるかもしれない、(「SMPTE、25インチ)、「smpte時間」の代替の使用の使用、」 「フレーム」に関しては、時間的価値における分野は、値が0〜29であると仮定できます。 1秒あたり30と29.97個のフレームの違いは毎分の最初の2つのフレームインデックスリスト(値00と01)を下げることによって、扱われます、10番目の分毎を除いて。 フレーム値がゼロであるなら、それは省略されるかもしれません。 Subframesはフレームの100番目で測定されます。
Schulzrinne, et. al. Standards Track [Page 16] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[16ページ]RFC2326リアルタイム
smpte-range = smpte-type "=" smpte-time "-" [ smpte-time ]
smpte-type = "smpte" | "smpte-30-drop" | "smpte-25"
; other timecodes may be added
smpte-time = 1*2DIGIT ":" 1*2DIGIT ":" 1*2DIGIT [ ":" 1*2DIGIT ]
[ "." 1*2DIGIT ]
smpte-範囲=smpte-タイプはsmpte-時間「-」[smpte-時間]smpte-タイプ="smpte"と「等しいです」。| 「smpte30は低下します」| 「smpte-25インチ」。 「他のtimecodesは加えられたsmpte-時間=1*2DIGITであるかもしれません」:、」 「1*2DIGIT」:、」 1*2DIGIT[「:」 1*2DIGIT][「. 」 1*2DIGIT、]
Examples:
smpte=10:12:33:20-
smpte=10:07:33-
smpte=10:07:00-10:07:33:05.01
smpte-25=10:07:00-10:07:33:05.01
例: smpte=10: 12:33:20smpte=10:07:33smpte=10: 7時0分から10時7分: 33:05.01smpte-25=10: 7時0分から10時7分: 33:05.01
3.6 Normal Play Time
3.6正常なプレー時間
Normal play time (NPT) indicates the stream absolute position relative to the beginning of the presentation. The timestamp consists of a decimal fraction. The part left of the decimal may be expressed in either seconds or hours, minutes, and seconds. The part right of the decimal point measures fractions of a second.
正常なプレー時間(NPT)はプレゼンテーションの始まりに比例してストリーム絶対位置を示します。 タイムスタンプは小数から成ります。 小数について残っている部分は何時間も、数分と、秒か秒のどちらかに表されるかもしれません。 小数点の部分権利は1秒の何分の一を測定します。
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 be used only for live events.
プレゼンテーションの始まりは0.0秒に対応しています。 負の数は定義されません。 特別な定数は現在、ライブイベントの現在の瞬間と定義されます。 それはライブイベントにだけ使用されるかもしれません。
NPT is defined as in DSM-CC: "Intuitively, NPT is the clock the viewer associates with a program. It is often digitally displayed on a VCR. 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 (high negative scale ratio) and is fixed in pause mode. NPT is (logically) equivalent to SMPTE time codes." [5]
NPTはDSM-CC:のように定義されます。 「NPTは直観的に、ビューアーがプログラムに関連づける時計です。」 VCRにそれをしばしばデジタルに表示します。 モードが正常なプレーモード(スケール=1)、速いスキャンフォワードでより速いレートでの進歩(高い陽性尺度比)では、スキャン逆(高い陰性尺度比)でいつを減少させるか、そして、中止して修理されているとき、通常、NPTは進みます。 「NPTはSMPTEタイム・コードに(論理的に)同等です。」 [5]
npt-range = ( npt-time "-" [ npt-time ] ) | ( "-" npt-time ) npt-time = "now" | npt-sec | npt-hhmmss npt-sec = 1*DIGIT [ "." *DIGIT ] npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] npt-hh = 1*DIGIT ; any positive number npt-mm = 1*2DIGIT ; 0-59 npt-ss = 1*2DIGIT ; 0-59
npt-範囲=(npt-時間「-」[npt-時間])| (「-」npt-時間) 「現在」のnpt-時間=| npt-秒| 「npt-hhmmss npt-秒=1*DIGIT[「.」 *ケタ]npt-hhmmssはnpt-hhと等しい」:、」 「npt-mm」:、」 npt-ss、[「. 」 *ケタ] npt-hhは1*ケタと等しいです。 どんな正の数npt-mmも1*2DIGITと等しいです。 0-59 npt-ssは1*2DIGITと等しいです。 0-59
Examples:
npt=123.45-125
npt=12:05:35.3-
npt=now-
例: npt=123.45-125 npt=12: 05:35.3nptが現在等しい、-
The syntax conforms to ISO 8601. The npt-sec notation is optimized
for automatic generation, the ntp-hhmmss notation for consumption
by human readers. The "now" constant allows clients to request to
構文はISO8601に従います。 npt-秒の記法は自動生成、人間の読者による消費のためにntp-hhmmss記法のために最適化されます。 「現在定数が要求するクライアントを許容する」
Schulzrinne, et. al. Standards Track [Page 17] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[17ページ]RFC2326リアルタイム
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.
保存されたか時間で遅れたバージョンよりむしろライブ給送を受けてください。 絶対時間も時間がないのもこのような場合適切でないので、これが必要です。
3.7 Absolute Time
3.7絶対時間
Absolute time is expressed as ISO 8601 timestamps, using UTC (GMT).
Fractions of a second may be indicated.
(グリニッジ標準時に)UTCを使用して、絶対時間はISO8601タイムスタンプとして言い表されます。 1秒の何分の一は示されるかもしれません。
utc-range = "clock" "=" utc-time "-" [ utc-time ]
utc-time = utc-date "T" utc-time "Z"
utc-date = 8DIGIT ; < YYYYMMDD >
utc-time = 6DIGIT [ "." fraction ] ; < HHMMSS.fraction >
utc-範囲=「時計」「=」utc-時間「-」[utc-時間]utc-時間は「T」utc-時間utc-日付「Z」utc-日付=8DIGITと等しいです。 <YYYYMMDD>utc-時間が6DIGITと等しい、[「. 」 断片、]、。 <HHMMSS.fraction>。
Example for November 8, 1996 at 14h37 and 20 and a quarter seconds
UTC:
14h37と20時の1996年11月8日のための例と4分の1秒UTC:
19961108T143720.25Z
19961108T143720.25Z
3.8 Option Tags
3.8 オプションタグ
Option tags are unique identifiers used to designate new options in RTSP. These tags are used in Require (Section 12.32) and Proxy- Require (Section 12.27) header fields.
オプションタグはRTSPの新しいオプションを指定するのに使用されるユニークな識別子です。 これらのタグはRequire(セクション12.32)で使用されます、そして、Proxyはヘッダーフィールドを必要とします(セクション12.27)。
Syntax:
構文:
option-tag = 1*xchar
オプションタグ=1*xchar
The creator of a new RTSP option should either prefix the option with a reverse domain name (e.g., "com.foo.mynewfeature" is an apt name for a feature whose inventor can be reached at "foo.com"), or register the new option with the Internet Assigned Numbers Authority (IANA).
新しいRTSPオプションのクリエイターは、逆のドメイン名(例えば、"com.foo.mynewfeature"は"foo.com"で発明者に連絡できる特徴のためのしやすい名前である)でオプションを前に置くべきであるか、またはインターネットAssigned民数記Authority(IANA)に新しいオプションを登録するべきです。
3.8.1 Registering New Option Tags with IANA
3.8.1 新しいオプションタグをIANAに登録すること。
When registering a new RTSP option, the following information should be provided:
新しいRTSPオプションを登録するとき、以下の情報を提供するべきです:
* Name and description of option. The name may be of any length,
but SHOULD be no more than twenty characters long. The name MUST
not contain any spaces, control characters or periods.
* Indication of who has change control over the option (for
example, IETF, ISO, ITU-T, other international standardization
bodies, a consortium or a particular company or group of
companies);
* オプションの名前と記述。 名前がどんな長さのそうですがも、SHOULDは20のキャラクタが切望するほどそうではありません。 名前はどんな空間、制御文字または期間も含んではいけません。 * だれにオプション(例えば、IETF、ISO、ITU-T、他の国際標準化本体、共同体、特定の会社または企業グループ)の変化コントロールがあるかしるし。
Schulzrinne, et. al. Standards Track [Page 18] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[18ページ]RFC2326リアルタイム
* A reference to a further description, if available, for example
(in order of preference) an RFC, a published paper, a patent
filing, a technical report, documented source code or a computer
manual;
* For proprietary options, contact information (postal and email
address);
* 例えば(好みの順に)、RFC、利用可能であるなら発行された論文、aがファイルしながら特許をとるさらなる記述の参照(技術報告書)はソースコードかコンピュータのマニュアルを記録しました。 * そして、独占オプション、問い合わせ先、(郵便、Eメールアドレス)、。
4 RTSP Message
4RTSPメッセージ
RTSP is a text-based protocol and uses the ISO 10646 character set in UTF-8 encoding (RFC 2279 [21]). Lines are terminated by CRLF, but receivers should be prepared to also interpret CR and LF by themselves as line terminators.
RTSPはテキストベースのプロトコルであり、UTF-8コード化にISO10646文字集合を使用します。(RFC2279[21])。 線はCRLFによって終えられますが、受信機はまた、系列ターミネータとして自分たちでCRとLFを解釈するように準備されるべきです。
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 done carefully, also allow easy
implementation of research prototypes in scripting languages such
as Tcl, Visual Basic and Perl.
テキストベースのプロトコルで、自己について説明する方法による任意のパラメタを加えるのは、より簡単になります。 パラメタの数とコマンドの頻度が下位であるので、処理効率は関心ではありません。 また、慎重にするなら、テキストベースのプロトコルはTclや、Visual BasicやPerlなどのスクリプト言語における研究プロトタイプの簡単な実装を許容します。
The 10646 character set avoids tricky character set switching, but
is invisible to the application as long as US-ASCII is being used.
This is also the encoding used for RTCP. ISO 8859-1 translates
directly into Unicode with a high-order octet of zero. ISO 8859-1
characters with the most-significant bit set are represented as
1100001x 10xxxxxx. (See RFC 2279 [21])
10646文字集合は、油断のならない文字集合の切り換えを避けますが、米国-ASCIIが使用されている限り、アプリケーションに目に見えません。 また、これはRTCPに使用されるコード化です。 ISO8859-1はゼロの高位八重奏で直接ユニコードに翻訳します。 最も多くの重要なビットがセットしたことでのISO8859-1キャラクタは1100001x 10xxxxxxとして代理をされます。 (RFC2279[21])を見てください。
RTSP messages can be carried over any lower-layer transport protocol that is 8-bit clean.
RTSPメッセージを清潔な状態で8ビットであるどんな下層トランスポート・プロトコルにも伝えられることができます。
Requests contain methods, 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.
要求はメソッド、メソッドが作動させているオブジェクト、およびさらにメソッドを説明するパラメタを含んでいます。 別の方法で注意されない場合、メソッドはベキ等元です。 また、メソッドは、メディアサーバでまず州のメインテナンスを必要としないように設計されています。
4.1 Message Types
4.1 メッセージタイプ
See [H4.1]
見てください。[H4.1]
4.2 Message Headers
4.2 メッセージヘッダー
See [H4.2]
見てください。[H4.2]
4.3 Message Body
4.3 メッセージ本体
See [H4.3]
見てください。[H4.3]
Schulzrinne, et. al. Standards Track [Page 19] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[19ページ]RFC2326リアルタイム
4.4 Message Length
4.4 メッセージ長
When a message body is included with a message, the length of that body is determined by one of the following (in order of precedence):
メッセージ本体がメッセージで含まれているとき、そのボディーの長さは以下(先任順に)の1つで測定されます:
1. Any response message which MUST NOT include a message body
(such as the 1xx, 204, and 304 responses) is always terminated
by the first empty line after the header fields, regardless of
the entity-header fields present in the message. (Note: An
empty line consists of only CRLF.)
1. メッセージ本体(1xxや、204や、304の応答などの)を含んではいけないどんな応答メッセージもいつもヘッダーフィールドの後の最初の空の系列によって終えられます、メッセージの現在の実体ヘッダーフィールドにかかわらず。 (注意: 空の系列はCRLFだけから成ります。)
2. If a Content-Length header field (section 12.14) is present,
its value in bytes represents the length of the message-body.
If this header field is not present, a value of zero is
assumed.
2. Content-長さのヘッダーフィールド(セクション12.14)が存在しているなら、バイトで表現される値はメッセージ本体の長さを表します。 このヘッダーフィールドが存在していないなら、ゼロの値は想定されます。
3. By the server closing the connection. (Closing the connection
cannot be used to indicate the end of a request body, since
that would leave no possibility for the server to send back a
response.)
3. 接続を終えるサーバで。 (要求本体の先を示すのに接続を終えるのを使用できません、それはサーバが応答を返送する可能性を全く残さないでしょう、したがって。)
Note that RTSP does not (at present) support the HTTP/1.1 "chunked" transfer coding(see [H3.6]) and requires the presence of the Content-Length header field.
RTSPが(現在のところ)HTTP/1.1をサポートしないというメモは、転送コード化([H3.6]を見る)を「chunkedし」て、Content-長さのヘッダーフィールドを存在に要求します。
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. Even though Content-Length must be present if there is
any entity body, the rules ensure reasonable behavior even if the
length is not given explicitly.
記述が返したプレゼンテーションの適度の長さを考えて、サーバはいつも長さを測定できるべきです、それがダイナミックに生成されても、chunked転送コード化を不要にして。 何か実体本体があれば、Content-長さは存在していなければなりませんが、長さが明らかに与えられないでも、規則は合理的な振舞いを確実にします。
5 General Header Fields
5 一般ヘッダーフィールド
See [H4.5], except that Pragma, Transfer-Encoding and Upgrade headers are not defined:
Pragma、Transfer-コード化、およびUpgradeヘッダーが定義されないのを除いて、[H4.5]は見ます:
general-header = Cache-Control ; Section 12.8
| Connection ; Section 12.10
| Date ; Section 12.18
| Via ; Section 12.43
一般的なヘッダーはキャッシュコントロールと等しいです。 セクション12.8| 接続。 セクション12.10| デートしてください。 セクション12.18| を通して。 セクション12.43
6 Request
6要求
A request message from a client to a server or vice versa includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use.
要求は、クライアントからサーバまで通信するか、またはそのメッセージの最初の系列の中に逆もまた同様にリソースに適用されるべきメソッド、リソースに関する識別子、および使用中のプロトコルバージョンを含んでいます。
Schulzrinne, et. al. Standards Track [Page 20] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[20ページ]RFC2326リアルタイム
Request = Request-Line ; Section 6.1
*( general-header ; Section 5
| request-header ; Section 6.2
| entity-header ) ; Section 8.1
CRLF
[ message-body ] ; Section 4.3
=要求線を要求してください。 セクション6.1*(一般的なヘッダー; セクション5| 要求ヘッダー; セクション6.2| 実体ヘッダー)。 セクション8.1 CRLF[メッセージ本体]。 セクション4.3
6.1 Request Line
6.1 要求線
Request-Line = Method SP Request-URI SP RTSP-Version CRLF
メソッドSP要求URI SP RTSP-バージョン要求線=CRLF
Method = "DESCRIBE" ; Section 10.2
| "ANNOUNCE" ; Section 10.3
| "GET_PARAMETER" ; Section 10.8
| "OPTIONS" ; Section 10.1
| "PAUSE" ; Section 10.6
| "PLAY" ; Section 10.5
| "RECORD" ; Section 10.11
| "REDIRECT" ; Section 10.10
| "SETUP" ; Section 10.4
| "SET_PARAMETER" ; Section 10.9
| "TEARDOWN" ; Section 10.7
| extension-method
メソッドは「説明」と等しいです。 セクション10.2| 「発表してください」。 セクション10.3| 「_パラメタを得てください」。 セクション10.8| 「オプション」。 セクション10.1| 「止まってください」。 セクション10.6| 「プレーしてください」。 セクション10.5| 「記録してください」。 セクション10.11| 「向け直します」。 セクション10.10| 「セットアップしてください」。 セクション10.4| 「セット_パラメタ」。 セクション10.9| 「分解」。 セクション10.7| 拡大メソッド
extension-method = token
拡大メソッドはトークンと等しいです。
Request-URI = "*" | absolute_URI
要求URI=「*」| 絶対_URI
RTSP-Version = "RTSP" "/" 1*DIGIT "." 1*DIGIT
「RTSP-バージョン="RTSP"」/、」 1*ケタ、」、」 1*ケタ
6.2 Request Header Fields
6.2 要求ヘッダーフィールド
request-header = Accept ; Section 12.1
| Accept-Encoding ; Section 12.2
| Accept-Language ; Section 12.3
| Authorization ; Section 12.5
| From ; Section 12.20
| If-Modified-Since ; Section 12.23
| Range ; Section 12.29
| Referer ; Section 12.30
| User-Agent ; Section 12.41
要求ヘッダー=は受け入れます。 セクション12.1| コード化を受け入れます。 セクション12.2| 言語を受け入れます。 セクション12.3| 承認。 セクション12.5| 。 セクション12.20| 以来変更されるなら。 セクション12.23| 及んでください。 セクション12.29| Referer。 セクション12.30| ユーザエージェント。 セクション12.41
Note that in contrast to HTTP/1.1 [2], RTSP requests always contain the absolute URL (that is, including the scheme, host and port) rather than just the absolute path.
HTTP/1.1[2]と対照してRTSP要求がいつもまさしく絶対パスよりむしろ絶対URL(すなわち、体系、ホスト、およびポートを含んでいる)を含むことに注意してください。
Schulzrinne, et. al. Standards Track [Page 21] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[21ページ]RFC2326リアルタイム
HTTP/1.1 requires servers to understand the absolute URL, 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は絶対URLを理解するためにサーバを必要としますが、クライアントはHost要求ヘッダーを使用するべきです。 これが純粋にHTTP/1.0のサーバとの後方の互換性、RTSPに適用されない考慮に必要です。
The asterisk "*" in the Request-URI means that the request does not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily apply to a resource. One example would be:
要求URIにおけるアスタリスク「*」は、要求が特定のリソースに適用するのではなく、サーバ自体に適用されることを意味して、使用されるメソッドが必ずリソースに適用されるというわけではないときだけ、許容されています。 1つの例は以下の通りでしょう。
OPTIONS * RTSP/1.0
オプション*RTSP/1.0
7 Response
7 応答
[H6] applies except that HTTP-Version is replaced by RTSP-Version. Also, RTSP defines additional status codes and does not define some HTTP codes. The valid response codes and the methods they can be used with are defined in Table 1.
HTTPバージョンをRTSP-バージョンに取り替えるのを除いて、[H6]は適用します。 また、RTSPは追加ステータスコードを定義して、いくつかのHTTPコードは定義しません。 有効回答コードとそれらを使用できるメソッドはTable1で定義されます。
After receiving and interpreting a request message, the recipient responds with an RTSP response message.
要求メッセージを受け取って、解釈した後に、受取人はRTSP応答メッセージで応じます。
Response = Status-Line ; Section 7.1
*( general-header ; Section 5
| response-header ; Section 7.1.2
| entity-header ) ; Section 8.1
CRLF
[ message-body ] ; Section 4.3
応答は状況表示行と等しいです。 セクション7.1*(一般的なヘッダー; セクション5| 応答ヘッダ; セクション7.1.2| 実体ヘッダー)。 セクション8.1 CRLF[メッセージ本体]。 セクション4.3
7.1 Status-Line
7.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.
Responseメッセージの最初の系列はStatus-線です、数値ステータスコード、およびステータスコードに関連している原文の句があとに続いたプロトコルバージョンから成って、各要素がSPキャラクタによって切り離されている状態で。 最終的なCRLF系列以外に、どんなCRもLFも許容されていません。
Status-Line = RTSP-Version SP Status-Code SP Reason-Phrase CRLF
状況表示行=RTSP-バージョンSPステータスコードSP理由句のCRLF
7.1.1 Status Code and Reason Phrase
7.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 11. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason- Phrase.
Status-コード要素は要望を理解して、応じる試みの3ケタの整数結果コードです。 これらのコードはセクション11で完全に定義されます。 Reason-句がStatus-コードの短い原文の記述を与えることを意図します。 Status-コードは使用のためにオートマトンで意図します、そして、Reason-句は人間のユーザのために意図します。 クライアントは、Reason句を調べるか、または表示する必要はありません。
Schulzrinne, et. al. Standards Track [Page 22] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[22ページ]RFC2326リアルタイム
The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit:
Status-コードの最初のケタは応答のクラスを定義します。 下2ケタには、どんな分類の役割もありません。 最初のケタのための5つの値があります:
* 1xx: Informational - Request received, continuing process
* 2xx: Success - The action was successfully received, understood,
and accepted
* 3xx: Redirection - Further action must be taken in order to
complete the request
* 4xx: Client Error - The request contains bad syntax or cannot be
fulfilled
* 5xx: Server Error - The server failed to fulfill an apparently
valid request
* 1xx: 情報、--受け取られていていて、継続するプロセス*2xxを要求してください: 成功--*3xxは、動作が首尾よく受けられたと理解して、受け入れました: リダイレクション--要求*4xxを完成するためにさらなる行動を取らなければなりません: クライアントError--要求は、誤りのある構文を含んでいるか、実現している*5xxであるはずがありません: サーバError--サーバは明らかに有効な要求を実現させませんでした。
The individual values of the numeric status codes defined for RTSP/1.0, and an example set of corresponding Reason-Phrase's, are presented below. The reason phrases listed here are only recommended - they may be replaced by local equivalents without affecting the protocol. Note that RTSP adopts most HTTP/1.1 [2] status codes and adds RTSP-specific status codes starting at x50 to avoid conflicts with newly defined HTTP status codes.
以下でRTSP/1.0のために定義された数値ステータスコードの個人価値、および対応する句のReasonものの例のセットを寄贈します。 ここにリストアップされた句がお勧めであるだけである理由--プロトコルに影響しないで、それらを地方の同等物に取り替えるかもしれません。 x50で新たに定義されたHTTPステータスコードで摩擦を避け始めて、RTSPがほとんどのHTTP/1.1の[2]ステータスコードを採用して、RTSP特有のステータスコードを加えることに注意してください。
Schulzrinne, et. al. Standards Track [Page 23] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[23ページ]RFC2326リアルタイム
Status-Code = "100" ; Continue
| "200" ; OK
| "201" ; Created
| "250" ; Low on Storage Space
| "300" ; Multiple Choices
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "303" ; See Other
| "304" ; Not Modified
| "305" ; Use Proxy
| "400" ; Bad Request
| "401" ; Unauthorized
| "402" ; Payment Required
| "403" ; Forbidden
| "404" ; Not Found
| "405" ; Method Not Allowed
| "406" ; Not Acceptable
| "407" ; Proxy Authentication Required
| "408" ; Request Time-out
| "410" ; Gone
| "411" ; Length Required
| "412" ; Precondition Failed
| "413" ; Request Entity Too Large
| "414" ; Request-URI Too Large
| "415" ; Unsupported Media Type
| "451" ; Parameter Not Understood
| "452" ; Conference Not Found
| "453" ; Not Enough Bandwidth
| "454" ; Session Not Found
| "455" ; Method Not Valid in This State
| "456" ; Header Field Not Valid for Resource
| "457" ; Invalid Range
| "458" ; Parameter Is Read-Only
| "459" ; Aggregate operation not allowed
| "460" ; Only aggregate operation allowed
| "461" ; Unsupported transport
| "462" ; Destination unreachable
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| "504" ; Gateway Time-out
| "505" ; RTSP Version not supported
| "551" ; Option not supported
| extension-code
ステータスコード=「100」。 続いてください。| "200" ; OK| "201" ; 作成されます。| "250" ; 集積スペースでは、低いです。| "300" ; 選択式| "301" ; 永久に、移行します。| "302" ; 一時、移行します。| "303" ; 別に見てください。| "304" ; 変更されません。| "305" ; プロキシを使用してください。| "400" ; 悪い要求| "401" ; 権限のない| "402" ; 支払いが必要です。| "403" ; 禁じられます。| "404" ; 見つけられません。| "405" ; 許容されなかったメソッド| "406" ; 許容できない| "407" ; プロキシ認証が必要です。| "408" ; タイムアウトを要求してください。| "410" ; 行きます。| "411" ; 長さが必要です。| "412" ; 前提条件は失敗しました。| "413" ; 大き過ぎる状態で実体を要求してください。| "414" ; 要求URIも多| "415" ; サポートされないメディアタイプ| "451" ; パラメタは分かりませんでした。| "452" ; 見つけられなかったコンファレンス| "453" ; 十分な帯域幅でない| "454" ; 見つけられなかったセッション| "455" ; この状態で有効でないメソッド| "456" ; リソースには、有効でないヘッダーフィールド| "457" ; 無効の範囲| "458" ; パラメタは書き込み禁止です。| "459" ; 許されなかった集合操作| "460" ; 許された集合操作だけ| "461" ; サポートされない輸送| "462" ; 目的地手が届きません。| "500" ; 内部サーバーエラー| "501" ; 実装されません。| "502" ; 悪いゲートウェイ| "503" ; 入手できないサービス| "504" ; ゲートウェイタイムアウト| "505" ; バージョンがサポートしなかったRTSP| "551" ; サポートされなかったオプション| 拡張コード
Schulzrinne, et. al. Standards Track [Page 24] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[24ページ]RFC2326リアルタイム
extension-code = 3DIGIT
拡張コード=3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
CR、LF>を除いた理由句の=*<TEXT
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 the exception that an unrecognized response 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 entity returned with the response, since that entity is likely to include human- readable information which will explain the unusual status.
RTSPステータスコードは広げることができます。 そのような理解は明らかに望ましいのですが、RTSPアプリケーションは、すべての登録されたステータスコードの意味を理解するのに必要ではありません。 しかしながら、アプリケーションは、最初のケタによって示されるようにどんなステータスコードのクラスも理解して、認識されていない応答が例外があるそのクラスのステータスコードであるに違いありませんが、x00に同等であるとしてキャッシュされていた状態でどんな認識されていない応答も扱わなければなりません。 例えば、431の認識されていないステータスコードがクライアントによって受け取られるなら、それは、まるで400ステータスコードを受け取ったかのように要求には不具合があったと安全に仮定して、応答を扱うことができます。 そのような場合、ユーザエージェントSHOULDは応答と共に返された実体をユーザに提示します、その実体が珍しい状態がわかる人間の読み込み可能な情報を含んでいそうであるので。
Code reason
コード理由
100 Continue all
100はすべてを続けています。
200 OK all 201 Created RECORD 250 Low on Storage Space RECORD
200はStorage Space RECORDの上のすべての201Created RECORD250Lowを承認します。
300 Multiple Choices all 301 Moved Permanently all 302 Moved Temporarily all 303 See Other all 305 Use Proxy all
300倍数Choices、すべての301Moved Permanently、すべての302Moved Temporarily、すべての303See Other、すべての305Use Proxy、すべて
Schulzrinne, et. al. Standards Track [Page 25] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[25ページ]RFC2326リアルタイム
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 411 Length Required all 412 Precondition Failed DESCRIBE, SETUP 413 Request Entity Too Large all 414 Request-URI Too Long all 415 Unsupported Media Type all 451 Invalid parameter SETUP 452 Illegal Conference Identifier SETUP 453 Not Enough Bandwidth SETUP 454 Session Not Found all 455 Method Not Valid In This State all 456 Header Field Not Valid all 457 Invalid Range PLAY 458 Parameter Is Read-Only SET_PARAMETER 459 Aggregate Operation Not Allowed all 460 Only Aggregate Operation Allowed all 461 Unsupported Transport all 462 Destination Unreachable all
400の悪いRequest、すべての401Unauthorized、すべての402Payment Required、すべての403Forbidden、すべての404Not Found、すべての405Method Not Allowed、すべての406Not Acceptable、すべての407Proxy Authentication Required、すべての408Request Timeout、すべての410Gone、すべての411Length Required、すべての412Precondition Failed DESCRIBE; SETUP413Request Entity Too Large、すべての414Request-URI Too Long、すべての415UnsupportedメディアType、すべての451InvalidパラメタSETUP452IllegalコンファレンスIdentifier SETUP453Not Enough Bandwidth SETUP454Session Not Found、すべての455Method Not Valid In This州、すべての456、Header Field Not Validすべての457Invalid Range PLAY458Parameter Is ReadだけSET_PARAMETER459Aggregate Operation Not Allowed、すべての460Only Aggregate Operation Allowed、すべての461Unsupported Transport、すべての462Destination Unreachable、すべて
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 support all
500の内部のServer Error、すべての501Not Implemented、すべての502Badゲートウェイ、すべての503Service Unavailable、すべての504ゲートウェイTimeout、すべての551Optionがすべてをサポートしないすべての505RTSPバージョンNot Supported
Table 1: Status codes and their usage with RTSP methods
テーブル1: RTSPメソッドがあるステータスコードとそれらの用法
7.1.2 Response Header Fields
7.1.2 応答ヘッダーフィールド
The response-header fields allow the request recipient to pass additional information about the response which cannot be placed in the Status-Line. These header fields give information about the server and about further access to the resource identified by the Request-URI.
応答ヘッダ分野で、要求受取人はStatus-線に置くことができない応答に関する追加情報を通過できます。 これらのヘッダーフィールドはサーバの周りと、そして、Request-URIによって特定されたリソースへのさらなるアクセスの周りに関して知らせます。
Schulzrinne, et. al. Standards Track [Page 26] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[26ページ]RFC2326リアルタイム
response-header = Location ; Section 12.25
| Proxy-Authenticate ; Section 12.26
| Public ; Section 12.28
| Retry-After ; Section 12.31
| Server ; Section 12.36
| Vary ; Section 12.42
| WWW-Authenticate ; Section 12.44
応答ヘッダは位置と等しいです。 セクション12.25| プロキシで認証します。 セクション12.26| 公衆。 セクション12.28| -後に再試行してください。 セクション12.31| サーバ。 セクション12.36| 異なってください。 セクション12.42| WWW認証します。 セクション12.44
Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields MAY be given the semantics of response- header fields if all parties in the communication recognize them to be response-header fields. Unrecognized header fields are treated as entity-header fields.
単にプロトコルバージョンにおける変化と組み合わせて応答ヘッダフィールド名を確かに広げることができます。 しかしながら、コミュニケーションにおけるすべてのパーティーが、彼らが応答ヘッダ分野であると認めるなら、応答ヘッダーフィールドの意味論を新しいか実験しているヘッダーフィールドに与えるかもしれません。 認識されていないヘッダーフィールドは実体ヘッダーフィールドとして扱われます。
8 Entity
8実体
Request and Response messages MAY transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header fields and an entity-body, although some responses will only include the entity-headers.
別の方法で要求メソッドか応答ステータスコードによって制限されないなら、要求とResponseメッセージは実体を移すかもしれません。 いくつかの応答が実体ヘッダーを含むだけでしょうが、実体は実体ヘッダーフィールドと実体本体から成ります。
In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives the entity.
このセクションで、送付者と受取人の両方がクライアントかサーバのどちらかについて言及します、だれが発信するか、そして、だれが実体を受けるかによって。
8.1 Entity Header Fields
8.1 実体ヘッダーフィールド
Entity-header fields define optional metainformation about the entity-body or, if no body is present, about the resource identified by the request.
実体ヘッダーフィールドが実体本体に関して任意のmetainformationを定義するか、またはボディーはいいえなら存在しています、要求で特定されたリソースに関して。
entity-header = Allow ; Section 12.4
| Content-Base ; Section 12.11
| Content-Encoding ; Section 12.12
| Content-Language ; Section 12.13
| Content-Length ; Section 12.14
| Content-Location ; Section 12.15
| Content-Type ; Section 12.16
| Expires ; Section 12.19
| Last-Modified ; Section 12.24
| extension-header
extension-header = message-header
=が許容する実体ヘッダー。 セクション12.4| 満足している基地。 セクション12.11| 内容をコード化しています。 セクション12.12| 満足している言語。 セクション12.13| コンテンツの長さ。 セクション12.14| 満足している位置。 セクション12.15| コンテントタイプ。 セクション12.16| 期限が切れます。 セクション12.19| 最終更新日。 セクション12.24| 拡張ヘッダー拡張ヘッダーはメッセージヘッダーと等しいです。
The extension-header mechanism allows additional entity-header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields SHOULD be ignored by the recipient and forwarded by proxies.
拡張ヘッダーメカニズムは、追加実体ヘッダーフィールドがプロトコルを変えないで定義されるのを許容しますが、受取人が認識可能であるとこれらの分野を思うことができません。 認識されていないヘッダーは受取人によって無視されて、プロキシによって進められたSHOULDをさばきます。
Schulzrinne, et. al. Standards Track [Page 27] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[27ページ]RFC2326リアルタイム
8.2 Entity Body
8.2 実体本体
See [H7.2]
見てください。[H7.2]
9 Connections
9 コネクションズ
RTSP requests can be transmitted in several different ways:
いくつかの異なった方法でRTSP要求を伝えることができます:
* persistent transport connections used for several
request-response transactions;
* one connection per request/response transaction;
* connectionless mode.
* いくつかの要求応答トランザクションに使用される永続的な輸送の接続。 * 要求/応答トランザクションあたり1つの接続。 * コネクションレスなモード。
The type of transport connection is defined by the RTSP URI (Section 3.2). For the scheme "rtsp", a persistent connection is assumed, while the scheme "rtspu" calls for RTSP requests to be sent without setting up a connection.
輸送接続のタイプはRTSP URI(セクション3.2)によって定義されます。 体系"rtsp"においてパーシステントコネクションは想定されます、体系"rtspu"は接続をセットアップしないで送られるというRTSP要求を求めますが。
Unlike HTTP, RTSP allows the media server to send requests to the media client. However, this is only supported for persistent connections, as the media server otherwise has no reliable way of reaching the client. Also, this is the only way that requests from media server to client are likely to traverse firewalls.
HTTPと異なって、RTSPはメディアサーバにメディアクライアントに要求を送らせます。 しかしながら、これはパーシステントコネクションのためにサポートされるだけです、そうでなければ、メディアサーバにクライアントに届くどんな信頼できる方法もないとき。 また、これはメディアサーバからクライアントまでの要求がファイアウォールを横断しそうである唯一の方法です。
9.1 Pipelining
9.1 パイプライン処理
A client that supports persistent connections or connectionless mode MAY "pipeline" its requests (i.e., send multiple requests without waiting for each response). A server MUST send its responses to those requests in the same order that the requests were received.
要求(すなわち、各応答を待たないで、複数の要求を送る)をパーシステントコネクションかコネクションレスなモード5月の「パイプライン」にサポートするクライアント。 サーバは要求を受け取ったという同次におけるそれらの要求への応答を送らなければなりません。
9.2 Reliability and Acknowledgements
9.2 信頼性と承認
Requests are acknowledged by the receiver unless they are sent to a multicast group. If there is no acknowledgement, the sender may resend the same message after a timeout of one round-trip time (RTT). The round-trip time is estimated as in TCP (RFC 1123) [18], with an initial round-trip value of 500 ms. An implementation MAY cache the last RTT measurement as the initial value for future connections.
それらがマルチキャストグループに送られない場合、要求は受信機によって承諾されます。 承認が全くなければ、送付者は往復の1回(RTT)のタイムアウトの後に同じメッセージを再送するかもしれません。 500原稿An実装の初期の往復の値がある[18]が今後の接続のための初期の値としてTCP(RFC1123)で最後のRTT測定をキャッシュするとき、往復の時間は見積もられています。
If a reliable transport protocol is used to carry RTSP, requests MUST NOT be retransmitted; the RTSP application MUST instead rely on the underlying transport to provide reliability.
信頼できるトランスポート・プロトコルがRTSPを運ぶのに使用されるなら、要求を再送してはいけません。 RTSPアプリケーションは、信頼性を提供するために代わりに基本的な輸送に依存しなければなりません。
If both the underlying reliable transport such as TCP and the RTSP
application retransmit requests, it is possible that each packet
loss results in two retransmissions. The receiver cannot typically
take advantage of the application-layer retransmission since the
TCPなどの基本的な信頼できる輸送とRTSPアプリケーションの両方が要求を再送するなら、各パケット損失が2「再-トランスミッション」をもたらすのは、可能です。 受信機は以来に「再-トランスミッション」応用層を通常利用できません。
Schulzrinne, et. al. Standards Track [Page 28] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[28ページ]RFC2326リアルタイム
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.
最初の試みが受信機に達する前に輸送スタックは「再-トランスミッション」応用層を提供しないでしょう。パケット損失が混雑で引き起こされると、異なった層の複数の「再-トランスミッション」が混雑を悪化させるでしょう。
If RTSP is used over a small-RTT LAN, standard procedures for
optimizing initial TCP round trip estimates, such as those used in
T/TCP (RFC 1644) [22], can be beneficial.
T/TCP(RFC1644)[22]で使用されるものなどの初期のTCP周遊旅行見積りを最適化するのが有益である場合があるのでRTSPが小さいRTT LAN、標準手続きの上で使用されるなら。
The Timestamp header (Section 12.38) is used to avoid the retransmission ambiguity problem [23, p. 301] and obviates the need for Karn's algorithm.
Timestampヘッダー(セクション12.38)は、「再-トランスミッション」あいまいさ問題を避けるのに使用されます。[23 p。 301] そして、Karnのアルゴリズムの必要性を取り除きます。
Each request carries a sequence number in the CSeq header (Section 12.17), which is incremented by one for each distinct request transmitted. If a request is repeated because of lack of acknowledgement, the request MUST carry the original sequence number (i.e., the sequence number is not incremented).
それぞれの異なった要求が伝わったので、各要求はCSeqヘッダー(セクション12.17)で一連番号を運びます。(ヘッダーは1つ増加されます)。 要求が承認の不足のために繰り返されるなら、要求は元の一連番号を運ばなければなりません(すなわち、一連番号は増加されていません)。
Systems implementing RTSP MUST support carrying RTSP over TCP and MAY support UDP. The default port for the RTSP server is 554 for both UDP and TCP.
RTSP MUSTがTCPと5月の間にRTSPを運ぶサポートであると実装するシステムがUDPをサポートします。 RTSPサーバのためのデフォルトポートはUDPとTCPの両方のための554です。
A number of RTSP packets destined for the same control end point may be packed into a single lower-layer PDU or encapsulated into a TCP stream. RTSP data MAY be interleaved with RTP and RTCP packets. Unlike HTTP, an RTSP message MUST contain a Content-Length header whenever that message contains a payload. Otherwise, an RTSP packet is terminated with an empty line immediately following the last message header.
同じコントロールエンドポイントのために運命づけられた多くのRTSPパケットが、独身の下層PDUに詰め込まれるか、またはTCPストリームにカプセルに入れられるかもしれません。 RTSPデータはRTPとRTCPパケットではさみ込まれるかもしれません。 HTTPと異なって、そのメッセージがペイロードを含んでいるときはいつも、RTSPメッセージはContent-長さのヘッダーを含まなければなりません。 さもなければ、空の系列がすぐに最後のメッセージヘッダーに続いていて、RTSPパケットは終えられます。
10 Method Definitions
10 メソッド定義
The method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive. New methods may be defined in the future. Method names may not start with a $ character (decimal 24) and must be a token. Methods are summarized in Table 2.
メソッドトークンはRequest-URIによって特定されたリソースに実行されるべきメソッドを示します。 メソッドは大文字と小文字を区別しています。 新しいメソッドは将来、定義されるかもしれません。 メソッド名は、$キャラクタ(10進24)から始めないかもしれなくて、トークンであるに違いありません。 メソッドはTable2にまとめられます。
Schulzrinne, et. al. Standards Track [Page 29] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[29ページ]RFC2326リアルタイム
method direction object requirement
DESCRIBE C->S P,S recommended
ANNOUNCE C->S, S->C P,S optional
GET_PARAMETER C->S, S->C P,S optional
OPTIONS C->S, S->C P,S required
(S->C: optional)
PAUSE C->S P,S recommended
PLAY C->S P,S required
RECORD C->S P,S optional
REDIRECT S->C P,S optional
SETUP C->S S required
SET_PARAMETER C->S, S->C P,S optional
TEARDOWN C->S P,S required
method direction object requirement DESCRIBE C->S P,S recommended ANNOUNCE C->S, S->C P,S optional GET_PARAMETER C->S, S->C P,S optional OPTIONS C->S, S->C P,S required (S->C: optional) PAUSE C->S P,S recommended PLAY C->S P,S required RECORD C->S P,S optional REDIRECT S->C P,S optional SETUP C->S S required SET_PARAMETER C->S, S->C P,S optional TEARDOWN C->S P,S required
Table 2: Overview of RTSP methods, their direction, and what
objects (P: presentation, S: stream) they operate on
テーブル2: RTSPメソッド、それらの方向の概要とそれらはどんなオブジェクト(P: プレゼンテーション、S: ストリーム)を作動させますか。
Notes on Table 2: PAUSE is recommended, but not required in that a fully functional server can be built that does not support this method, for example, for live feeds. If a server does not support a particular method, it MUST return "501 Not Implemented" and a client SHOULD not try this method again for this server.
テーブル2での注意: PAUSEは、例えばライブ給送のためにこのメソッドをサポートしない完全に機能的なサーバを組立てることができるので、推薦されますが、必要ではありません。 サーバが特定のメソッドをサポートしないなら、それはこのサーバのために再び「実装されなかった501」とSHOULDが裁かないクライアントにこのメソッドを返さなければなりません。
10.1 OPTIONS
10.1 オプション
The behavior is equivalent to that described in [H9.2]. An OPTIONS request may be issued at any time, e.g., if the client is about to try a nonstandard request. It does not influence server state.
振舞いは[H9.2]で説明されたそれに同等です。 例えば、クライアントが標準的でない要求を試みようとしているなら、OPTIONS要求はいつでも、出されるかもしれません。 それはサーバ状態に影響を及ぼしません。
Example:
例:
C->S: OPTIONS * RTSP/1.0
CSeq: 1
Require: implicit-play
Proxy-Require: gzipped-messages
C>S: オプション*RTSP/1.0CSeq: 1 必要です: 内在しているプレーは以下をProxy必要とします。 gzippedメッセージ
S->C: RTSP/1.0 200 OK
CSeq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE
S>C: RTSP/1.0 200はCSeqを承認します: 1人の公衆: 説明、セットアップ、分解をプレーして、止まってください。
Note that these are necessarily fictional features (one would hope that we would not purposefully overlook a truly useful feature just so that we could have a strong example in this section).
これらが必ず作り事の特徴であることに注意してください(人は、私たちがただこのセクションに強い例を持つことができるように故意に本当に役に立つ特徴を見落とさないことを望んでいるでしょう)。
Schulzrinne, et. al. Standards Track [Page 30] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[30ページ]RFC2326リアルタイム
10.2 DESCRIBE
10.2は説明します。
The DESCRIBE method retrieves the description of a presentation or media object identified by the request URL from a server. It may use the Accept header to specify the description formats that the client understands. The server responds with a description of the requested resource. The DESCRIBE reply-response pair constitutes the media initialization phase of RTSP.
DESCRIBEメソッドは要求URLによってサーバから特定されたプレゼンテーションかメディアオブジェクトの記述を検索します。それは、クライアントが理解している記述形式を指定するのにAcceptヘッダーを使用するかもしれません。 サーバは要求されたリソースの記述で反応します。 DESCRIBE回答応答組はRTSPのメディア初期設定段階を構成します。
Example:
例:
C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Accept: application/sdp, application/rtsl, application/mheg
C>S: DESCRIBE rtsp://server.example.com/シューシューという音/foo RTSP/1.0CSeq: 312 受け入れます: アプリケーション/sdp、アプリケーション/rtsl、アプリケーション/mheg
S->C: RTSP/1.0 200 OK
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Content-Type: application/sdp
Content-Length: 376
S>C: RTSP/1.0 200はCSeqを承認します: 312 日付: 1997年1月23日のグリニッジ標準時15時35分6秒のコンテントタイプ: sdp Contentアプリケーション/長さ: 376
v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
m=whiteboard 32416 UDP WB
a=orient:portrait
2873397496 2873404696a=recvonly mjh@isi.edu (マークハンドレー)c=IN IP4 224.2.17.12/127セッション記述プロトコルuのv=0 o=mhandley2890844526 2890842807IN IP4 126.16.64.4 s=SDP Seminar i=A Seminar= http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps e=t=mが31mの3456年の0mのオーディオRTP/AVP=ビデオ2232RTP/AVP=ホワイトボードと等しい、32416UDP WB a、= : 肖像を適応させてください。
The DESCRIBE response MUST contain all media initialization information for the resource(s) that it describes. If a media client obtains a presentation description from a source other than DESCRIBE and that description contains a complete set of media initialization parameters, the client SHOULD use those parameters and not then request a description for the same media via RTSP.
DESCRIBE応答はそれが説明するリソースのためのすべてのメディア初期化情報を含まなければなりません。 メディアクライアントがDESCRIBE以外のソースからプレゼンテーション記述を得て、その記述が完全なセットのメディア初期化パラメタを含んでいて、クライアントSHOULD使用がそれらのパラメタであり、次に、何か要求もRTSPを通した同じメディアのための記述でないなら。
Additionally, servers SHOULD NOT use the DESCRIBE response as a means of media indirection.
さらに、サーバSHOULD NOTはメディア間接指定の手段としてDESCRIBE応答を使用します。
Clear ground rules need to be established so that clients have an
unambiguous means of knowing when to request media initialization
information via DESCRIBE, and when not to. By forcing a DESCRIBE
明確な基本規則が、設立される必要があるので、クライアントには、そうしないよういつDESCRIBE、およびいつを通したメディア初期化情報に要求するかを知る明白な手段があります。 DESCRIBEを強制することによって
Schulzrinne, et. al. Standards Track [Page 31] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[31ページ]RFC2326リアルタイム
response to contain all media initialization for the set of streams
that it describes, and discouraging use of DESCRIBE for media
indirection, we avoid looping problems that might result from other
approaches.
それが説明するストリームのセット、およびDESCRIBEのメディア間接指定のがっかりしている使用のためのすべてのメディア初期化を含む応答、私たちは他のアプローチから生じるかもしれない問題を輪にするのを避けます。
Media initialization is a requirement for any RTSP-based system,
but the RTSP specification does not dictate that this must be done
via the DESCRIBE method. There are three ways that an RTSP client
may receive initialization information:
メディア初期化はどんなRTSPベースのシステムのための要件ですがも、RTSP仕様は、DESCRIBEメソッドでこれをしなければならないと決めません。 RTSPクライアントがそうする3つの方法があります。初期化情報を受け取ってください:
* via RTSP's DESCRIBE method;
* via some other protocol (HTTP, email attachment, etc.);
* via the command line or standard input (thus working as a browser
helper application launched with an SDP file or other media
initialization format).
* RTSPのDESCRIBEメソッドで。 * ある他のプロトコル(HTTP、メール付属など)で。 * コマンドラインか規格で、(その結果、ブラウザ支援アプリケーションがSDPファイルで始められながら働いているか、他のメディア初期化形式)を入力してください。
In the interest of practical interoperability, it is highly
recommended that minimal servers support the DESCRIBE method, and
highly recommended that minimal clients support the ability to act
as a "helper application" that accepts a media initialization file
from standard input, command line, and/or other means that are
appropriate to the operating environment of the client.
実用的な相互運用性のために、最小量のサーバがDESCRIBEメソッドをサポートするのが、非常にお勧めであり、そんなに最小量で強く推薦されて、クライアントは適切な標準の入力、コマンドライン、そして/または、他の手段からクライアントの操作環境にメディア初期化ファイルを受け入れる「支援アプリケーション」として機能する能力をサポートします。
10.3 ANNOUNCE
10.3は発表します。
The ANNOUNCE method serves two purposes:
ANNOUNCEメソッドは2つの目的に役立ちます:
When sent from client to server, ANNOUNCE posts the description of a presentation or media object identified by the request URL to a server. When sent from server to client, ANNOUNCE updates the session description in real-time.
いつがクライアントからサーバ(プレゼンテーションかメディアオブジェクトの記述が要求URLでサーバに特定したANNOUNCEポスト)まで発信したか。サーバからクライアントに送ると、ANNOUNCEはリアルタイムでにおけるセッション記述をアップデートします。
If a new media stream is added to a presentation (e.g., during a live presentation), the whole presentation description should be sent again, rather than just the additional components, so that components can be deleted.
プレゼンテーション(例えば、ライブプレゼンテーションの間の)にニューメディアストリームを加えるなら、再び、まさしく追加コンポーネントよりむしろ全体のプレゼンテーション記述を送るべきです、コンポーネントを削除できるように。
Example:
例:
C->S: ANNOUNCE rtsp://server.example.com/fizzle/foo RTSP/1.0
CSeq: 312
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Content-Type: application/sdp
Content-Length: 332
C>S: ANNOUNCE rtsp://server.example.com/シューシューという音/foo RTSP/1.0CSeq: 312 日付: 1997年1月23日のグリニッジ標準時15時35分6秒のセッション: 47112344コンテントタイプ: sdp Contentアプリケーション/長さ: 332
v=0
o=mhandley 2890844526 2890845468 IN IP4 126.16.64.4
v=0 o=mhandley2890844526 2890845468IN IP4 126.16.64、.4
Schulzrinne, et. al. Standards Track [Page 32] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[32ページ]RFC2326リアルタイム
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 3456 RTP/AVP 0
m=video 2232 RTP/AVP 31
2873397496 2873404696a=recvonly mjh@isi.edu (マークハンドレー)c=IN IP4 224.2.17.12/127セッション記述プロトコルuのs=SDP Seminar i=A Seminar= http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps e=t=mは3456年の0mのオーディオRTP/AVP=ビデオ2232RTP/AVP31と等しいです。
S->C: RTSP/1.0 200 OK
CSeq: 312
S>C: RTSP/1.0 200はCSeqを承認します: 312
10.4 SETUP
10.4 セットアップ
The SETUP request for a URI specifies the transport mechanism to be used for the streamed media. A client can issue a SETUP request for a stream that is already playing to change transport parameters, which a server MAY allow. If it does not allow this, it MUST respond with error "455 Method Not Valid In This State". For the benefit of any intervening firewalls, a client must indicate the transport parameters even if it has no influence over these parameters, for example, where the server advertises a fixed multicast address.
URIを求めるSETUP要求は、流されたメディアに使用されるために移送機構を指定します。 クライアントは既にサーバが許容するかもしれない変化輸送パラメタに演奏しているストリームを求めるSETUP要求を出すことができます。 これを許容しないなら、それは誤りで「この状態で有効でない455メソッド」を反応させなければなりません。 どんな介入しているファイアウォールの利益のためにも、例えば、サーバが固定マルチキャストアドレスの広告を出すところにこれらのパラメタへの影響を全く持たないでも、クライアントは輸送パラメタを示さなければなりません。
Since SETUP includes all transport initialization information,
firewalls and other intermediate network devices (which need this
information) are spared the more arduous task of parsing the
DESCRIBE response, which has been reserved for media
initialization.
SETUPがすべての輸送初期化情報を含んでいるので、ファイアウォールと他の中間ネットワークデバイス(この情報を必要とする)にメディア初期化のために控えられたDESCRIBE応答を分析するより困難なタスクを割きます。
The Transport header specifies the transport parameters acceptable to the client for data transmission; the response will contain the transport parameters selected by the server.
Transportヘッダーはクライアントにとって、データ伝送のために許容できる輸送パラメタを指定します。 応答はサーバによって選択された輸送パラメタを含むでしょう。
C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Transport: RTP/AVP;unicast;client_port=4588-4589
C>S: SETUP rtsp://example.com/foo/バー/baz.rm RTSP/1.0CSeq: 302 輸送: RTP/AVP; ユニキャスト; クライアント_ポートは4588-4589と等しいです。
S->C: RTSP/1.0 200 OK
CSeq: 302
Date: 23 Jan 1997 15:35:06 GMT
Session: 47112344
Transport: RTP/AVP;unicast;
client_port=4588-4589;server_port=6256-6257
S>C: RTSP/1.0 200はCSeqを承認します: 302 日付: 1997年1月23日のグリニッジ標準時15時35分6秒のセッション: 47112344 輸送: RTP/AVP(ユニキャスト) クライアント_ポートは4588-4589と等しいです; サーバ_ポートは6256-6257と等しいです。
The server generates session identifiers in response to SETUP requests. If a SETUP request to a server includes a session identifier, the server MUST bundle this setup request into the
サーバはSETUP要求に対応してセッション識別子を生成します。 サーバへのSETUP要求がセッション識別子を含んでいるなら、サーバはこのセットアップ要求を添付しなければなりません。
Schulzrinne, et. al. Standards Track [Page 33] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[33ページ]RFC2326リアルタイム
existing session or return error "459 Aggregate Operation Not Allowed" (see Section 11.3.10).
「459の集合操作は許容しなかった」既存のセッションかリターン誤り(セクション11.3.10を見ます)。
10.5 PLAY
10.5 プレー
The PLAY method tells the server to start sending data via the mechanism specified in SETUP. A client MUST NOT issue a PLAY request until any outstanding SETUP requests have been acknowledged as successful.
PLAYメソッドは、SETUPで指定されたメカニズムでデータを送り始めるようにサーバに言います。 どんな傑出しているSETUP要求もうまくいくと承諾されるまで、クライアントはPLAY要求を出してはいけません。
The PLAY request positions the normal play time to the beginning of the range specified and delivers stream data until the end of the range is reached. PLAY requests may be pipelined (queued); a server MUST queue PLAY requests to be executed in order. That is, a PLAY request arriving while a previous PLAY request is still active is delayed until the first has been completed.
PLAYは範囲の端に達するまで、正常なプレー時間から範囲の始まりがストリームデータを指定して、提供するという位置を要求します。 PLAY要求はpipelinedされるかもしれません(列に並ばせられます)。 サーバは整然とした状態で実行されるというPLAY要求を列に並ばせなければなりません。 1番目が完成するまで、すなわち、前のPLAY要求がまだ活発である間に到着するPLAY要求は遅れます。
This allows precise editing.
これは正確な編集を許します。
For example, regardless of how closely spaced the two PLAY requests in the example below arrive, the server will first play seconds 10 through 15, then, immediately following, seconds 20 to 25, and finally seconds 30 through the end.
例えば、どれくらい密接に区切られるかにかかわらず以下の例における2つのPLAY要求が到着して、サーバは最初に、秒10〜15、当時の、そして、すぐに次の秒20〜25、および最終的に終わりまでの秒30をプレーするでしょう。
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 835
Session: 12345678
Range: npt=10-15
C>S: PLAY rtsp://audio.example.com/オーディオRTSP/1.0CSeq: 835セッション: 12345678は及びます: npt=10-15
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 836
Session: 12345678
Range: npt=20-25
C>S: PLAY rtsp://audio.example.com/オーディオRTSP/1.0CSeq: 836セッション: 12345678は及びます: npt=20-25
C->S: PLAY rtsp://audio.example.com/audio RTSP/1.0
CSeq: 837
Session: 12345678
Range: npt=30-
C>S: PLAY rtsp://audio.example.com/オーディオRTSP/1.0CSeq: 837セッション: 12345678は及びます: npt=30、-
See the description of the PAUSE request for further examples.
さらなる例のためのPAUSE要求の記述を見てください。
A PLAY request without a Range header is legal. It starts playing a stream from the beginning unless the stream has been paused. If a stream has been paused via PAUSE, stream delivery resumes at the pause point. If a stream is playing, such a PLAY request causes no further action and can be used by the client to test server liveness.
RangeヘッダーのないPLAY要求は法的です。 ストリームがポーズされていない場合、それは始めからストリームをプレーし始めます。 ストリームがPAUSEを通してポーズされたなら、ストリーム配送はくぎりのポイントで再開します。 ストリームがプレーしているなら、そのようなPLAY要求を、これ以上動作を引き起こさないで、クライアントは、サーバ活性をテストするのに使用できます。
Schulzrinne, et. al. Standards Track [Page 34] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[34ページ]RFC2326リアルタイム
The Range header may also contain a time parameter. This parameter specifies a time in UTC at which the playback should start. If the message is received after the specified time, playback is started immediately. The time parameter may be used to aid in synchronization of streams obtained from different sources.
また、Rangeヘッダーは時間パラメタを含むかもしれません。 このパラメタは再生が始まるべきであるUTCで時間を指定します。 指定された時の後にメッセージを受け取るなら、すぐに、再生を始めます。 時間パラメタは、さまざまな原因から得られたストリームの同期で支援するのに使用されるかもしれません。
For a on-demand stream, the server replies with the actual range that will be played back. This may differ from the requested range if alignment of the requested range to valid frame boundaries is required for the media source. If no range is specified in the request, the current position is returned in the reply. The unit of the range in the reply is the same as that in the request.
要求次第のストリームのために、サーバは再生される実際の範囲で返答します。 有効なフレーム境界への要求された範囲の整列がメディア・ソースに必要であるなら、これは要求された範囲と異なるかもしれません。 要求で範囲を全く指定しないなら、回答で現在の位置を返します。 回答における、範囲のユニットは要求におけるそれと同じです。
After playing the desired range, the presentation is automatically paused, as if a PAUSE request had been issued.
必要な範囲をプレーした後に、まるでPAUSE要求が出されたかのようにプレゼンテーションは自動的にポーズされます。
The following example plays the whole presentation starting at SMPTE time code 0:10:20 until the end of the clip. The playback is to start at 15:36 on 23 Jan 1997.
以下の例はSMPTEタイム・コード0:10:20で全体のプレゼンテーション始めをクリップの端までプレーします。 再生は1997年1月23日15:36に始まることになっています。
C->S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0
CSeq: 833
Session: 12345678
Range: smpte=0:10:20-;time=19970123T153600Z
C>S: PLAY rtsp://audio.example.com/twister.en RTSP/1.0CSeq: 833セッション: 12345678は及びます: smpte=0:10:20; 時間は19970123T153600Zと等しいです。
S->C: RTSP/1.0 200 OK
CSeq: 833
Date: 23 Jan 1997 15:35:06 GMT
Range: smpte=0:10:22-;time=19970123T153600Z
S>C: RTSP/1.0 200はCSeqを承認します: 833 日付: 1997年1月23日のグリニッジ標準時15時35分6秒に、及んでください: smpte=0:10:22; 時間は19970123T153600Zと等しいです。
For playing back a recording of a live presentation, it may be desirable to use clock units:
ライブプレゼンテーションの録音を再生するのに、クロックユニットを使用するのは望ましいかもしれません:
C->S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0
CSeq: 835
Session: 12345678
Range: clock=19961108T142300Z-19961108T143520Z
C>S: PLAY rtsp://audio.example.com/meeting.en RTSP/1.0CSeq: 835セッション: 12345678は及びます: 時計=19961108T142300Z-19961108T143520Z
S->C: RTSP/1.0 200 OK
CSeq: 835
Date: 23 Jan 1997 15:35:06 GMT
S>C: RTSP/1.0 200はCSeqを承認します: 835 日付: 1997年1月23日のグリニッジ標準時15時35分6秒
A media server only supporting playback MUST support the npt format and MAY support the clock and smpte formats.
再生をサポートするだけであるメディアサーバは、時計とsmpteが形式であるとnptが形式であるとサポートしなければならなくて、サポートするかもしれません。
Schulzrinne, et. al. Standards Track [Page 35] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[35ページ]RFC2326リアルタイム
10.6 PAUSE
10.6 くぎり
The PAUSE request causes the stream delivery to be interrupted (halted) temporarily. If the request URL names a stream, only playback and recording of that stream is halted. For example, for audio, this is equivalent to muting. If the request URL names a presentation or group of streams, delivery of all currently active streams within the presentation or group is halted. After resuming playback or recording, 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要求で、一時ストリーム配送を中断します(立ち止まります)。 要求URLがストリームを命名するなら、そのストリームの再生と録音だけが止められます。 例えば、オーディオにおいて、これは無言に同等です。 要求URLがストリームのプレゼンテーションかグループを命名するなら、プレゼンテーションかグループの中のすべての現在アクティブなストリームの配送は止められます。 再生か録音を再開した後に、道の同期を維持しなければなりません。 どんなサーバリソースも保たれます、サーバはSessionヘッダーのタイムアウトパラメタがSETUPメッセージにある状態で指定された持続時間のためにポーズされた後に、セッションと無料のリソースを終えるかもしれませんが。
Example:
例:
C->S: PAUSE rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 834
Session: 12345678
C>S: PAUSE rtsp://example.com/シューシューという音/foo RTSP/1.0CSeq: 834セッション: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 834
Date: 23 Jan 1997 15:35:06 GMT
S>C: RTSP/1.0 200はCSeqを承認します: 834 日付: 1997年1月23日のグリニッジ標準時15時35分6秒
The PAUSE request may contain a Range header specifying when the stream or presentation is to be halted. We refer to this point as the "pause point". The header must contain exactly one value rather than a time range. The normal play time for the stream is set to the pause point. The pause request becomes effective the first time the server is encountering the time point specified in any of the currently pending PLAY requests. If the Range header specifies a time outside any currently pending PLAY requests, the error "457 Invalid Range" is returned. If a media unit (such as an audio or video frame) starts presentation at exactly the pause point, it is not played or recorded. If the Range header is missing, stream delivery is interrupted immediately on receipt of the message and the pause point is set to the current normal play time.
PAUSE要求はストリームかプレゼンテーションがいつ立ち止まるかことであると指定するRangeヘッダーを含むかもしれません。 私たちは「くぎりのポイント」としてこの位まで参照します。 ヘッダーはまさに時間範囲よりむしろ1つの値を含まなければなりません。 ストリームのための正常なプレー時間はくぎりのポイントに決められます。 くぎりの要求はポイントが現在未定のPLAY要求のどれかで指定したときサーバが遭遇している1回目に有効になります。 Rangeヘッダーがどんな現在未定のPLAY要求の外における時間、「457の無効の範囲」が返される誤りも指定するなら。 メディア部隊(オーディオかビデオフレームなどの)がまさにくぎりのポイントでのプレゼンテーションを始動するなら、それは、プレーもされませんし、記録もされません。 Rangeヘッダーが行方不明であるなら、ストリーム配送はすぐメッセージを受け取り次第中断されます、そして、くぎりのポイントは現在の正常なプレー時間に設定されます。
A PAUSE request discards all queued PLAY requests. However, the pause point in the media stream MUST be maintained. A subsequent PLAY request without Range header resumes from the pause point.
PAUSE要求はすべての列に並ばせられたPLAY要求を捨てます。 しかしながら、メディアストリームにおけるくぎりのポイントを維持しなければなりません。 Rangeヘッダーのないその後のPLAY要求はくぎりのポイントから再開します。
For example, if the server has play requests for ranges 10 to 15 and 20 to 29 pending and then receives a pause request for NPT 21, it would start playing the second range and stop at NPT 21. If the pause request is for NPT 12 and the server is playing at NPT 13 serving the first play request, the server stops immediately. If the pause request is for NPT 16, the server stops after completing the first
例えば、サーバがNPT21のために10〜15と20〜29の範囲を求めるプレー要求を持って、次に、くぎりの要求を受け取るなら、それは、2番目の範囲をプレーし始めて、NPT21で止まるでしょう。 くぎりの要求がNPT12のためのものであり、サーバが最初のプレー要求に役立つNPT13で上演されているなら、サーバはすぐに、止まります。 くぎりの要求がNPT16のためのものであるなら、1番目を完成した後に、サーバは止まります。
Schulzrinne, et. al. Standards Track [Page 36] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[36ページ]RFC2326リアルタイム
play request and discards the second play request.
プレーは、2番目のプレー要求を要求して、捨てます。
As another example, if a server has received requests to play ranges 10 to 15 and then 13 to 20 (that is, overlapping ranges), the PAUSE request for NPT=14 would take effect while the server plays the first range, with the second PLAY request effectively being ignored, assuming the PAUSE request arrives before the server has started playing the second, overlapping range. Regardless of when the PAUSE request arrives, it sets the NPT to 14.
別の例として、サーバが10〜15に範囲をプレーして、次に13〜20にプレーするという要求を受け取ったなら(すなわち、重なることは及びます)、PAUSEは、NPTのために= サーバが最初の範囲をプレーしている間14が実施するよう要求します、PLAYが有効に要求する無視される秒で、サーバが2番目をプレーし始める前にPAUSE要求が到着すると仮定して、範囲を重ね合わせて。 PAUSE要求が到着する時にかかわらず、それは14にNPTを設定します。
If the server has already sent data beyond the time specified in the Range header, a PLAY would still resume at that point in time, as it is assumed that the client has discarded data after that point. This ensures continuous pause/play cycling without gaps.
サーバが既にデータをRangeヘッダーで指定された時間を超えたところまで送ったなら、PLAYは時間内にその時まだ再開しているでしょう、クライアントがそのポイント後にデータを捨てたと思われるとき。 これはギャップなしで循環する連続したくぎり/プレーを確実にします。
10.7 TEARDOWN
10.7 分解
The TEARDOWN request stops the stream delivery for the given URI, freeing the resources associated with it. If the URI is the presentation URI for this presentation, any RTSP session identifier associated with the session is no longer valid. Unless all transport parameters are defined by the session description, a SETUP request has to be issued before the session can be played again.
TEARDOWN随時停留所、与えられたURIのためのそれに関連しているリソースを解放するストリーム配送。 URIがこのプレゼンテーションのためのプレゼンテーションURIであるなら、セッションに関連しているどんなRTSPセッション識別子ももう有効ではありません。 すべての輸送パラメタがセッション記述で定義されるというわけではないなら、再びセッションをプレーできる前にSETUP要求は出されなければなりません。
Example:
C->S: TEARDOWN rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 892
Session: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 892
例: C>S: TEARDOWN rtsp://example.com/シューシューという音/foo RTSP/1.0CSeq: 892セッション: 12345678秒間の>C: RTSP/1.0 200はCSeqを承認します: 892
10.8 GET_PARAMETER
10.8は_パラメタを得ます。
The GET_PARAMETER request retrieves the value of a parameter of a
presentation or stream specified in the URI. The content of the reply
and response is left to the implementation. GET_PARAMETER with no
entity body may be used to test client or server liveness ("ping").
PARAMETERが要求するGET_はURIで指定されたプレゼンテーションかストリームのパラメタの値を検索します。 回答と応答の内容は実装に残されます。 実体本体のないGET_PARAMETERは、クライアントかサーバ活性(「ピング」)をテストするのに使用されるかもしれません。
Example:
例:
S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 431
Content-Type: text/parameters
Session: 12345678
Content-Length: 15
S>C: GET_PARAMETER rtsp://example.com/シューシューという音/foo RTSP/1.0CSeq: 431コンテントタイプ: テキスト/パラメタSession: 12345678 コンテンツの長さ: 15
packets_received
jitter
パケット_はジターを受けました。
Schulzrinne, et. al. Standards Track [Page 37] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[37ページ]RFC2326リアルタイム
C->S: RTSP/1.0 200 OK
CSeq: 431
Content-Length: 46
Content-Type: text/parameters
C>S: RTSP/1.0 200はCSeqを承認します: 431 コンテンツの長さ: 46コンテントタイプ: テキスト/パラメタ
packets_received: 10
jitter: 0.3838
パケット_は受信されました: 10ジター: 0.3838
The "text/parameters" section is only an example type for
parameter. This method is intentionally loosely defined with the
intention that the reply content and response content will be
defined after further experimentation.
「テキスト/パラメタ」セクションはパラメタのための例のタイプにすぎません。 このメソッドは故意に回答内容と応答内容がさらなる実験の後に定義されるという意志で緩く定義されます。
10.9 SET_PARAMETER
10.9セット_パラメタ
This method requests to set the value of a parameter for a
presentation or stream specified by the URI.
このメソッドは、プレゼンテーションかストリームのためのパラメタの値を設定するのがURIで指定したよう要求します。
A request SHOULD 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.
SHOULDがクライアントが、特定の要求がなぜ失敗したかを決心しているのを許容するただ一つのパラメタを含むだけであるという要求。 要求がいくつかのパラメタを含んでいるなら、首尾よくパラメタのすべてを設定できるなら、サーバは要求に影響するだけでよいです。 サーバは、パラメタが繰り返して同じ値に設定されるのを許容しなければなりませんが、それは、パラメタ値を変えるのを禁じるかもしれません。
Note: transport parameters for the media stream MUST only be set with
the SETUP command.
以下に注意してください。 SETUPコマンドでメディアストリームのための輸送パラメタを設定するだけでよいです。
Restricting setting transport parameters to SETUP is for the
benefit of firewalls.
設定輸送パラメタをSETUPに制限するのは、ファイアウォールの利益のためのものです。
The parameters are split in a fine-grained fashion so that there
can be more meaningful error indications. However, it may make
sense to allow the setting of several parameters if an atomic
setting is desirable. Imagine device control where the client does
not want the camera to pan unless it can also tilt to the right
angle at the same time.
パラメタは、より重要な誤り指摘があることができるように、きめ細かに粒状のファッションで分けられます。 しかしながら、原子設定が望ましいなら、それはいくつかのパラメタの設定を許す意味になるかもしれません。 また、同時に直角に傾くことができないならクライアントが、カメラが撮影されて欲しくないところで装置制御を想像してください。
Example:
例:
C->S: SET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 421
Content-length: 20
Content-type: text/parameters
C>S: SET_PARAMETER rtsp://example.com/シューシューという音/foo RTSP/1.0CSeq: 421 コンテンツの長さ: 20文書内容: テキスト/パラメタ
barparam: barstuff
barparam: barstuff
S->C: RTSP/1.0 451 Invalid Parameter
S>C: RTSP/1.0 451の無効のパラメタ
Schulzrinne, et. al. Standards Track [Page 38] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[38ページ]RFC2326リアルタイム
CSeq: 421
Content-length: 10
Content-type: text/parameters
CSeq: 421 コンテンツの長さ: 10文書内容: テキスト/パラメタ
barparam
barparam
The "text/parameters" section is only an example type for
parameter. This method is intentionally loosely defined with the
intention that the reply content and response content will be
defined after further experimentation.
「テキスト/パラメタ」セクションはパラメタのための例のタイプにすぎません。 このメソッドは故意に回答内容と応答内容がさらなる実験の後に定義されるという意志で緩く定義されます。
10.10 REDIRECT
10.10は向け直します。
A redirect request informs the client that it must connect to another server location. It contains the mandatory header Location, which indicates that the client should issue requests for that URL. It may contain the parameter Range, which indicates when the redirection takes effect. If the client wants to continue to send or receive media for this URI, the client MUST issue a TEARDOWN request for the current session and a SETUP for the new session at the designated host.
再直接の要求はそれがもう1つのサーバ位置に接しなければならないクライアントに知らせます。 それは義務的なヘッダーLocationを含んでいます。(Locationは、クライアントがそのURLを求める要求を出すべきであるのを示します)。 それはパラメタRangeを含むかもしれません。(Rangeはリダイレクションがいつ効くかを示します)。 クライアントが、このURIのためにメディアを送るか、または受け取り続けたいなら、クライアントは新しいセッションのために指定されたホストで現在のセッションとSETUPを求めるTEARDOWN要求を出さなければなりません。
This example request redirects traffic for this URI to the new server at the given play time:
この例の要求は与えられたプレー時にこのURIのために新しいサーバにトラフィックを向け直します:
S->C: REDIRECT rtsp://example.com/fizzle/foo RTSP/1.0
CSeq: 732
Location: rtsp://bigserver.com:8001
Range: clock=19960213T143205Z-
S>C: REDIRECT rtsp://example.com/シューシューという音/foo RTSP/1.0CSeq: 732位置: rtsp://bigserver.com: 8001Range: =19960213T143205Zの時間を計ってください、-
10.11 RECORD
10.11 記録
This method initiates recording a range of media data according to the presentation description. The timestamp reflects start and end time (UTC). If no time range is given, use the start or end time provided in the presentation description. If the session has already started, commence recording immediately.
プレゼンテーション記述に従ってさまざまなメディアデータを記録するこのメソッド開始。 タイムスタンプは始めと終わりの時間(UTC)を反映します。 時間範囲を全く与えないなら、プレゼンテーション記述に提供された始めか終わりの時間を費やしてください。 セッションが既に始まったなら、すぐに記録し始めてください。
The server decides whether to store the recorded data under the request-URI or another URI. If the server does not use the request- URI, the response SHOULD be 201 (Created) and contain an entity which describes the status of the request and refers to the new resource, and a Location header.
サーバは、要求URIか別のURIの下で記録データを保存するかどうか決めます。 サーバが要求URIを使用しないなら、応答SHOULDは201歳(作成される)であり、要求の状態について説明して、新しいリソース、およびLocationヘッダーについて言及する実体を含んでいます。
A media server supporting recording of live presentations MUST support the clock range format; the smpte format does not make sense.
ライブプレゼンテーションの録音をサポートするメディアサーバは、時計範囲が形式であるとサポートしなければなりません。 smpte形式は理解できません。
Schulzrinne, et. al. Standards Track [Page 39] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[39ページ]RFC2326リアルタイム
In this example, the media server was previously invited to the conference indicated.
この例では、メディアサーバは以前に、示された会議に招待されました。
C->S: RECORD rtsp://example.com/meeting/audio.en RTSP/1.0
CSeq: 954
Session: 12345678
Conference: 128.16.64.19/32492374
C>S: RECORD rtsp://example.com/ミーティング/audio.en RTSP/1.0CSeq: 954セッション: 12345678コンファレンス: 128.16.64.19/32492374
10.12 Embedded (Interleaved) Binary Data
10.12 埋め込まれた(はさみ込まれる)バイナリ・データ
Certain firewall designs and other circumstances may force a server to interleave RTSP methods and stream data. This interleaving should generally be avoided unless necessary since it complicates client and server operation and imposes additional overhead. Interleaved binary data SHOULD only be used if RTSP is carried over TCP.
あるファイアウォールデザインと他の事情のために、サーバはやむを得ずRTSPメソッドとストリームデータをはさみ込むかもしれません。 必要でない場合、クライアントとサーバ操作を複雑にして、追加オーバーヘッドを課すので、一般に、このインターリービングは避けられるべきです。 バイナリ・データSHOULDをはさみ込む、RTSPがTCPの上まで運ばれるなら、単に使用されてください。
Stream data such as RTP packets is encapsulated by an ASCII dollar sign (24 hexadecimal), followed by a one-byte channel identifier, followed by the length of the encapsulated binary data as a binary, two-byte integer in network byte order. The stream data follows immediately afterwards, without a CRLF, but including the upper-layer protocol headers. Each $ block contains exactly one upper-layer protocol data unit, e.g., one RTP packet.
RTPパケットなどのストリームデータはカプセル化されたバイナリ・データの長さに従って1バイトのチャンネル識別子があとに続いた(24 16進)がネットワークバイトオーダーにおける2進の、そして、2バイトの整数として従ったASCIIドル記号によってカプセル化されます。 データがその後すぐにCRLFなしで続くストリームにもかかわらず、上側の層のプロトコルヘッダーを含んでいること。 それぞれの$ブロックはまさに1つの上側の層のプロトコルデータ単位、例えば1つのRTPパケットを含んでいます。
The channel identifier is defined in the Transport header with the interleaved parameter(Section 12.39).
チャンネル識別子ははさみ込まれたパラメタ(セクション12.39)があるTransportヘッダーで定義されます。
When the transport choice is RTP, RTCP messages are also interleaved by the server over the TCP connection. As a default, RTCP packets are sent on the first available channel higher than the RTP channel. The client MAY explicitly request RTCP packets on another channel. This is done by specifying two channels in the interleaved parameter of the Transport header(Section 12.39).
また、輸送選択がRTPであるときに、RTCPメッセージはサーバによってTCP接続の上にはさみ込まれます。 デフォルトとして、第1代利用可能なチャンネルでRTCPパケットをRTPが精神を集中するより高く送ります。 クライアントは別のチャンネルの上に明らかにRTCPパケットを要求するかもしれません。 Transportヘッダー(セクション12.39)のはさみ込まれたパラメタの2個のチャンネルを指定することによって、これをします。
RTCP is 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 TCP control connection when
required by the network configuration and transfer them onto UDP
when possible.
2つ以上のストリームがそのようなファッションではさみ込まれるとき、RTCPが同期に必要です。 また、これはネットワーク・コンフィギュレーションが必要であるとTCPコントロール接続でRTP/RTCPパケットにトンネルを堀って、可能であるときにそれらをUDPに移す便利な方法を提供します。
C->S: SETUP rtsp://foo.com/bar.file RTSP/1.0
CSeq: 2
Transport: RTP/AVP/TCP;interleaved=0-1
C>S: SETUP rtsp://foo.com/bar.file RTSP/1.0CSeq: 2 輸送: RTP/AVP/TCP; はさみ込まれた=0-1
S->C: RTSP/1.0 200 OK
CSeq: 2
Date: 05 Jun 1997 18:57:18 GMT
Transport: RTP/AVP/TCP;interleaved=0-1
S>C: RTSP/1.0 200はCSeqを承認します: 2 日付: 1997年6月5日のグリニッジ標準時18時57分18秒の輸送: RTP/AVP/TCP; はさみ込まれた=0-1
Schulzrinne, et. al. Standards Track [Page 40] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[40ページ]RFC2326リアルタイム
Session: 12345678
セッション: 12345678
C->S: PLAY rtsp://foo.com/bar.file RTSP/1.0
CSeq: 3
Session: 12345678
C>S: PLAY rtsp://foo.com/bar.file RTSP/1.0CSeq: 3セッション: 12345678
S->C: RTSP/1.0 200 OK
CSeq: 3
Session: 12345678
Date: 05 Jun 1997 18:59:15 GMT
RTP-Info: url=rtsp://foo.com/bar.file;
seq=232433;rtptime=972948234
S>C: RTSP/1.0 200はCSeqを承認します: 3セッション: 12345678 日付: 1997年6月5日のグリニッジ標準時18時59分15秒のRTP-インフォメーション: url=rtsp://foo.com/bar.file。 seq=232433; rtptime=972948234
S->C: $%%BODY%%00{2 byte length}{"length" bytes data, w/RTP header}
S->C: $%%BODY%%00{2 byte length}{"length" bytes data, w/RTP header}
S->C: $%%BODY%%01{2 byte length}{"length" bytes RTCP packet}
S>C: 000円の$の2バイトの長さ、RTPヘッダーがある「長さ」バイトデータ、S>C: 000円の$の2バイトの長さ、RTPヘッダーがある「長さ」バイトデータ、S>C: 001円の$の2バイトの長さ「長さ」バイトRTCPパケット
11 Status Code Definitions
11 ステータスコード定義
Where applicable, HTTP status [H10] codes are reused. Status codes that have the same meaning are not repeated here. See Table 1 for a listing of which status codes may be returned by which requests.
適切であるところでは、HTTP状態[H10]コードが再利用されます。 同じ意味を持っているステータスコードがここで繰り返されません。 ステータスコードがどの要求で返されるかもしれないリストのためにTable1を見てください。
11.1 Success 2xx
11.1 成功2xx
11.1.1 250 Low on Storage Space
11.1.1 250 集積スペースでは、低いです。
The server returns this warning after receiving a RECORD request that it may not be able to fulfill completely due to insufficient storage space. If possible, the server should use the Range header to indicate what time period it may still be able to record. Since other processes on the server may be consuming storage space simultaneously, a client should take this only as an estimate.
それが完全な不十分な集積スペースのため実現させることができないかもしれないRECORD要求を受け取った後に、サーバはこの警告を返します。 できれば、サーバは記録できる状態でそれがそうする期間がまだ何時であるかを示すRangeヘッダーを使用するべきです。 サーバの他のプロセスが同時に集積スペースを消費するかもしれないので、クライアントは単に見積りとしてこれをみなすべきです。
11.2 Redirection 3xx
11.2 リダイレクション3xx
See [H10.3].
[H10.3]を見てください。
Within RTSP, redirection may be used for load balancing or redirecting stream requests to a server topologically closer to the client. Mechanisms to determine topological proximity are beyond the scope of this specification.
RTSPの中では、リダイレクションは、クライアントの、より近くでサーバに位相的にロードバランシングに使用されるか、またはストリーム要求を向け直しているかもしれません。 位相的な近接を決定するメカニズムはこの仕様の範囲を超えています。
Schulzrinne, et. al. Standards Track [Page 41] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[41ページ]RFC2326リアルタイム
11.3 Client Error 4xx
11.3 クライアント誤り4xx
11.3.1 405 Method Not Allowed
11.3.1 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, e.g., if a RECORD request is issued even though the mode parameter in the Transport header only specified PLAY.
要求で指定されたメソッドは要求URIによって特定されたリソースのために許容されていません。 応答は要求されたリソースのための有効なメソッドのリストを含むAllowヘッダーを含まなければなりません。 このステータスコードは要求が、SETUPの間に示されなかったメソッドを使用するのを試みるならまた、使用されることです、例えば、TransportヘッダーのモードパラメタがPLAYを指定しただけですが、RECORD要求が出されるなら。
11.3.2 451 Parameter Not Understood
11.3.2 451 パラメタは分かりませんでした。
The recipient of the request does not support one or more parameters contained in the request.
要求の受取人は要求に含まれた1つ以上のパラメタをサポートしません。
11.3.3 452 Conference Not Found
11.3.3 452 見つけられなかったコンファレンス
The conference indicated by a Conference header field is unknown to the media server.
メディアサーバにおいて、コンファレンスヘッダーフィールドによって示された会議は未知です。
11.3.4 453 Not Enough Bandwidth
11.3.4 453 十分な帯域幅でない
The request was refused because there was insufficient bandwidth. This may, for example, be the result of a resource reservation failure.
不十分な帯域幅があったので、要求は拒否されました。 例えば、これは資源予約失敗の結果であるかもしれません。
11.3.5 454 Session Not Found
11.3.5 454 見つけられなかったセッション
The RTSP session identifier in the Session header is missing, invalid, or has timed out.
SessionヘッダーのRTSPセッション識別子は、取り逃がす病人であるか外で時間があります。
11.3.6 455 Method Not Valid in This State
11.3.6 455 この状態で有効でないメソッド
The client or server cannot process this request in its current state. The response SHOULD contain an Allow header to make error recovery easier.
クライアントかサーバが現状のときにこの要求を処理できません。 応答SHOULDはエラー回復をより簡単にするAllowヘッダーを含んでいます。
11.3.7 456 Header Field Not Valid for Resource
11.3.7 456 リソースには、有効でないヘッダーフィールド
The server could not act on a required request header. For example, if PLAY contains the Range header field but the stream does not allow seeking.
サーバは必要な要求ヘッダーに影響できませんでした。 例えば、PLAYがRangeを含んでいるなら、ヘッダーフィールドにもかかわらず、ストリームは、探すのを許容しません。
Schulzrinne, et. al. Standards Track [Page 42] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[42ページ]RFC2326リアルタイム
11.3.8 457 Invalid Range
11.3.8 457 無効の範囲
The Range value given is out of bounds, e.g., beyond the end of the presentation.
区域外に、そして、例えば、プレゼンテーションの端のときに、与えられたRange値があります。
11.3.9 458 Parameter Is Read-Only
11.3.9 458 パラメタは書き込み禁止です。
The parameter to be set by SET_PARAMETER can be read but not modified.
SET_PARAMETERによって設定されるべきパラメタは、読みますが、変更できません。
11.3.10 459 Aggregate Operation Not Allowed
11.3.10 459 許されなかった集合操作
The requested method may not be applied on the URL in question since it is an aggregate (presentation) URL. The method may be applied on a stream URL.
要求されたメソッドは、それが集合(プレゼンテーション)URLであるので、問題のURLで適用されないかもしれません。 メソッドはストリームURLで適用されるかもしれません。
11.3.11 460 Only Aggregate Operation Allowed
11.3.11 460 許された集合操作だけ
The requested method may not be applied on the URL in question since it is not an aggregate (presentation) URL. The method may be applied on the presentation URL.
要求されたメソッドは、それが集合(プレゼンテーション)URLでないので、問題のURLで適用されないかもしれません。 メソッドはプレゼンテーションURLで適用されるかもしれません。
11.3.12 461 Unsupported Transport
11.3.12 461 サポートされない輸送
The Transport field did not contain a supported transport specification.
Transport分野はサポートしている輸送仕様を含みませんでした。
11.3.13 462 Destination Unreachable
11.3.13 462 目的地手が届きません。
The data transmission channel could not be established because the client address could not be reached. This error will most likely be the result of a client attempt to place an invalid Destination parameter in the Transport field.
クライアントアドレスに達することができなかったので、データ伝送チャンネルを確立できませんでした。 この誤りはたぶん無効のDestinationパラメタをTransport分野に置くクライアント試みの結果になるでしょう。
11.3.14 551 Option not supported
11.3.14 551 サポートされなかったオプション
An option given in the Require or the Proxy-Require fields was not supported. The Unsupported header should be returned stating the option for which there is no support.
分野をProxy必要としてください。または、Requireで与えられたオプション、サポートされませんでした。 サポートが全くないオプションを述べながら、Unsupportedヘッダーを返すべきです。
Schulzrinne, et. al. Standards Track [Page 43] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[43ページ]RFC2326リアルタイム
12 Header Field Definitions
12 ヘッダーフィールド定義
HTTP/1.1 [2] or other, non-standard header fields not listed here currently have no well-defined meaning and SHOULD be ignored by the recipient.
現在ここに記載されていないHTTP/1.1[2]、または他の、そして、標準的でないヘッダーフィールドで、受取人は明確な意味とSHOULDを全く無視しません。
Table 3 summarizes the header fields used by RTSP. Type "g" designates general request headers to be found in both requests and responses, type "R" designates request headers, type "r" designates response headers, and type "e" designates entity header fields. Fields marked with "req." in the column labeled "support" MUST be implemented by the recipient for a particular method, while fields marked "opt." are optional. Note that not all fields marked "req." will be sent in every request of this type. The "req." means only that client (for response headers) and server (for request headers) MUST implement the fields. The last column lists the method for which this header field is meaningful; the designation "entity" refers to all methods that return a message body. Within this specification, DESCRIBE and GET_PARAMETER fall into this class.
テーブル3はRTSPによって使用されたヘッダーフィールドをまとめます。 タイプ「g」は要求と応答の両方で見つけられる一般的な要求ヘッダーを任命します、そして、タイプ「R」は要求ヘッダーを任命します、そして、タイプ「r」は応答ヘッダを任命します、そして、タイプ「e」は実体ヘッダーフィールドを指定します。 受取人は特定のメソッドのために"req" コラムが「サポート」とラベルしたコネで示される分野を実装しなければなりません、分野が「選んでください」をマークしましたが任意です。 すべての分野が"req"をマークしたというわけではないことに注意してください。このタイプのあらゆる要求では、送るでしょう。 . "req"、そのクライアント(応答ヘッダのための)とサーバ(要求ヘッダーのための)だけが分野を実装しなければならないことを意味します。 最後のコラムはこのヘッダーフィールドが重要であるメソッドを記載します。 名称「実体」はメッセージ本体を返すすべてのメソッドを示します。 この仕様の中では、DESCRIBEとGET_PARAMETERはこのクラスになります。
Schulzrinne, et. al. Standards Track [Page 44] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[44ページ]RFC2326リアルタイム
Header type support methods Accept R opt. entity Accept-Encoding R opt. entity Accept-Language R opt. all Allow r opt. all Authorization R opt. all Bandwidth R opt. all Blocksize R opt. all but OPTIONS, TEARDOWN Cache-Control g opt. SETUP Conference R opt. SETUP Connection g req. all Content-Base e opt. entity Content-Encoding e req. SET_PARAMETER Content-Encoding e req. DESCRIBE, ANNOUNCE Content-Language e req. DESCRIBE, ANNOUNCE Content-Length e req. SET_PARAMETER, ANNOUNCE Content-Length e req. entity Content-Location e opt. entity Content-Type e req. SET_PARAMETER, ANNOUNCE Content-Type r req. entity CSeq g req. all Date g opt. all Expires e opt. DESCRIBE, ANNOUNCE From R opt. all If-Modified-Since R opt. DESCRIBE, SETUP Last-Modified e opt. entity Proxy-Authenticate Proxy-Require R req. all Public r opt. all Range R opt. PLAY, PAUSE, RECORD Range r opt. PLAY, PAUSE, RECORD Referer R opt. all Require R req. all Retry-After r opt. all RTP-Info r req. PLAY Scale Rr opt. PLAY, RECORD Session Rr req. all but SETUP, OPTIONS Server r opt. all Speed Rr opt. PLAY Transport Rr req. SETUP Unsupported r req. all User-Agent R opt. all Via g opt. all WWW-Authenticate r opt. all
ヘッダータイプサポートメソッドAccept Rは選びます。実体Accept-コード化Rは選ばれます。実体Accept-言語Rは選ばれます。すべてのAllow rが選びます。すべてのAuthorization Rが選びます。すべてのBandwidth Rが選びます。すべてのBlocksize Rが選びます。OPTIONS以外のすべて、TEARDOWN Cache-コントロールgは選ばれます。 SETUPコンファレンスRは選ばれます。 SETUP Connection g reqすべてのContent-基地のeが. 実体Content-コード化e reqを選びます。 e reqをSET_PARAMETER Contentコード化します。 DESCRIBE、ANNOUNCE Content-言語e req。 DESCRIBE、ANNOUNCE Content-長さのe req。 ANNOUNCE Content-長さのe req SET_PARAMETER、実体Content-位置のeは. 実体コンテントタイプe reqを選びます。 req SET_PARAMETER、ANNOUNCEコンテントタイプr req実体CSeq g Date gは選びます。すべてのExpires eが選びます。 DESCRIBE、ANNOUNCE From Rは選ばれます。すべての以来変更されたIf Rが選ばれます。 R reqをProxy必要としてください。すべてのPublic rが選びます。DESCRIBE、SETUP最終更新日eが. 実体を選ぶ、Proxy認証、すべてのRange Rが選びます。 PLAY、PAUSE、RECORD Range rは選ばれます。 PLAY、PAUSE、RECORD Referer Rは選ばれます。Require R reqすべてのすべての後のRetry rが. すべてのRTP-インフォメーションr reqを選びます。 PLAY Scale Rrは選びます。 PLAY、RECORD Session Rr req SETUP、OPTIONS Server r以外のすべてが選ばれます。すべてのSpeed Rrが選びます。 PLAY Transport Rr req。 SETUP Unsupported r reqすべてのUser-エージェントRが選ばれます。すべてのVia gが選びます。すべてがrをWWW認証します。選んでください、すべて
Schulzrinne, et. al. Standards Track [Page 45] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[45ページ]RFC2326リアルタイム
Overview of RTSP header fields
RTSPヘッダーフィールドの概要
12.1 Accept
12.1は受け入れます。
The Accept request-header field can be used to specify certain presentation description content types which are acceptable for the response.
応答において、許容できるあるプレゼンテーション記述content typeを指定するのにAccept要求ヘッダーフィールドを使用できます。
The "level" parameter for presentation descriptions is properly
defined as part of the MIME type registration, not here.
プレゼンテーション記述のための「平らな」パラメタは適切にここでないことでのMIMEの種類登録の一部と定義されます。
See [H14.1] for syntax.
構文に関して[H14.1]を見てください。
Example of use:
Accept: application/rtsl, application/sdp;level=2
使用に関する例: 受け入れます: アプリケーション/rtsl、アプリケーション/sdp; レベル=2
12.2 Accept-Encoding
12.2、コード化を受け入れます。
See [H14.3]
見てください。[H14.3]
12.3 Accept-Language
12.3、言語を受け入れます。
See [H14.4]. Note that the language specified applies to the presentation description and any reason phrases, not the media content.
[H14.4]を見てください。 言語が指定したというメモはメディア内容ではなく、プレゼンテーション記述とどんな理由句にも適用されます。
12.4 Allow
12.4は許容します。
The Allow response header field lists the methods supported by the resource identified by the request-URI. The purpose of this field is to strictly inform the recipient of valid methods associated with the resource. An Allow header field must be present in a 405 (Method not allowed) response.
Allow応答ヘッダーフィールドは要求URIによって特定されたリソースによってサポートされたメソッドを記載します。 この分野の目的はリソースに関連している有効なメソッドについて厳密に受取人に知らせることです。 Allowヘッダーフィールドは405(許容されなかったメソッド)応答で存在していなければなりません。
Example of use:
Allow: SETUP, PLAY, RECORD, SET_PARAMETER
使用に関する例: 許容します: セットアップ、記録的なプレーは_パラメタを設定します。
12.5 Authorization
12.5 承認
See [H14.8]
見てください。[H14.8]
12.6 Bandwidth
12.6 帯域幅
The Bandwidth request header field describes the estimated bandwidth available to the client, expressed as a positive integer and measured in bits per second. The bandwidth available to the client may change during an RTSP session, e.g., due to modem retraining.
Bandwidthは、ヘッダーフィールドが正の整数として言い表されて、bpsで測定されたクライアントにとって、利用可能なおよそ帯域幅について説明するよう要求します。 クライアントにとって、利用可能な帯域幅は例えば、モデム再教育によるRTSPセッションの間、変化するかもしれません。
Schulzrinne, et. al. Standards Track [Page 46] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[46ページ]RFC2326リアルタイム
Bandwidth = "Bandwidth" ":" 1*DIGIT
「帯域幅は「帯域幅」と等しい」:、」 1*ケタ
Example:
Bandwidth: 4000
例: 帯域幅: 4000
12.7 Blocksize
12.7はBlocksizeされます。
This 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 which 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 (416) if the value is syntactically invalid.
クライアントから特定のメディア向けの資料セットサイズをサーバに求めるメディアサーバにこの要求ヘッダーフィールドを送ります。 このパケットサイズはIP、UDP、またはRTPなどの下層ヘッダーを含んでいません。 サーバはaがblocksizeする使用に無料です(要求されたものより低いです)。 必要なら、サーバは、最小の、そして、メディア特有のブロック・サイズの最も近い倍数にこのパケットサイズに先端を切らせるか、またはメディア特有のサイズでそれをくつがえすかもしれません。 ブロック・サイズは八重奏で測定された陽の10進数であるに違いありません。 (416) 値がシンタクス上無効である場合にだけ、サーバは誤りを返します。
12.8 Cache-Control
12.8 キャッシュ制御
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-コントロールの一般的なヘッダーフィールドは、要求/応答チェーンに沿ってメカニズムをキャッシュして、すべてで従わなければならない指示を指定するのに使用されます。
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 SETUP request and its response. Note: Cache-Control does not govern the caching of responses as for HTTP, but rather of the stream identified by the SETUP request. Responses to RTSP requests are not cacheable, except for responses to DESCRIBE.
キャッシュコントロールはSETUP要求とその応答で指定されるだけであるべきです。 以下に注意してください。 キャッシュコントロールはHTTPのような応答についてキャッシュを治めるのではなく、むしろSETUP要求で特定されたストリームについて治めます。 DESCRIBEへの応答以外に、RTSP要求への応答は「キャッシュ-可能」ではありません。
Cache-Control = "Cache-Control" ":" 1#cache-directive
cache-directive = cache-request-directive
| cache-response-directive
cache-request-directive = "no-cache"
| "max-stale"
| "min-fresh"
| "only-if-cached"
| cache-extension
cache-response-directive = "public"
| "private"
| "no-cache"
| "no-transform"
| "must-revalidate"
「キャッシュ制御は「キャッシュ制御」と等しい」:、」 1#キャッシュ指示のキャッシュ指示=キャッシュ要求指示| キャッシュ応答指示キャッシュ要求指示=「キャッシュがありません」| 「最大聞き古したです」。| 「分新鮮です」。| 「キャッシュされる場合にだけ」| キャッシュ拡大キャッシュ応答指示=「公衆」| 「個人的です」。| 「キャッシュがありません」| 「変形しないでください」| 「必須-revalidate」
Schulzrinne, et. al. Standards Track [Page 47] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[47ページ]RFC2326リアルタイム
| "proxy-revalidate"
| "max-age" "=" delta-seconds
| cache-extension
cache-extension = token [ "=" ( token | quoted-string ) ]
| 「プロキシ-revalidate」| 「最大時代」「=」デルタ秒| キャッシュ拡大キャッシュ拡大はトークンと等しいです。[「=」(トークン| 引用文字列)]
no-cache:
Indicates that the media stream 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.
以下をキャッシュしないでください。 どこでもメディアストリームをキャッシュしてはいけないのを示します。 これで、発生源サーバは、クライアント要求への聞き古した応答を返すために構成されたキャッシュでさえキャッシュするのを防ぐことができます。
public:
Indicates that the media stream is cacheable by any cache.
公衆: メディアストリームがどんなキャッシュでも「キャッシュ-可能」であることを示します。
private:
Indicates that the media stream is intended for a single user
and MUST NOT be cached by a shared cache. A private (non-
shared) cache may cache the media stream.
個人的: メディアストリームがシングルユーザーのために意図するのを示して、共有されたキャッシュによってキャッシュされてはいけません。 個人的な(非共有された)キャッシュはメディアストリームをキャッシュするかもしれません。
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 entity-body.
Therefore, if a response includes the no-transform directive,
an intermediate cache or proxy MUST NOT change the encoding of
the stream. Unlike HTTP, RTSP does not provide for partial
transformation at this point, e.g., allowing translation into
a different language.
変形しないでください: 中間的キャッシュ(プロキシ)によって、あるストリームのメディアタイプを変換するのが役に立つのがわかるかもしれません。 例えば、プロキシは、キャッシュスペースを節約するか、または遅いリンクでトラフィックの量を減少させるためにビデオ形式の間で変換するかもしれません。 しかしながら、これらの変換が、ある種類のアプリケーションのために意図するストリームに適用されたとき、重大な運転上の問題は起こるかもしれません。 例えば、医療画像処理のアプリケーション、科学的データ分析、および終わりから終わりへの認証を使用するものがビットのために噛み付かれるストリームを受けるのにオリジナルの実体本体と同じ状態ですべてよります。 したがって、応答が変換がない指示を含んでいるなら、中間的キャッシュかプロキシがストリームのコード化を変えてはいけません。 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 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 it
receives this directive, a cache SHOULD either respond using a
cached media stream 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.
キャッシュされる場合にだけ: 非常に不十分なネットワークの接続性の倍などのいくつかの場合では、クライアントは、キャッシュにそれが現在保存したストリームをそれらのメディアだけに返して、発生源サーバからこれらを受けないで欲しいかもしれません。これをするために、クライアントは要求における唯一の、しかし、キャッシュされた指示を入れるかもしれません。 この指示を受けるなら、キャッシュSHOULDは要求の他の規制と一致したキャッシュされたメディアストリームを使用することで応じるか、または504(ゲートウェイTimeout)状態で応じます。 しかしながら、統一されたシステムとして良い内部の接続性でキャッシュのグループを経営しているなら、キャッシュのそのグループの中でそのような要求を転送するかもしれません。
Schulzrinne, et. al. Standards Track [Page 48] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[48ページ]RFC2326リアルタイム
max-stale:
Indicates that the client is willing to accept a media stream
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.
最大聞き古した: クライアントが、満了時間を超えていたメディアストリームを受け入れても構わないと思っているのを示します。 最大聞き古したである、割り当てられたa値、クライアントが指定された数だけに応じてそれが持っている応答を受け入れるのが満了時間を超えていたことを望んでいるその時は秒ですか? 値が全く最大に古くさくなるように割り当てられないなら、クライアントは、どんな時代の聞き古した応答も受け入れても構わないと思っています。
min-fresh:
Indicates that the client is willing to accept a media stream
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
entry after it becomes stale to respond to a subsequent
request without first revalidating it with the origin server.
That is, the cache must do an end-to-end revalidation every
time, if, based solely on the origin server's Expires, the
cached response is stale.)
必須-revalidate: 必須-revalidate指示であるときに、唯一発生源サーバのExpiresに基づいて、キャッシュされた応答が. すなわち、キャッシュが毎回終わりから終わりへの再合法化をしなければならない発生源サーバ、聞き古したである、キャッシュ、そのキャッシュで受け取られていているSETUP応答が最初に再有効にしないでその後の要求に反応するのに聞き古したであるなった後にエントリーを使用してはいけない現在のコネはそれですか?)
12.9 Conference
12.9 コンファレンス
This request header field establishes a logical connection between a pre-established conference and an RTSP stream. The conference-id must not be changed for the same RTSP session.
この要求ヘッダーフィールドはプレ設立された会議とRTSPストリームとの論理的な関係を確立します。 同じRTSPセッションのために会議イドを変えてはいけません。
Conference = "Conference" ":" conference-id Example:
Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
「コンファレンス=「コンファレンス」」:、」 会議イドExample: コンファレンス: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
A response code of 452 (452 Conference Not Found) is returned if the conference-id is not valid.
会議イドが有効でないなら、452(452コンファレンスNot Found)の応答コードは返されます。
12.10 Connection
12.10 接続
See [H14.10]
見てください。[H14.10]
12.11 Content-Base
12.11 満足している基地
See [H14.11]
見てください。[H14.11]
12.12 Content-Encoding
12.12 内容コード化
See [H14.12]
見てください。[H14.12]
Schulzrinne, et. al. Standards Track [Page 49] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[49ページ]RFC2326リアルタイム
12.13 Content-Language
12.13 満足している言語
See [H14.13]
見てください。[H14.13]
12.14 Content-Length
12.14 コンテンツの長さ
This field contains the length of the content of the method (i.e. after the double CRLF following the last header). Unlike HTTP, it MUST be included in all messages that carry content beyond the header portion of the message. If it is missing, a default value of zero is assumed. It is interpreted according to [H14.14].
この分野はメソッド(すなわち、最後のヘッダーに続く二重CRLFの後の)の内容の長さを含んでいます。 HTTPと異なって、メッセージのヘッダー部分まで内容を運ぶすべてのメッセージにそれを含まなければなりません。 それがなくなるなら、ゼロのデフォルト値は想定されます。 [H14.14]に従って、それは解釈されます。
12.15 Content-Location
12.15 満足している位置
See [H14.15]
見てください。[H14.15]
12.16 Content-Type
12.16 コンテントタイプ
See [H14.18]. Note that the content types suitable for RTSP are likely to be restricted in practice to presentation descriptions and parameter-value types.
[H14.18]を見てください。 RTSPに適当なcontent typeが実際にはプレゼンテーション記述とパラメタ価値のタイプに制限されそうに注意してください。
12.17 CSeq
12.17 CSeq
The CSeq field specifies the sequence number for an RTSP request- response pair. This field MUST be present in all requests and responses. For every RTSP request containing the given sequence number, there will be a corresponding response having the same number. 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).
CSeq分野は応答が対にするRTSP要求に一連番号を指定します。 この分野はすべての要求と応答で存在していなければなりません。 与えられた一連番号を含むあらゆるRTSP要求のために、同じ数を持っている対応する応答があるでしょう。 どんな再送された要求もオリジナルと同じ一連番号を含まなければなりません(すなわち、一連番号は同じ要求の「再-トランスミッション」のために増加されません)。
12.18 Date
12.18 日付
See [H14.19].
[H14.19]を見てください。
12.19 Expires
12.19は期限が切れます。
The Expires entity-header field gives a date and time after which the description or media-stream should be considered stale. The interpretation depends on the method:
Expires実体ヘッダーフィールドは記述かメディアストリームが聞き古したである考えられるべきである日時を与えます。 解釈はメソッドによります:
DESCRIBE response:
The Expires header indicates a date and time after which the
description should be considered stale.
DESCRIBE応答: Expiresヘッダーは記述が聞き古したである考えられるべきである日時を示します。
Schulzrinne, et. al. Standards Track [Page 50] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[50ページ]RFC2326リアルタイム
A stale cache entry may not normally be returned by a cache (either a proxy cache or an user agent cache) unless it is first validated with the origin server (or with an intermediate cache that has a fresh copy of the entity). See section 13 for further discussion of the expiration model.
それが最初に発生源サーバ(または実体の新鮮なコピーを持っている中間的キャッシュで)で有効にされない場合、キャッシュ(プロキシキャッシュかユーザエージェントキャッシュのどちらか)によって通常、聞き古したキャッシュエントリーは返されないかもしれません。 満了モデルのさらなる議論に関してセクション13を見てください。
The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time.
Expires分野の存在は、オリジナルのリソースが変化するのを含意もしませんし、その時の前かその時か、その時以降存在するのをやめもしません。
The format is an absolute date and time as defined by HTTP-date in [H3.3]; it MUST be in RFC1123-date format:
形式は[H3.3]のHTTP日付までに定義されるように絶対日時です。 RFC1123-日付の形式にはそれがあるに違いありません:
Expires = "Expires" ":" HTTP-date
「=「期限が切れること」を吐き出す」:、」 HTTP日付
An example of its use is
使用に関する例はそうです。
Expires: Thu, 01 Dec 1994 16:00:00 GMT
期限が切れます: グリニッジ標準時1994年12月1日木曜日16時0分0秒
RTSP/1.0 clients and caches MUST treat other invalid date formats, especially including the value "0", as having occurred in the past (i.e., "already expired").
RTSP/1.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/1.0 servers should not send Expires dates more than one year in the future.
「既に吐き出されます」のように応答をマークするために、発生源サーバはDateヘッダー価値と等しいExpires期日を使用するべきです。 「決して期限が切れない」で応答をマークするために、発生源サーバは応答が送られる時からのExpiresおよそ1年日付を使用するべきです。 RTSP/1.0サーバは将来、1年以上日付をExpiresに送るべきではありません。
The presence of an Expires header field with a date value of some time in the future on a media stream that otherwise would by default be non-cacheable indicates that the media stream is cacheable, unless indicated otherwise by a Cache-Control header field (Section 12.8).
将来いつかの日付の値がそうでなければ、デフォルトで非「キャッシュ-可能」であるメディアストリームにあるExpiresヘッダーフィールドの存在は、メディアストリームが「キャッシュ-可能」であることを示します、Cache-コントロールヘッダーフィールド(セクション12.8)によって別の方法で示されない場合。
12.20 From
12.20
See [H14.22].
[H14.22]を見てください。
12.21 Host
12.21 ホスト
This HTTP request header field is not needed for RTSP. It should be silently ignored if sent.
このHTTP要求ヘッダーフィールドはRTSPに必要ではありません。 送るなら、静かにそれを無視するべきです。
12.22 If-Match
12.22、-合ってください。
See [H14.25].
[H14.25]を見てください。
Schulzrinne, et. al. Standards Track [Page 51] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[51ページ]RFC2326リアルタイム
This field is especially useful for ensuring the integrity of the presentation description, in both the case where it is fetched via means external to RTSP (such as HTTP), or in the case where the server implementation is guaranteeing the integrity of the description between the time of the DESCRIBE message and the SETUP message.
この分野は特にそれがRTSP(HTTPなどの)への外部の手段でとって来られるケースを両方のプレゼンテーション記述の保全に確実にするか、またはサーバ実装がそうである場合でDESCRIBEメッセージの時間とSETUPメッセージの間の記述の保全を保証することの役に立ちます。
The identifier is an opaque identifier, and thus is not specific to any particular session description language.
識別子は、不明瞭な識別子であり、その結果、どんな特定のセッション記述言語にも特定ではありません。
12.23 If-Modified-Since
12.23、以来、変更されます。
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 will be returned without any message-body.
以来変更されたIf要求ヘッダーフィールドはDESCRIBEとそれらを条件付きにするSETUPメソッドで使用されます。 時間がこの分野で指定して以来要求された異形が変更されていないと、記述がサーバ(DESCRIBE)から返されないだろうか、またはストリームはセットアップされないでしょう(SETUP)。 代わりに、少しもメッセージ本体なしで304(変更されない)応答を返すでしょう。
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
「= 以来変更されるなら「以来変更されるなら」」:、」 HTTP日付
An example of the field is:
分野に関する例は以下の通りです。
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
以来変更されるなら: グリニッジ標準時1994年10月29日土曜日19時43分31秒
12.24 Last-Modified
12.24 最終更新日
The Last-Modified entity-header field indicates the date and time at which the origin server believes the presentation description or media stream was last modified. See [H14.29]. For the methods DESCRIBE or ANNOUNCE, the header field indicates the last modification date and time of the description, for SETUP that of the media stream.
最終更新日実体ヘッダーフィールドは、発生源サーバがプレゼンテーション記述かメディアストリームを信じている日時が最後に変更されたのを示します。 [H14.29]を見てください。 メソッドDESCRIBEかANNOUNCEに関しては、ヘッダーフィールドはSETUPのための記述の最後の変更日時にメディアストリームのものを示します。
12.25 Location
12.25 位置
See [H14.30].
[H14.30]を見てください。
12.26 Proxy-Authenticate
12.26はプロキシで認証します。
See [H14.33].
[H14.33]を見てください。
12.27 Proxy-Require
12.27がプロキシで必要です。
The Proxy-Require header 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 if not supported. Servers
ヘッダーをProxy必要としてください、プロキシがサポートしなければならないプロキシ機密の特徴を示すには、使用されます。 いずれもプロキシによってサポートされないで、クライアントのプロキシによって否定的に承認されるか、またはサポートしなければならないということであるヘッダーの特徴をProxy必要とします。 サーバ
Schulzrinne, et. al. Standards Track [Page 52] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[52ページ]RFC2326リアルタイム
should treat this field identically to the Require field.
同様にRequire分野にこの分野を扱うべきです。
See Section 12.32 for more details on the mechanics of this message and a usage example.
このメッセージと使用例の整備士に関するその他の詳細に関してセクション12.32を見てください。
12.28 Public
12.28 公衆
See [H14.35].
[H14.35]を見てください。
12.29 Range
12.29 範囲
This request and response header field specifies a range of time. The range can be specified in a number of units. This specification defines the smpte (Section 3.5), npt (Section 3.6), and clock (Section 3.7) range units. Within RTSP, byte ranges [H14.36.1] are not meaningful and MUST NOT be used. The header may also contain a time parameter in UTC, specifying the time at which the operation is to be made effective. Servers supporting the Range header MUST understand the NPT range format and SHOULD understand the SMPTE range format. The Range response header indicates what range of time is actually being played or recorded. If the Range header is given in a time format that is not understood, the recipient should return "501 Not Implemented".
この要求と応答ヘッダーフィールドはさまざまな時間、指定します。 多くのユニットで範囲を指定できます。 この仕様はsmpte(セクション3.5)、npt(セクション3.6)、および時計(セクション3.7)レンジ・ユニットを定義します。 RTSPの中では、バイト範囲[H14.36.1]は、重要でなく、使用されてはいけません。 また、ヘッダーはUTCに時間パラメタを含むかもしれません、有効に作られる操作がことである時を指定して。 Rangeヘッダーを支えるサーバは、NPT範囲の形式とSHOULDがSMPTE範囲形式を理解しているのを理解しなければなりません。 Range応答ヘッダは、どんな範囲の時間が実際にプレーされるか、または記録されているかを示します。 理解されていない時間形式でRangeヘッダーを与えるなら、受取人は「実装されなかった501」を返すべきです。
Ranges are half-open intervals, including the lower point, but excluding the upper point. In other words, a range of a-b starts exactly at time a, but stops just before b. Only the start time of a media unit such as a video or audio frame is relevant. As an 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原稿A範囲が10.0- 10.1にフレームに生成されるビデオが10.0以降時に始動するビデオフレームを含んでいて、10.08で始動するビデオフレームを含んでいると仮定してください、間隔に持続しましたが。 他方では、10.0-10.08の範囲は10.08でフレームを除くでしょう。
Range = "Range" ":" 1\#ranges-specifier
[ ";" "time" "=" utc-time ]
ranges-specifier = npt-range | utc-range | smpte-range
「範囲=「範囲」」:、」 1円#の範囲特許説明書の作成書、[「」、;「時間」がutc時間] 範囲特許説明書の作成書=npt-範囲と「等しい」 | utc-範囲| smpte-範囲
Example:
Range: clock=19960213T143205Z-;time=19970123T143720Z
例: 範囲: =19960213T143205Zの時間を計ってください、-、;時間が19970123T143720Zと等しい
The notation is similar to that used for the HTTP/1.1 [2] byte-
range header. It allows clients to select an excerpt from the media
object, and to play from a given point to the end as well as from
the current location to a given point. The start of playback can be
scheduled for any time in the future, although a server may refuse
to keep server resources for extended idle periods.
記法はHTTP/1.1[2]バイト範囲ヘッダーに使用されるそれと同様です。 それで、クライアントは、メディアオブジェクトから抜粋を選択して、与えられたポイントから終わりまで現在の位置から与えられたポイントまでプレーします。 将来いつでもように再生の始まりを予定できます、サーバは、延ばされた活動していない期間、サーバリソースを保つのを拒否するかもしれませんが。
Schulzrinne, et. al. Standards Track [Page 53] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[53ページ]RFC2326リアルタイム
12.30 Referer
12.30 Referer
See [H14.37]. The URL refers to that of the presentation description, typically retrieved via HTTP.
[H14.37]を見てください。 URLはHTTPで通常検索されたプレゼンテーション記述のものについて言及します。
12.31 Retry-After
12.31 再試行します。
See [H14.38].
[H14.38]を見てください。
12.32 Require
12.32が必要です。
The Require header is used by clients to query the server about options that it may or may not support. The server MUST respond to this header by using the Unsupported header to negatively acknowledge those options which are NOT supported.
Requireヘッダーは、それがサポートするか、またはサポートしないかもしれないオプションに関するサーバについて質問するのにクライアントによって使用されます。 サーバは、否定的にサポートされないそれらのオプションを承諾するのにUnsupportedヘッダーを使用することによって、このヘッダーに反応しなければなりません。
This is to make sure that the client-server interaction will
proceed without delay when all options are understood by both
sides, and only slow down if options are not understood (as in the
case above). 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.
オプションが理解されていない場合にだけ(上のケースのように)、これは、すべてのオプションが両側に解釈されるとき、クライアント/サーバ相互作用が即刻続くのを確実にして、減速することになっています。 よく取り組んでいるクライアント/サーバ組のために、相互作用は急速に続きます、節約a往復です。クライアントがサーバが理解していない特徴を必要とするとき、交渉メカニズムIn追加がしばしば必要であることで、また、それは州のあいまいさを取り除きます。
Require = "Require" ":" 1#option-tag
「=「必要」を必要としてください」:、」 1#オプションタグ
Example:
C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
CSeq: 302
Require: funky-feature
Funky-Parameter: funkystuff
例: C>S: SETUP rtsp://server.com/foo/バー/baz.rm RTSP/1.0CSeq: 302 必要です: 風変りな特徴Funky-パラメタ: funkystuff
S->C: RTSP/1.0 551 Option not supported
CSeq: 302
Unsupported: funky-feature
S>C: RTSP/1.0 551OptionはCSeqをサポートしませんでした: 302 サポートされない: 風変りな特徴
C->S: SETUP rtsp://server.com/foo/bar/baz.rm RTSP/1.0
CSeq: 303
C>S: SETUP rtsp://server.com/foo/バー/baz.rm RTSP/1.0CSeq: 303
S->C: RTSP/1.0 200 OK
CSeq: 303
S>C: RTSP/1.0 200はCSeqを承認します: 303
In this example, "funky-feature" is the feature tag which 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-パラメタ分野が必要であることをクライアントに示す特徴タグです。 「風変りな特徴」とFunky-パラメタとの関係はRTSP交換で伝えられません、その関係を「風変りな特徴」の不変の特性であり、その結果、あらゆる交換のときに伝えるべきであるというわけではありません。
Schulzrinne, et. al. Standards Track [Page 54] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[54ページ]RFC2326リアルタイム
Proxies and other intermediary devices SHOULD ignore features that are not understood in this field. If a particular extension requires that intermediate devices support it, the extension should be tagged in the Proxy-Require field instead (see Section 12.27).
プロキシと他の仲介者デバイスSHOULDはこの分野で理解されていない特徴を無視します。 特定の拡張子が、中間的デバイスがそれをサポートするのを必要とするなら、拡大が中でタグ付けをされるべきである、代わりに分野をProxy必要としてください(セクション12.27を見てください)。
12.33 RTP-Info
12.33 RTP-インフォメーション
This field is used to set RTP-specific parameters in the PLAY response.
この分野は、RTP特有のパラメタをPLAY応答にはめ込むのに使用されます。
url:
Indicates the stream URL which for which the following RTP
parameters correspond.
url: ストリームURLを示す、どれ、以下のRTPパラメタが対応する。
seq:
Indicates the sequence number of the first packet of the
stream. 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.
seq: ストリームの最初のパケットの一連番号を示します。 探すとき、これで、クライアントは優雅にパケットに対処できます。 クライアントは、シークの後に起因したパケットとシークの前に起因したパケットを区別するのにこの値を使用します。
rtptime:
Indicates the RTP timestamp corresponding to the time value in
the Range response header. (Note: For aggregate control, a
particular stream may not actually generate a packet for the
Range time value returned or implied. Thus, there is no
guarantee that the packet with the sequence number indicated
by seq actually has the timestamp indicated by rtptime.) The
client uses this value to calculate the mapping of RTP time to
NPT.
rtptime: Range応答ヘッダで時間的価値に対応するRTPタイムスタンプを示します。 (以下に注意してください。 集合コントロールのために、特定のストリームは実際に返すか、または含意するRange時間的価値のためのパケットを生成しないかもしれません。 したがって、一連番号がseqによって示されているパケットにはrtptimeによって示されたタイムスタンプが実際にあるという保証が全くありません。) クライアントは、RTP時間に関するマッピングについてNPTに計算するのにこの値を使用します。
A mapping from RTP timestamps to NTP timestamps (wall clock) is
available via RTCP. However, this information is not sufficient to
generate a mapping from RTP timestamps to NPT. Furthermore, in
order to ensure that this information is available at the necessary
time (immediately at startup or after a seek), and that it is
delivered reliably, this mapping is placed in the RTSP control
channel.
RTPタイムスタンプからNTPタイムスタンプ(柱時計)までのマッピングはRTCPを通して利用可能です。 しかしながら、この情報は、RTPタイムスタンプからNPTまでマッピングを生成するために十分ではありません。 その上、この情報が必要な時(始動すぐにおけるシークの後の)に利用可能であり、それが確かに提供されるのを確実にするために、このマッピングはRTSP制御チャンネルに置かれます。
In order to compensate for drift for long, uninterrupted
presentations, RTSP clients should additionally map NPT to NTP,
using initial RTCP sender reports to do the mapping, and later
reports to check drift against the mapping.
長くて、とぎれないプレゼンテーションのためにドリフトを補って、RTSPクライアントは、マッピングに対してドリフトをチェックするためにさらに、NTP、初期のRTCPを使用して、送付者がマッピングをすると報告するおよび後のレポートにNPTを写像するべきです。
Schulzrinne, et. al. Standards Track [Page 55] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[55ページ]RFC2326リアルタイム
Syntax:
構文:
RTP-Info = "RTP-Info" ":" 1#stream-url 1*parameter
stream-url = "url" "=" url
parameter = ";" "seq" "=" 1*DIGIT
| ";" "rtptime" "=" 1*DIGIT
「RTP-インフォメーションは「RTP-インフォメーション」と等しい」:、」 「url1*パラメタストリーム-url="url"がurlパラメタと「等しい」という1#ストリーム=」;、」 "seq"は1*ケタと「等しいです」。| ";" "rtptime"は1*ケタと「等しいです」。
Example:
例:
RTP-Info: url=rtsp://foo.com/bar.avi/streamid=0;seq=45102,
url=rtsp://foo.com/bar.avi/streamid=1;seq=30211
RTP-インフォメーション: url=rtsp://foo.com/bar.avi/streamid=0; seq=45102、url=rtsp://foo.com/bar.avi/streamid=1; seq=30211
12.34 Scale
12.34 スケール
A scale value of 1 indicates normal play or record at the normal
forward viewing rate. If not 1, the value corresponds to the rate
with respect to normal viewing rate. For example, a ratio of 2
indicates twice the normal viewing rate ("fast forward") and a ratio
of 0.5 indicates half the normal viewing rate. In other words, a
ratio of 2 has normal play time increase at twice the wallclock rate.
For every second of elapsed (wallclock) time, 2 seconds of content
will be delivered. A negative value indicates reverse direction.
1のスケール値は標準の前進の視聴率で正常なプレーか記録を示します。 1でないなら、値は標準の視聴率に関してレートに対応しています。 例えば、2の比率は、二度標準の視聴率(「早送りする」)と0.5の比率が標準の視聴率の半分を示すのを示します。 言い換えれば、2の比率で、正常なプレー時間はwallclockレートの2倍で増加します。 経過した(wallclock)時間のあらゆる2番目において、2秒の内容は提供されるでしょう。 負の数は反対の方向を示します。
Unless requested otherwise by the Speed parameter, the data rate SHOULD not be changed. Implementation of scale changes depends on the server and media type. For video, a server may, for example, deliver only key frames or selected key frames. For audio, it may time-scale the audio while preserving pitch or, less desirably, deliver fragments of audio.
Speedパラメタ、データ信号速度SHOULDでそうでない状態で要求されない場合、変えられないでください。 スケール変化の実装はサーバによります、そして、メディアはタイプされます。 ビデオに関しては、例えば、サーバは主要なフレームか選択された主要なフレームだけを提供するかもしれません。 オーディオのために、それは、ピッチを保存している間、オーディオを時スケーリングするか、またはそれほど好ましくなくオーディオの断片を提供しないかもしれません。
The server should try to approximate the viewing rate, but may restrict the range of scale values that it supports. The response MUST contain the actual scale value chosen by the server.
サーバは、視聴率に近似しようとするべきですが、それがサポートするスケール値の範囲を制限するかもしれません。 応答はサーバによって選ばれた実際のスケール値を含まなければなりません。
If the request contains a Range parameter, the new scale value will take effect at that time.
要求がRangeパラメタを含んでいると、新しいスケール値はその時、実施するでしょう。
Scale = "Scale" ":" [ "-" ] 1*DIGIT [ "." *DIGIT ]
「スケール=「スケール」」:、」 [「-」]1*ケタ[「. 」 *ケタ、]
Example of playing in reverse at 3.5 times normal rate:
3.5回の標準の速度で逆でありプレーする例:
Scale: -3.5
以下をスケーリングしてください。 -3.5
Schulzrinne, et. al. Standards Track [Page 56] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[56ページ]RFC2326リアルタイム
12.35 Speed
12.35速度
This request header fields parameter requests the server to deliver data to the client at a particular speed, contingent on the server's ability and desire to serve the media stream at the given speed. Implementation by the server is OPTIONAL. The default is the bit rate of the stream.
この要求ヘッダーフィールドパラメタは、特定の速度でデータをクライアントに提供するようサーバに要求します、サーバの能力と与えられた速度でメディアストリームに役立つ願望次第で。 サーバによる実装はOPTIONALです。 デフォルトはストリームのビット伝送速度です。
The parameter value is expressed as a decimal ratio, e.g., a value of 2.0 indicates that data is to be delivered twice as fast as normal. A speed of zero is invalid. If the request contains a Range parameter, the new speed value will take effect at that time.
2.0の値が、データが標準の2倍速く提供されることであることを10進比率に、例えば示すとき、パラメタ値は言い表されます。 ゼロの速度は無効です。 要求がRangeパラメタを含んでいると、新しい速度値はその時、実施するでしょう。
Speed = "Speed" ":" 1*DIGIT [ "." *DIGIT ]
「速度は「速度」と等しい」:、」 1*ケタ[「. 」 *ケタ、]
Example:
Speed: 2.5
例: 速度: 2.5
Use of this field changes the bandwidth used for data delivery. It is meant for use in specific circumstances where preview of the presentation at a higher or lower rate is necessary. Implementors should keep in mind that bandwidth for the session may be negotiated beforehand (by means other than RTSP), and therefore re-negotiation may be necessary. When data is delivered over UDP, it is highly recommended that means such as RTCP be used to track packet loss rates.
この分野の使用はデータ配送に使用される帯域幅を変えます。 それは、より高いか低いレートでのプレゼンテーションのプレビューが必要である特定の事情における使用のために意味されます。 作成者は、セッションのための帯域幅があらかじめ(RTSP以外の手段で)交渉されるかもしれないのを覚えておくべきです、そして、したがって、再交渉が必要であるかもしれません。 データがUDPの上に提供されるとき、RTCPなどの手段がパケット損失率を追跡するのに使用されるのは、非常にお勧めです。
12.36 Server
12.36 サーバ
See [H14.39]
見てください。[H14.39]
12.37 Session
12.37 セッション
This request and response header field identifies an RTSP session started by the media server in a SETUP response and concluded by TEARDOWN on the presentation URL. The session identifier is chosen by the media server (see Section 3.4). Once a client receives a Session identifier, it MUST return it for any request related to that session. A server does not have to set up a session identifier if it has other means of identifying a session, such as dynamically generated URLs.
この要求と応答ヘッダーフィールドはSETUP応答におけるメディアサーバによって始められて、プレゼンテーションURLのTEARDOWNによって結論づけられたRTSPセッションを特定します。 セッション識別子はメディアサーバによって選ばれています(セクション3.4を見てください)。 クライアントがいったんSession識別子を受け取ると、それはそのセッションのときに関連したどんな要求のためにもそれを返さなければなりません。 それにセッションを特定する他の手段があるなら、サーバはセッション識別子をセットアップする必要はありません、URLであるとダイナミックに生成されるように。
Session = "Session" ":" session-id [ ";" "timeout" "=" delta-seconds ]
「セッション=「セッション」」:、」 セッションイド[「」、;、「タイムアウト」「=」デルタ秒]
The timeout parameter is only allowed in a response header. The server uses it to indicate to the client how long the server is prepared to wait between RTSP commands before closing the session due to lack of activity (see Section A). The timeout is measured in
タイムアウトパラメタは応答ヘッダに許容されているだけです。 サーバは、サーバがどれくらい長い間活動の不足によるセッションを終える前にRTSPコマンドの間で待つように準備されるかを(セクションAを見てください)クライアントに示すのにそれを使用します。 タイムアウトでは、測定されます。
Schulzrinne, et. al. Standards Track [Page 57] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[57ページ]RFC2326リアルタイム
seconds, with a default of 60 seconds (1 minute).
60秒(1分)のデフォルトがある秒。
Note that a session identifier identifies a RTSP session across transport sessions or connections. Control messages for more than one RTSP URL may be sent within a single RTSP session. Hence, it is possible that clients use the same session for controlling many streams constituting a presentation, as long as all the streams come from the same server. (See example in Section 14). However, multiple "user" sessions for the same URL from the same client MUST use different session identifiers.
セッション識別子が輸送セッションか接続の向こう側にRTSPセッションを特定することに注意してください。 ただ一つのRTSPセッション以内に1RTSP URLへのコントロールメッセージを送るかもしれません。 したがって、クライアントがプレゼンテーションを構成しながら多くのストリームを制御するのに同じセッションを使用するのは、可能です、すべての小川が同じサーバから来る限り。. (セクション14で例を見ます。) しかしながら、同じクライアントからの同じURLのための複数の「ユーザ」セッションは異なったセッション識別子を使用しなければなりません。
The session identifier is needed to distinguish several delivery
requests for the same URL coming from the same client.
セッション識別子が、同じクライアントから来る同じURLを求めるいくつかの配送要求を区別するのに必要です。
The response 454 (Session Not Found) is returned if the session identifier is invalid.
セッション識別子が無効であるなら、応答454(セッションNot Found)を返します。
12.38 Timestamp
12.38 タイムスタンプ
The timestamp general header describes when the client sent the request to the server. The value of the timestamp is of significance only to the client and may use any timescale. The server MUST echo the exact same value and MAY, if it has accurate information about this, add a floating point number indicating the number of seconds that has elapsed since it has received the request. The timestamp is used by the client to compute the round-trip time to the server so that it can adjust the timeout value for retransmissions.
タイムスタンプの一般的なヘッダーは、クライアントがいつ要求をサーバに送ったかを説明します。タイムスタンプの値は、クライアントだけには意味があって、どんなスケールも使用するかもしれません。 サーバは、全く同じ値を反響しなければならなくて、それにこれに関する的確な情報があるなら、要求を受け取って以来経過している秒数を示す浮動小数点を加えるかもしれません。 タイムスタンプは、「再-トランスミッション」のためにタイムアウト値を調整できるように往復の時間をサーバに計算するのにクライアントによって使用されます。
Timestamp = "Timestamp" ":" *(DIGIT) [ "." *(DIGIT) ] [ delay ] delay = *(DIGIT) [ "." *(DIGIT) ]
「タイムスタンプ=「タイムスタンプ」」:、」 *(ケタ) [「. 」 *(ケタ][遅れ]遅れは*(ケタ)と等しいです。[「. 」 *(ケタ]
12.39 Transport
12.39 輸送
This request header indicates which transport protocol is to be used and configures its parameters such as destination address, compression, multicast time-to-live and destination port for a single stream. It sets those values not already determined by a presentation description.
この要求ヘッダーは、使用されるためにトランスポート・プロトコルがどれであるかを示して、ただ一つのストリームのために送付先アドレスや、圧縮や、住むマルチキャスト時間や仕向港などのパラメタを構成します。 それはプレゼンテーション記述で既に決定しなかったそれらの値を設定します。
Transports are comma separated, listed in order of preference. Parameters may be added to each transport, separated by a semicolon.
輸送は好みの順に切り離されて、記載されたコンマです。 パラメタはセミコロンによって切り離された各輸送に加えられるかもしれません。
The Transport header MAY also be used to change certain transport parameters. A server MAY refuse to change parameters of an existing stream.
また、Transportヘッダーは、ある輸送パラメタを変えるのに使用されるかもしれません。 サーバは、既存のストリームのパラメタを変えるのを拒否するかもしれません。
The server MAY return a Transport response header in the response to indicate the values actually chosen.
サーバは、実際に選ばれた値を示すために応答でTransport応答ヘッダを返すかもしれません。
Schulzrinne, et. al. Standards Track [Page 58] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[58ページ]RFC2326リアルタイム
A Transport request header field may contain a list of transport options acceptable to the client. In that case, the server MUST return a single option which was actually chosen.
Transport要求ヘッダーフィールドはクライアントにとって、許容できる輸送オプションのリストを含むかもしれません。 その場合、サーバは実際に選ばれたただ一つのオプションを返さなければなりません。
The syntax for the transport specifier is
輸送特許説明書の作成書のための構文はそうです。
transport/profile/lower-transport.
下側の輸送/プロフィール/輸送。
The default value for the "lower-transport" parameters is specific to the profile. For RTP/AVP, the default is UDP.
「下側の輸送」パラメタのためのデフォルト値はプロフィールに特定です。 RTP/AVPに関しては、デフォルトはUDPです。
Below are the configuration parameters associated with transport:
以下に、輸送に関連している設定パラメータがあります:
General parameters:
一般的指標:
unicast | multicast:
mutually exclusive indication of whether unicast or multicast
delivery will be attempted. Default value is multicast.
Clients that are capable of handling both unicast and
multicast transmission MUST indicate such capability by
including two full transport-specs with separate parameters
for each.
ユニキャスト| マルチキャスト: ユニキャストかマルチキャスト配送が試みられるかどうか互いに排他的なしるし。 デフォルト値はマルチキャストです。 ユニキャストとマルチキャスト送信の両方を扱うことができるクライアントは、それぞれのための別々のパラメタで2つの完全な輸送仕様を含んでいることによって、そのような能力を示さなければなりません。
destination:
The address to which a stream will be sent. The client may
specify the multicast address with the destination parameter.
To avoid becoming the unwitting perpetrator of a remote-
controlled denial-of-service attack, a server SHOULD
authenticate the client and SHOULD log such attempts before
allowing the client to direct a media stream to an address not
chosen by the server. This is particularly important if RTSP
commands are issued via UDP, but implementations cannot rely
on TCP as reliable means of client identification by itself. A
server SHOULD not allow a client to direct media streams to an
address that differs from the address commands are coming
from.
目的地: 小川が送られるアドレス。 クライアントは目的地パラメタでマルチキャストアドレスを指定するかもしれません。 リモート制御サービス不能攻撃、サーバの知らず知らずの加害者になるのを避けるために、SHOULDはそのようなものがクライアントがサーバによって選ばれなかったアドレスにメディアストリームを向けるのを許容する前に試みるクライアントとSHOULDログを認証します。UDPを通してRTSPコマンドを発行するなら、これは特に重要ですが、実装自体はクライアント識別の信頼できる手段としてTCPを当てにすることができません。 SHOULDがメディアをクライアントを指示させないサーバはコマンドが来るアドレスと異なっているアドレスに流れます。
source:
If the source address for the stream is different than can be
derived from the RTSP endpoint address (the server in playback
or the client in recording), the source MAY be specified.
ソース: ストリームのためのソースアドレスがRTSP終点アドレス(再生のサーバか録音におけるクライアント)から派生できるより異なるなら、ソースは指定されるかもしれません。
This information may also be available through SDP. However, since
this is more a feature of transport than media initialization, the
authoritative source for this information should be in the SETUP
response.
また、この情報もSDPを通して利用可能であるかもしれません。 しかしながら、これがメディア初期化より輸送の特徴であるので、この情報のための権威筋はSETUP応答中であるはずです。
Schulzrinne, et. al. Standards Track [Page 59] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[59ページ]RFC2326リアルタイム
layers:
The number of multicast layers to be used for this media
stream. The layers are sent to consecutive addresses starting
at the destination address.
層: マルチキャストの数は、このメディアストリームに使用されるために層にされます。 送付先アドレスで始まる連続したアドレスに層を送ります。
mode:
The mode parameter indicates the methods to be supported for
this session. Valid values are PLAY and RECORD. If not
provided, the default is PLAY.
モード: モードパラメタはこのセッションのためにサポートするべきメソッドを示します。 有効値は、PLAYとRECORDです。 提供されないなら、デフォルトはPLAYです。
append:
If the mode parameter includes RECORD, the append parameter
indicates that the media data should append to the existing
resource rather than overwrite it. If appending is requested
and the server does not support this, it MUST refuse the
request rather than overwrite the resource identified by the
URI. The append parameter is ignored if the mode parameter
does not contain RECORD.
追加します: パラメタを追加してください。モードパラメタがRECORDを含んでいるなら示す、メディアデータが上書きするよりむしろ存在リソースにそれを追加するべきであるのを示します。 追加が要求されていて、サーバがこれをサポートしないなら、それはURIによって特定されたリソースを上書きするよりむしろ要求を拒否しなければなりません。 パラメタを追加してください。モードパラメタがRECORDを含んでいないなら、無視されます。
interleaved:
The interleaved parameter implies mixing the media stream with
the control stream in whatever protocol is being used by the
control stream, using the mechanism defined in Section 10.12.
The argument provides the channel number to be used in the $
statement. This parameter may be specified as a range, e.g.,
interleaved=4-5 in cases where the transport choice for the
media stream requires it.
はさみ込まれる: はさみ込まれたパラメタは、いかなるプロトコルにおける制御ストリームにもメディアストリームを混ぜるのが制御ストリームで使用されているのを含意します、セクション10.12で定義されたメカニズムを使用して。 議論は、$声明で使用されるために論理機番を提供します。 このパラメタは範囲(例えば、メディアストリームのための輸送選択がそれを必要とする場合におけるはさみ込まれた=4-5)として指定されるかもしれません。
This allows RTP/RTCP to be handled similarly to the way that it is
done with UDP, i.e., one channel for RTP and the other for RTCP.
これは、RTP/RTCPがRTCPのためのRTPともう片方のために同様にそれがすなわち、UDP、1個のチャンネルで行われる道に扱われるのを許容します。
Multicast specific:
マルチキャスト特有:
ttl:
multicast time-to-live
ttl: 生きるマルチキャスト時間
RTP Specific:
RTP特有:
port:
This parameter provides the RTP/RTCP port pair for a multicast
session. It is specified as a range, e.g., port=3456-3457.
ポート: このパラメタはマルチキャストセッションのためにRTP/RTCPポート組を提供します。 それは範囲として指定されます、例えば、ポートが3456-3457と等しいです。
client_port:
This parameter provides the unicast RTP/RTCP port pair on
which the client has chosen to receive media data and control
information. It is specified as a range, e.g.,
client_port=3456-3457.
クライアント_ポート: このパラメタはクライアントがメディアデータと制御情報を受け取るのを選んだユニキャストRTP/RTCPポート組を提供します。 それは範囲として指定されます、例えば、クライアント_ポートが3456-3457と等しいです。
Schulzrinne, et. al. Standards Track [Page 60] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[60ページ]RFC2326リアルタイム
server_port:
This parameter provides the unicast RTP/RTCP port pair on
which the server has chosen to receive media data and control
information. It is specified as a range, e.g.,
server_port=3456-3457.
サーバ_ポート: このパラメタはサーバがメディアデータと制御情報を受け取るのを選んだユニキャストRTP/RTCPポート組を提供します。 それは範囲として指定されます、例えば、サーバ_ポートが3456-3457と等しいです。
ssrc:
The ssrc parameter indicates the RTP SSRC [24, Sec. 3] value
that should be (request) or will be (response) used by the
media server. This parameter is only valid for unicast
transmission. It identifies the synchronization source to be
associated with the media stream.
ssrc: ssrcパラメタはRTP SSRCを示します。[24、秒 3] (要求)であるべきであるかメディアサーバによって使用される(応答)でしょう。ユニキャスト送信だけに、このパラメタが有効であることを評価してください。 それは、メディアストリームに関連しているように同期ソースを特定します。
Transport = "Transport" ":"
1\#transport-spec
transport-spec = transport-protocol/profile[/lower-transport]
*parameter
transport-protocol = "RTP"
profile = "AVP"
lower-transport = "TCP" | "UDP"
parameter = ( "unicast" | "multicast" )
| ";" "destination" [ "=" address ]
| ";" "interleaved" "=" channel [ "-" channel ]
| ";" "append"
| ";" "ttl" "=" ttl
| ";" "layers" "=" 1*DIGIT
| ";" "port" "=" port [ "-" port ]
| ";" "client_port" "=" port [ "-" port ]
| ";" "server_port" "=" port [ "-" port ]
| ";" "ssrc" "=" ssrc
| ";" "mode" = <"> 1\#mode <">
ttl = 1*3(DIGIT)
port = 1*5(DIGIT)
ssrc = 8*8(HEX)
channel = 1*3(DIGIT)
address = host
mode = <"> *Method <"> | Method
「輸送は「輸送」と等しい」:、」 "AVP"下側の"RTP"という1円#の輸送仕様輸送仕様=トランスポート・プロトコル/プロフィール[/下側の輸送]*パラメタトランスポート・プロトコル=プロフィール=輸送は"TCP"と等しいです。| "UDP"パラメタ=(「ユニキャスト」| 「マルチキャスト」)| ";" 「目的地」[アドレスと「等しいです」]| ";" 「はさみ込まれた」「=」チャンネル[「-」チャンネル]| ";" 「追加」| ";" "ttl"はttlと「等しいです」。| ";" 「層」は1*ケタと「等しいです」。| ";" 「ポート」はポート[「-」ポート]と「等しいです」。| ";" 「クライアント_ポート」はポート[「-」ポート]と「等しいです」。| ";" 「サーバ_ポート」はポート[「-」ポート]と「等しいです」。| ";" "ssrc"はssrcと「等しいです」。| ";" 「モード」が<と等しい、「>の1つの\#モードの<、「ホスト1*3(DIGIT)8*8(HEX)1*5(DIGIT)1*3(DIGIT)>ttl=ポート=ssrc=チャンネル=アドレス=モードが<と等しい、「>*メソッド<">"| メソッド
Example:
Transport: RTP/AVP;multicast;ttl=127;mode="PLAY",
RTP/AVP;unicast;client_port=3456-3457;mode="PLAY"
例: 輸送: RTP/AVP; RTP/AVP; ユニキャスト; クライアント_ポートは3456-3457と等しいです; マルチキャスト; ttl=127; モードは「プレー」と等しく、モードは「プレー」と等しいです。
The Transport header is restricted to describing a single RTP
stream. (RTSP can also control multiple streams as a single
entity.) Making it part of RTSP rather than relying on a multitude
of session description formats greatly simplifies designs of
firewalls.
Transportヘッダーはただ一つのRTPストリームについて説明するのに制限されます。 (また、RTSPは単一体として複数のストリームを制御できます。) それを作って、セッション記述形式の多数を当てにするよりむしろRTSPの一部がファイアウォールのデザインを大いに簡素化します。
Schulzrinne, et. al. Standards Track [Page 61] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[61ページ]RFC2326リアルタイム
12.40 Unsupported
12.40、サポートされなさ
The Unsupported response header lists the features not supported by the server. In the case where the feature was specified via the Proxy-Require field (Section 12.32), if there is a proxy on the path between the client and the server, the proxy MUST insert a message reply with an error message "551 Option Not Supported".
を通してUnsupported応答ヘッダが記載する、特徴が、サーバで. コネが特徴が指定されたケースであるとサポートしなかった、分野(セクション12.32)をProxy必要としてください、aプロキシがクライアントとサーバの間の経路にあればプロキシは「オプションがサポートしなかった551」というエラーメッセージでメッセージ回答を挿入しなければなりません。
See Section 12.32 for a usage example.
使用例に関してセクション12.32を見てください。
12.41 User-Agent
12.41 ユーザエージェント
See [H14.42]
見てください。[H14.42]
12.42 Vary
12.42は異なります。
See [H14.43]
見てください。[H14.43]
12.43 Via
を通して12.43。
See [H14.44].
[H14.44]を見てください。
12.44 WWW-Authentica
12.44 WWW-Authentica
See [H14.46].
[H14.46]を見てください。
13 Caching
13 キャッシュ
In HTTP, response-request pairs are cached. RTSP differs significantly in that respect. Responses are not cacheable, with the exception of the presentation description returned by DESCRIBE or included with ANNOUNCE. (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によって返されるか、またはANNOUNCEと共に含まれたプレゼンテーション記述以外に、応答は「キャッシュ-可能」ではありません。 (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 behavior allowed to the cache is given by the cache-response directives
SETUPかPLAY要求を受け取ると、プロキシは、それには連続したメディア内容とその記述の最新のコピーがあるかどうかを確かめます。 それは、コピーがそれぞれSETUPかDESCRIBE要求を出して、キャッシュされたコピーのものと最終更新日ヘッダーを比べることによって最新であるかどうか決定できます。 コピーが最新でないなら、それは、適宜SETUP輸送パラメタを変更して、発生源サーバに要求を転送します。次に、PLAYかPAUSEなどのその後の制御コマンドは変更されていなくプロキシを通過します。 プロキシは後の再利用のためにことによると地方のコピーを作っている間、クライアントへのデータを連続したメディアに提供します。 キャッシュ応答指示でキャッシュに許容された正確な振舞いを与えます。
Schulzrinne, et. al. Standards Track [Page 62] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[62ページ]RFC2326リアルタイム
described in Section 12.8. A cache MUST answer any DESCRIBE requests if it is currently serving the stream to the requestor, as it is possible that low-level details of the stream description may have changed on the origin-server.
セクション12.8では、説明されます。 現在要請者にストリームをサービスしているなら、キャッシュはどんなDESCRIBE要求にも答えなければなりません、ストリーム記述の低レベルである詳細が発生源サーバで変化したのが、可能であるときに。
Note that an RTSP cache, unlike the HTTP cache, is of the "cut- through" variety. Rather than retrieving the whole resource from the origin server, the cache simply copies the streaming data as it passes by on its way to the client. Thus, it does not introduce additional latency.
RTSPキャッシュがHTTPキャッシュと異なって「突き抜けるのに切られて」バラエティーのものであることに注意してください。 発生源サーバからの全体のリソースを検索するよりむしろ、クライアントへの途中で通り過ぎるとき、キャッシュは単にストリーミングのデータをコピーします。 したがって、それは追加潜在を導入しません。
To the client, an RTSP proxy cache appears like a regular media server, to the media origin server 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 (that is, 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プロキシキャッシュは通常のメディアサーバのように見えます、クライアントのようなメディア発生源サーバに。 ちょうどHTTPキャッシュがそれがキャッシュするオブジェクトのためにcontent type、満足している言語などを保存しなければならないように、メディアキャッシュはプレゼンテーション記述を保存しなければなりません。 通常、キャッシュはプレゼンテーション記述からすべての輸送参照(すなわち、マルチキャスト情報)を排除します、これらがキャッシュからクライアントまでのデータ配送から独立しているので。 encodingsに関する情報は同じままで残っています。 キャッシュがキャッシュされたメディアデータを翻訳できるなら、それは提供できるすべてのコード化の可能性で新しいプレゼンテーション記述を作成するでしょう。
14 Examples
14の例
The following examples refer to stream description formats that are not standards, such as RTSL. The following examples are not to be used as a reference for those formats.
以下の例はRTSLなどの規格でないストリーム記述書式を示します。 以下の例はそれらの形式の参照として使用されないことです。
14.1 Media on Demand (Unicast)
オンデマンドの14.1のメディア(ユニキャスト)
Client C requests a movie from media servers A ( audio.example.com) and V (video.example.com). The media description is stored on a web server W . The media description contains descriptions of the presentation and all its streams, including the codecs that are available, dynamic RTP payload types, the protocol stack, and content information such as language or copyright restrictions. It may also give an indication about the timeline of the movie.
クライアントCはメディアサーバA(audio.example.com)とV(video.example.com)から映画を要求します。 メディア記述はウェブサーバーWに保存されます。メディア記述はプレゼンテーションの記述とそのすべてのストリームを含んでいます、言語か著作権制限の利用可能なコーデック、ダイナミックなRTPペイロードタイプ、プロトコル・スタック、および満足している情報を含んでいて。 また、それは映画のスケジュールに関して指示を与えるかもしれません。
In this example, the client is only interested in the last part of the movie.
この例では、クライアントは映画の最後の部分に興味を持っているだけです。
C->W: GET /twister.sdp HTTP/1.1
Host: www.example.com
Accept: application/sdp
C>W: twister.sdp HTTP/1.1が接待する/を手に入れてください: www.example.com Accept: アプリケーション/sdp
W->C: HTTP/1.0 200 OK
Content-Type: application/sdp
W>C: HTTP/1.0 200はコンテントタイプを承認します: アプリケーション/sdp
Schulzrinne, et. al. Standards Track [Page 63] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[63ページ]RFC2326リアルタイム
v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
m=audio 0 RTP/AVP 0
a=control:rtsp://audio.example.com/twister/audio.en
m=video 0 RTP/AVP 31
a=control:rtsp://video.example.com/twister/video
: v=0の=-2890844526 2890842807o IN IP4 192.16.24.202 s=RTSP Session m=のオーディオの0RTP/AVP0a=コントロール: rtsp://audio.example.com/竜巻/audio.en m=ビデオ0RTP/AVP31a=制御rtsp://video.example.com/竜巻/ビデオ
C->A: SETUP rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057
C>A: SETUP rtsp://audio.example.com/竜巻/audio.en RTSP/1.0CSeq: 1 輸送: RTP/AVP/UDP; ユニキャスト; クライアント_ポートは3056-3057と等しいです。
A->C: RTSP/1.0 200 OK
CSeq: 1
Session: 12345678
Transport: RTP/AVP/UDP;unicast;client_port=3056-3057;
server_port=5000-5001
1>のC: RTSP/1.0 200はCSeqを承認します: 1つのセッション: 12345678 輸送: RTP/AVP/UDP; ユニキャスト; クライアント_ポートは3056-3057と等しいです。 サーバ_ポートは5000-5001と等しいです。
C->V: SETUP rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 1
Transport: RTP/AVP/UDP;unicast;client_port=3058-3059
C>V: SETUP rtsp://video.example.com/竜巻/ビデオRTSP/1.0CSeq: 1 輸送: RTP/AVP/UDP; ユニキャスト; クライアント_ポートは3058-3059と等しいです。
V->C: RTSP/1.0 200 OK
CSeq: 1
Session: 23456789
Transport: RTP/AVP/UDP;unicast;client_port=3058-3059;
server_port=5002-5003
V>C: RTSP/1.0 200はCSeqを承認します: 1つのセッション: 23456789 輸送: RTP/AVP/UDP; ユニキャスト; クライアント_ポートは3058-3059と等しいです。 サーバ_ポートは5002-5003と等しいです。
C->V: PLAY rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-
C>V: PLAY rtsp://video.example.com/竜巻/ビデオRTSP/1.0CSeq: 2セッション: 23456789は及びます: smpte=0: 10:00
V->C: RTSP/1.0 200 OK
CSeq: 2
Session: 23456789
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://video.example.com/twister/video;
seq=12312232;rtptime=78712811
V>C: RTSP/1.0 200はCSeqを承認します: 2セッション: 23456789は及びます: smpte=0:10時0分から0時20分:00RTP-インフォメーション: url=rtsp://video.example.com/竜巻/ビデオ。 seq=12312232; rtptime=78712811
C->A: PLAY rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 2
Session: 12345678
Range: smpte=0:10:00-
C>A: PLAY rtsp://audio.example.com/竜巻/audio.en RTSP/1.0CSeq: 2セッション: 12345678は及びます: smpte=0: 10:00
A->C: RTSP/1.0 200 OK
CSeq: 2
Session: 12345678
1>のC: RTSP/1.0 200はCSeqを承認します: 2セッション: 12345678
Schulzrinne, et. al. Standards Track [Page 64] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[64ページ]RFC2326リアルタイム
Range: smpte=0:10:00-0:20:00
RTP-Info: url=rtsp://audio.example.com/twister/audio.en;
seq=876655;rtptime=1032181
範囲: smpte=0:10時0分から0時20分:00RTP-インフォメーション: url=rtsp://audio.example.com/竜巻/audio.en。 seq=876655; rtptime=1032181
C->A: TEARDOWN rtsp://audio.example.com/twister/audio.en RTSP/1.0
CSeq: 3
Session: 12345678
C>A: TEARDOWN rtsp://audio.example.com/竜巻/audio.en RTSP/1.0CSeq: 3セッション: 12345678
A->C: RTSP/1.0 200 OK
CSeq: 3
1>のC: RTSP/1.0 200はCSeqを承認します: 3
C->V: TEARDOWN rtsp://video.example.com/twister/video RTSP/1.0
CSeq: 3
Session: 23456789
C>V: TEARDOWN rtsp://video.example.com/竜巻/ビデオRTSP/1.0CSeq: 3セッション: 23456789
V->C: RTSP/1.0 200 OK
CSeq: 3
V>C: RTSP/1.0 200はCSeqを承認します: 3
Even though the audio and video track are on two different servers, and may start at slightly different times and may drift with respect to each other, the client can synchronize the two using standard RTP methods, in particular the time scale contained in the RTCP sender reports.
オーディオとビデオ道は、2つの異なったサーバにあって、わずかにいろいろな時間に始まって、互いに関して漂流するかもしれませんが、クライアントは、標準のRTPメソッド、特にRTCP送付者レポートに含まれたタイムスケールを使用することで2を同期させることができます。
14.2 Streaming of a Container file
14.2 Containerファイルのストリーミング
For purposes of this example, a container file is a storage entity in which multiple continuous media types pertaining to the same end-user presentation are present. In effect, the container file represents an RTSP presentation, with each of its components being RTSP streams. Container files are a widely used means to store such presentations. While the components are transported as independent streams, it is desirable to maintain a common context for those streams at the server end.
この例の目的のために、コンテナファイルは同じエンドユーザプレゼンテーションに関係する複数の連続したメディアタイプが出席しているストレージ実体です。 事実上、コンテナファイルはRTSPプレゼンテーションを表します、RTSPストリームであるそれぞれのコンポーネントで。コンテナファイルはそのようなプレゼンテーションを保存する広く使用された手段です。 コンポーネントは独立しているストリームとして輸送されますが、サーバ終わりにそれらのストリームのための一般的な文脈を維持するのは望ましいです。
This enables the server to keep a single storage handle open
easily. It also allows treating all the streams equally in case of
any prioritization of streams by the server.
これは、サーバが容易に単一のストレージハンドルを開くように保つのを可能にします。 また、それで、サーバはストリームのどんな優先順位づけの場合に等しくすべてのストリームを扱います。
It is also possible that the presentation author may wish to prevent selective retrieval of the streams by the client in order to preserve the artistic effect of the combined media presentation. Similarly, in such a tightly bound presentation, it is desirable to be able to control all the streams via a single control message using an aggregate URL.
また、プレゼンテーション作者が結合したメディアプレゼンテーションの芸術的効果を保存するためにクライアントによるストリームの選択している検索を防ぎたがっているのも、可能です。 同様に、そのようなしっかり制限されたプレゼンテーションでは、集合URLを使用することで単一管理メッセージですべてのストリームを制御できるのは望ましいです。
The following is an example of using a single RTSP session to control multiple streams. It also illustrates the use of aggregate URLs.
↓これは複数のストリームを制御するのにただ一つのRTSPセッションを使用する例です。また、それは集合URLの使用を例証します。
Schulzrinne, et. al. Standards Track [Page 65] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[65ページ]RFC2326リアルタイム
Client C requests a presentation from media server M . The movie is stored in a container file. The client has obtained an RTSP URL to the container file.
クライアントCはメディアサーバMからプレゼンテーションを要求します。映画はコンテナファイルに保存されます。 クライアントはコンテナファイルにRTSP URLを入手しました。
C->M: DESCRIBE rtsp://foo/twister RTSP/1.0
CSeq: 1
C>M: DESCRIBE rtsp://foo/竜巻RTSP/1.0CSeq: 1
M->C: RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: 164
M>C: RTSP/1.0 200はCSeqを承認します: 1つのコンテントタイプ: sdp Contentアプリケーション/長さ: 164
v=0
o=- 2890844256 2890842807 IN IP4 172.16.2.93
s=RTSP Session
i=An Example of RTSP Session Usage
a=control:rtsp://foo/twister
t=0 0
m=audio 0 RTP/AVP 0
a=control:rtsp://foo/twister/audio
m=video 0 RTP/AVP 26
a=control:rtsp://foo/twister/video
: v=0oオーディオの0RTP/AVP0 0 0RTSP Session Usage a=コントロールの=-2890844256 2890842807IN IP4 172.16.2.93 s=RTSP Session i=Example: rtsp://foo/竜巻t=m=a=コントロール: rtsp://foo/竜巻/オーディオm=ビデオ0RTP/AVP26a=制御rtsp://foo/竜巻/ビデオ
C->M: SETUP rtsp://foo/twister/audio RTSP/1.0
CSeq: 2
Transport: RTP/AVP;unicast;client_port=8000-8001
C>M: SETUP rtsp://foo/竜巻/オーディオRTSP/1.0CSeq: 2 輸送: RTP/AVP; ユニキャスト; クライアント_ポートは8000-8001と等しいです。
M->C: RTSP/1.0 200 OK
CSeq: 2
Transport: RTP/AVP;unicast;client_port=8000-8001;
server_port=9000-9001
Session: 12345678
M>C: RTSP/1.0 200はCSeqを承認します: 2 輸送: RTP/AVP; ユニキャスト; クライアント_ポートは8000-8001と等しいです。 サーバ_ポートは9000-9001 Sessionと等しいです: 12345678
C->M: SETUP rtsp://foo/twister/video RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8002-8003
Session: 12345678
C>M: SETUP rtsp://foo/竜巻/ビデオRTSP/1.0CSeq: 3 輸送: RTP/AVP; ユニキャスト; クライアント_ポート=8002-8003セッション: 12345678
M->C: RTSP/1.0 200 OK
CSeq: 3
Transport: RTP/AVP;unicast;client_port=8002-8003;
server_port=9004-9005
Session: 12345678
M>C: RTSP/1.0 200はCSeqを承認します: 3 輸送: RTP/AVP; ユニキャスト; クライアント_ポートは8002-8003と等しいです。 サーバ_ポートは9004-9005 Sessionと等しいです: 12345678
C->M: PLAY rtsp://foo/twister RTSP/1.0
CSeq: 4
Range: npt=0-
Session: 12345678
C>M: PLAY rtsp://foo/竜巻RTSP/1.0CSeq: 4は及びます: npt=0セッション: 12345678
Schulzrinne, et. al. Standards Track [Page 66] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[66ページ]RFC2326リアルタイム
M->C: RTSP/1.0 200 OK
CSeq: 4
Session: 12345678
RTP-Info: url=rtsp://foo/twister/video;
seq=9810092;rtptime=3450012
M>C: RTSP/1.0 200はCSeqを承認します: 4セッション: 12345678RTP-インフォメーション: url=rtsp://foo/竜巻/ビデオ。 seq=9810092; rtptime=3450012
C->M: PAUSE rtsp://foo/twister/video RTSP/1.0
CSeq: 5
Session: 12345678
C>M: PAUSE rtsp://foo/竜巻/ビデオRTSP/1.0CSeq: 5セッション: 12345678
M->C: RTSP/1.0 460 Only aggregate operation allowed
CSeq: 5
M>C: RTSP/1.0 460のOnlyの集合操作はCSeqを許容しました: 5
C->M: PAUSE rtsp://foo/twister RTSP/1.0
CSeq: 6
Session: 12345678
C>M: PAUSE rtsp://foo/竜巻RTSP/1.0CSeq: 6セッション: 12345678
M->C: RTSP/1.0 200 OK
CSeq: 6
Session: 12345678
M>C: RTSP/1.0 200はCSeqを承認します: 6セッション: 12345678
C->M: SETUP rtsp://foo/twister RTSP/1.0
CSeq: 7
Transport: RTP/AVP;unicast;client_port=10000
C>M: SETUP rtsp://foo/竜巻RTSP/1.0CSeq: 7 輸送: RTP/AVP; ユニキャスト; クライアント_ポート=10000
M->C: RTSP/1.0 459 Aggregate operation not allowed
CSeq: 7
M>C: RTSP/1.0 459Aggregate操作はCSeqを許容しませんでした: 7
In the first instance of failure, the client tries to pause one stream (in this case video) of the presentation. This is disallowed for that presentation by the server. In the second instance, the aggregate URL may not be used for SETUP and one control message is required per stream to set up transport parameters.
失敗の最初のインスタンスでは、クライアントはプレゼンテーションの1つの流れ(この場合ビデオ)をポーズしようとします。 これはそのプレゼンテーションのためにサーバによって禁じられます。2番目のインスタンスに、集合URLはSETUPに使用されないかもしれません、そして、1つのコントロールメッセージが、輸送パラメタをセットアップするのにストリーム単位で必要です。
This keeps the syntax of the Transport header simple and allows
easy parsing of transport information by firewalls.
これは、Transportヘッダーの構文を簡単に保って、ファイアウォールのそばに輸送情報の簡単な構文解析を許容します。
14.3 Single Stream Container Files
14.3 ただ一つのストリームコンテナファイル
Some RTSP servers may treat all files as though they are "container files", yet other servers may not support such a concept. Because of this, clients SHOULD use the rules set forth in the session description for request URLs, rather than assuming that a consistent URL may always be used throughout. Here's an example of how a multi- stream server might expect a single-stream file to be served:
いくつかのRTSPサーバがまるでそれらが「コンテナファイル」であるかのようにすべてのファイルを扱うかもしれませんが、他のサーバはそのような概念をサポートしないかもしれません。 これのために、クライアントSHOULDは一貫したURLがいつも使用されるかもしれない仮定よりむしろ要求URLにセッション記述で詳しく説明された規則を使用します。 ここに、マルチストリームサーバが、ただ一つのストリーム・ファイルが役立たれるとどう予想するかもしれないかに関する例があります:
Accept: application/x-rtsp-mh, application/sdp
受け入れます: アプリケーション/x-rtsp-mh、アプリケーション/sdp
Schulzrinne, et. al. Standards Track [Page 67] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[67ページ]RFC2326リアルタイム
CSeq: 1
CSeq: 1
S->C RTSP/1.0 200 OK
CSeq: 1
Content-base: rtsp://foo.com/test.wav/
Content-type: application/sdp
Content-length: 48
S>C RTSP/1.0 200はCSeqを承認します: 1個の満足しているベース: rtsp://foo.com/test.wav/文書内容: sdp Contentアプリケーション/長さ: 48
v=0
o=- 872653257 872653257 IN IP4 172.16.2.187
s=mu-law wave file
i=audio test
t=0 0
m=audio 0 RTP/AVP 0
a=control:streamid=0
v=0o=-872653257 872653257IN IP4 172.16.2.187 s=μから0 0オーディオ法のウェーブファイルi=テストt=mへの=0RTP/AVP0オーディオのa=コントロール: streamid=0
C->S SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
Transport: RTP/AVP/UDP;unicast;
client_port=6970-6971;mode=play
CSeq: 2
C>S SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0Transport: RTP/AVP/UDP(ユニキャスト) クライアント_ポートは6970-6971と等しいです; モードはプレーCSeqと等しいです: 2
S->C RTSP/1.0 200 OK
Transport: RTP/AVP/UDP;unicast;client_port=6970-6971;
server_port=6970-6971;mode=play
CSeq: 2
Session: 2034820394
S>C RTSP/1.0 200は輸送を承認します: RTP/AVP/UDP; ユニキャスト; クライアント_ポートは6970-6971と等しいです。 サーバ_ポートは6970-6971と等しいです; モードはプレーCSeqと等しいです: 2セッション: 2034820394
C->S PLAY rtsp://foo.com/test.wav RTSP/1.0
CSeq: 3
Session: 2034820394
C>S PLAY rtsp://foo.com/test.wav RTSP/1.0CSeq: 3セッション: 2034820394
S->C RTSP/1.0 200 OK
CSeq: 3
Session: 2034820394
RTP-Info: url=rtsp://foo.com/test.wav/streamid=0;
seq=981888;rtptime=3781123
S>C RTSP/1.0 200はCSeqを承認します: 3セッション: 2034820394RTP-インフォメーション: url=rtsp://foo.com/test.wav/streamid=0。 seq=981888; rtptime=3781123
Note the different URL in the SETUP command, and then the switch back to the aggregate URL in the PLAY command. This makes complete sense when there are multiple streams with aggregate control, but is less than intuitive in the special case where the number of streams is one.
PLAYコマンドで、集合URLにSETUPコマンドにおける異なったURLに注意して、次に、スイッチに注意して戻してください。 これは、複数のストリームがあるとき、集合コントロールで完全な意味になりますが、ストリームの数が1である特別な場合ではあまり直感的ではありません。
In this special case, it is recommended that servers be forgiving of implementations that send:
この特別な場合では、サーバが発信する実装で寛大であることは、お勧めです:
C->S PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
CSeq: 3
C>S PLAY rtsp://foo.com/test.wav/streamid=0 RTSP/1.0CSeq: 3
Schulzrinne, et. al. Standards Track [Page 68] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[68ページ]RFC2326リアルタイム
In the worst case, servers should send back:
最悪の場合には、サーバは発信して戻るべきです:
S->C RTSP/1.0 460 Only aggregate operation allowed
CSeq: 3
S>CのRTSP/1.0 460のOnlyの集合操作はCSeqを許容しました: 3
One would also hope that server implementations are also forgiving of the following:
また、人は、また、サーバ実装が以下を許していることを望んでいるでしょう:
C->S SETUP rtsp://foo.com/test.wav RTSP/1.0
Transport: rtp/avp/udp;client_port=6970-6971;mode=play
CSeq: 2
C>S SETUP rtsp://foo.com/test.wav RTSP/1.0Transport: rtp/avp/udp; クライアント_ポートは6970-6971と等しいです; モードはプレーCSeqと等しいです: 2
Since there is only a single stream in this file, it's not ambiguous what this means.
このファイルにはただ一つのストリームしかないので、これが何を意味するかが、あいまいではありません。
14.4 Live Media Presentation Using Multicast
14.4 マルチキャストを使用するライブメディアプレゼンテーション
The media server M chooses the multicast address and port. Here, we assume that the web server only contains a pointer to the full description, while the media server M maintains the full description.
メディアサーバMはマルチキャストアドレスとポートを選びます。 ここで、私たちは、ウェブサーバーが余すところのない解説に指針を含むだけであると思います、メディアサーバMは余すところのない解説を維持しますが。
C->W: GET /concert.sdp HTTP/1.1
Host: www.example.com
C>W: concert.sdp HTTP/1.1が接待する/を手に入れてください: www.example.com
W->C: HTTP/1.1 200 OK
Content-Type: application/x-rtsl
W>C: HTTP/1.1 200はコンテントタイプを承認します: アプリケーション/x-rtsl
<session>
<track src="rtsp://live.example.com/concert/audio">
</session>
<セッション><道のsrc=、「rtsp://live.example.com/コンサート/オーディオ「></セッション>」
C->M: DESCRIBE rtsp://live.example.com/concert/audio RTSP/1.0
CSeq: 1
C>M: DESCRIBE rtsp://live.example.com/コンサート/オーディオRTSP/1.0CSeq: 1
M->C: RTSP/1.0 200 OK
CSeq: 1
Content-Type: application/sdp
Content-Length: 44
M>C: RTSP/1.0 200はCSeqを承認します: 1つのコンテントタイプ: sdp Contentアプリケーション/長さ: 44
v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
m=audio 3456 RTP/AVP 0
a=control:rtsp://live.example.com/concert/audio
c=IN IP4 224.2.0.1/16
v=0の=-2890844526 2890842807o IN IP4 192.16.24.202 s=RTSP Session m=のオーディオの3456RTP/AVP0a=コントロール: rtsp://live.example.com/コンサート/オーディオc=IN IP4 224.2.0.1/16
C->M: SETUP rtsp://live.example.com/concert/audio RTSP/1.0
CSeq: 2
C>M: SETUP rtsp://live.example.com/コンサート/オーディオRTSP/1.0CSeq: 2
Schulzrinne, et. al. Standards Track [Page 69] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[69ページ]RFC2326リアルタイム
Transport: RTP/AVP;multicast
輸送: RTP/AVP; マルチキャスト
M->C: RTSP/1.0 200 OK
CSeq: 2
Transport: RTP/AVP;multicast;destination=224.2.0.1;
port=3456-3457;ttl=16
Session: 0456804596
M>C: RTSP/1.0 200はCSeqを承認します: 2 輸送: RTP/AVP; マルチキャスト; 目的地=224.2.0.1。 ポートは3456-3457と等しいです;、ttl=16 Session: 0456804596
C->M: PLAY rtsp://live.example.com/concert/audio RTSP/1.0
CSeq: 3
Session: 0456804596
C>M: PLAY rtsp://live.example.com/コンサート/オーディオRTSP/1.0CSeq: 3セッション: 0456804596
M->C: RTSP/1.0 200 OK
CSeq: 3
Session: 0456804596
M>C: RTSP/1.0 200はCSeqを承認します: 3セッション: 0456804596
14.5 Playing media into an existing session
14.5 既存のセッションまでメディアと対戦します。
A conference participant C wants to have the media server M play back a demo tape into an existing conference. C indicates to the media server that the network addresses and encryption keys are already given by the conference, so they should not be chosen by the server. The example omits the simple ACK responses.
会議の参加者CはメディアサーバMに既存の会議にデモテープを再生させたがっています。 Cは、ネットワーク・アドレスと暗号化キーが会議によって既に与えられているのでそれらがサーバによって選ばれるべきでないのをメディアサーバに示します。例は簡単なACK応答を忘れます。
C->M: DESCRIBE rtsp://server.example.com/demo/548/sound RTSP/1.0
CSeq: 1
Accept: application/sdp
C>M: DESCRIBE rtsp://server.example.com/デモ/548/音のRTSP/1.0CSeq: 1 受け入れます: アプリケーション/sdp
M->C: RTSP/1.0 200 1 OK
Content-type: application/sdp
Content-Length: 44
M>C: RTSP/1.0 200 1OK文書内容: sdp Contentアプリケーション/長さ: 44
v=0
o=- 2890844526 2890842807 IN IP4 192.16.24.202
s=RTSP Session
i=See above
t=0 0
m=audio 0 RTP/AVP 0
=-2890844526 2890842807IN IP4 192.16.24.202 s=RTSP Session i=がtが0 0m等しいのを上を見るv=0oはオーディオの0RTP/AVP0と等しいです。
C->M: SETUP rtsp://server.example.com/demo/548/sound RTSP/1.0
CSeq: 2
Transport: RTP/AVP;multicast;destination=225.219.201.15;
port=7000-7001;ttl=127
Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
C>M: SETUP rtsp://server.example.com/デモ/548/音のRTSP/1.0CSeq: 2 輸送: RTP/AVP; マルチキャスト; 目的地=225.219.201.15。 ポート=7000-7001; ttl=127コンファレンス: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
M->C: RTSP/1.0 200 OK
CSeq: 2
Transport: RTP/AVP;multicast;destination=225.219.201.15;
M>C: RTSP/1.0 200はCSeqを承認します: 2 輸送: RTP/AVP; マルチキャスト; 目的地=225.219.201.15。
Schulzrinne, et. al. Standards Track [Page 70] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[70ページ]RFC2326リアルタイム
port=7000-7001;ttl=127
Session: 91389234234
Conference: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
ポートは7000-7001と等しいです;、ttl=127 Session: 91389234234コンファレンス: 199702170042.SAA08642@obiwan.arl.wustl.edu%20Starr
C->M: PLAY rtsp://server.example.com/demo/548/sound RTSP/1.0
CSeq: 3
Session: 91389234234
C>M: PLAY rtsp://server.example.com/デモ/548/音のRTSP/1.0CSeq: 3セッション: 91389234234
M->C: RTSP/1.0 200 OK
CSeq: 3
M>C: RTSP/1.0 200はCSeqを承認します: 3
14.6 Recording
14.6 録音
The conference participant client C asks the media server M to record the audio and video portions of a meeting. The client uses the ANNOUNCE method to provide meta-information about the recorded session to the server.
会議の参加者クライアントCは、ミーティングのオーディオとビデオ部分を記録するようにメディアサーバMに頼みます。 クライアントは記録されたセッション頃にメタ情報をサーバに提供するANNOUNCEメソッドを使用します。
C->M: ANNOUNCE rtsp://server.example.com/meeting RTSP/1.0
CSeq: 90
Content-Type: application/sdp
Content-Length: 121
C>M: ANNOUNCE rtsp://server.example.com/ミーティングRTSP/1.0CSeq: 90コンテントタイプ: sdp Contentアプリケーション/長さ: 121
v=0
o=camera1 3080117314 3080118787 IN IP4 195.27.192.36
s=IETF Meeting, Munich - 1
i=The thirty-ninth IETF meeting will be held in Munich, Germany
u=http://www.ietf.org/meetings/Munich.html
e=IETF Channel 1 <ietf39-mbone@uni-koeln.de>
p=IETF Channel 1 +49-172-2312 451
c=IN IP4 224.0.1.11/127
t=3080271600 3080703600
a=tool:sdr v2.4a6
a=type:test
m=audio 21010 RTP/AVP 5
c=IN IP4 224.0.1.11/127
a=ptime:40
m=video 61010 RTP/AVP 31
c=IN IP4 224.0.1.12/127
v=0 o=camera1 3080117314 3080118787IN IP4 195.27.192.36 s=IETF Meeting、ミュンヘン--1 http://www.ietf.org/meetings/Munich.html e=IETF Channel保持されたコネがミュンヘン、ドイツuであるつもりであったなら会う第39i=IETF= 1 <ietf39-mbone@uni-koeln.de 、gt;、p=IETF Channel1+49-172-2312、451、c、=IN IP4 224.0.1.11/127tは=ツールあたり3080271600 3080703600と等しいです: sdr v2.4a6 aはタイプと等しいです: テストmがオーディオの21010RTP/AVPと等しい、5、c、= IN IP4 224.0.1.11/127a=ptime: 40mがビデオ61010RTP/AVPと等しい、31、c、=IN IP4 224.0.1.12/127
M->C: RTSP/1.0 200 OK
CSeq: 90
M>C: RTSP/1.0 200はCSeqを承認します: 90
C->M: SETUP rtsp://server.example.com/meeting/audiotrack RTSP/1.0
CSeq: 91
Transport: RTP/AVP;multicast;destination=224.0.1.11;
port=21010-21011;mode=record;ttl=127
C>M: SETUP rtsp://server.example.com/ミーティング/audiotrack RTSP/1.0CSeq: 91 輸送: RTP/AVP; マルチキャスト; 目的地=224.0.1.11。 ポートは21010-21011; モード=記録; ttl=127と等しいです。
Schulzrinne, et. al. Standards Track [Page 71] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[71ページ]RFC2326リアルタイム
M->C: RTSP/1.0 200 OK
CSeq: 91
Session: 50887676
Transport: RTP/AVP;multicast;destination=224.0.1.11;
port=21010-21011;mode=record;ttl=127
M>C: RTSP/1.0 200はCSeqを承認します: 91セッション: 50887676 輸送: RTP/AVP; マルチキャスト; 目的地=224.0.1.11。 ポートは21010-21011; モード=記録; ttl=127と等しいです。
C->M: SETUP rtsp://server.example.com/meeting/videotrack RTSP/1.0
CSeq: 92
Session: 50887676
Transport: RTP/AVP;multicast;destination=224.0.1.12;
port=61010-61011;mode=record;ttl=127
C>M: SETUP rtsp://server.example.com/ミーティング/videotrack RTSP/1.0CSeq: 92セッション: 50887676 輸送: RTP/AVP; マルチキャスト; 目的地=224.0.1.12。 ポートは61010-61011; モード=記録; ttl=127と等しいです。
M->C: RTSP/1.0 200 OK
CSeq: 92
Transport: RTP/AVP;multicast;destination=224.0.1.12;
port=61010-61011;mode=record;ttl=127
M>C: RTSP/1.0 200はCSeqを承認します: 92 輸送: RTP/AVP; マルチキャスト; 目的地=224.0.1.12。 ポートは61010-61011; モード=記録; ttl=127と等しいです。
C->M: RECORD rtsp://server.example.com/meeting RTSP/1.0
CSeq: 93
Session: 50887676
Range: clock=19961110T1925-19961110T2015
C>M: RECORD rtsp://server.example.com/ミーティングRTSP/1.0CSeq: 93セッション: 50887676は及びます: 時計=19961110T1925-19961110T2015
M->C: RTSP/1.0 200 OK
CSeq: 93
M>C: RTSP/1.0 200はCSeqを承認します: 93
15 Syntax
15構文
The RTSP syntax is described in an augmented Backus-Naur form (BNF) as used in RFC 2068 [2].
RTSP構文はRFC2068[2]で使用されるように増大しているBN記法(BNF)で説明されます。
15.1 Base Syntax
15.1基地の構文
OCTET = <any 8-bit sequence of data> CHAR = <any US-ASCII character (octets 0 - 127)> UPALPHA = <any US-ASCII uppercase letter "A".."Z"> LOALPHA = <any US-ASCII lowercase letter "a".."z"> ALPHA = UPALPHA | LOALPHA
データ>CHAR=<において、どんな米国-ASCII文字(八重奏0--127)>UPALPHAも<と等しいです。「OCTETがどんな8ビットも配列する<と等しい、どんな米国-ASCII大文字「A」。」Z、「>LOALPHAがどんな米国-ASCIIも小文字で印刷する<と等しい、手紙“a"、」z「>アルファー=UPALPHA」| LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
DIGITは<とどんな米国-ASCIIケタ「0インチ」等しいです。9インチの>CTLは<と等しいです。どんな米国-ASCII制御文字(八重奏0--31)とデル(127)>CRも<米国-ASCII CRと等しいです、復帰(13)>LF=<米国-ASCII LF、ラインフィード(10)>。
SP = <US-ASCII SP, space (32)> HT = <US-ASCII HT, horizontal-tab (9)> <"> = <US-ASCII double-quote mark (34)> CRLF = CR LF
SP=<米国-ASCII SP、スペース(32)>HTは<米国-ASCII HTと等しく、水平タブ(9)><は「<米国-ASCII二重引用符>=(34)>CRLFはCR LFと等しいです」です。
Schulzrinne, et. al. Standards Track [Page 72] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[72ページ]RFC2326リアルタイム
LWS = [CRLF] 1*( SP | HT )
TEXT = <any OCTET except CTLs>
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
LWS=[CRLF]1*(SP| HT)TEXTがどんなOCTET CTLs>もtspecialsする<と等しい、等しさ、「(「|」、)、」| "<"| ">"| "@" | "," | ";" | ":" | "\" | <">"| "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP| HT
token = 1*<any CHAR except CTLs or tspecials> quoted-string = ( <"> *(qdtext) <"> ) qdtext = <any TEXT except <">> quoted-pair = "\" CHAR
トークン=1*<、CTLs以外のどんなCHARかtspecials>引用文字列=、も(<、「>*(qdtext)<、「>) qdtextが<と等しい、<「>>引用された組=「\」炭」を除いたどんなTEXT
message-header = field-name ":" [ field-value ] CRLF
field-name = token
field-value = *( field-content | LWS )
field-content = <the OCTETs making up the field-value and
consisting of either *TEXT or
combinations of token, tspecials, and
quoted-string>
「メッセージヘッダー=フィールド名」:、」 OCTETs作成が分野値と成ることを上げる[分野値]*(分野内容| LWS)分野CRLFフィールド名=トークン分野価値=内容=<*トークンのTEXTか組み合わせ、tspecials、および引用文字列>。
safe = "\$" | "-" | "_" | "." | "+"
extra = "!" | "*" | "$'$" | "(" | ")" | ","
「金庫は」 \$と等しいです」| "-" | "_" | "." | 「+」 付加的な=“!" | "*" | "$'$" | "(" | ")" | ","
hex = DIGIT | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
escape = "\%" hex hex
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="
十六進法=DIGIT| 「A」| 「B」| 「C」| 「D」| 「E」| 「F」| "a"| 「b」| 「c」| 「d」| 「e」| 「「」 」 十六進法が魔法をかける\f」エスケープ=%は=を予約しました」」 | "/" | "?" | ":" | "@" | "&" | "="
unreserved = alpha | digit | safe | extra xchar = unreserved | reserved | escape
無遠慮な=アルファ| ケタ| 金庫| 付加的なxchar=無遠慮です。| 予約されます。| エスケープ
16 Security Considerations
16 セキュリティ問題
Because of the similarity in syntax and usage between RTSP servers and HTTP servers, the security considerations outlined in [H15] apply. Specifically, please note the following:
構文による類似性とRTSPサーバとHTTPサーバの間の用法のために、[H15]に概説されたセキュリティ問題は適用されます。 明確に、以下に注意してください:
Authentication Mechanisms:
RTSP and HTTP share common authentication schemes, and thus
should follow the same prescriptions with regards to
authentication. See [H15.1] for client authentication issues,
and [H15.2] for issues regarding support for multiple
authentication mechanisms.
認証機構: RTSPとHTTPは、一般的な認証体系を共有して、その結果、あいさつで同じ処方箋に認証に続くべきです。 クライアント認証問題に関して[H15.1]を見て、複数の認証機構のサポートに関する問題のために[H15.2]を見てください。
Abuse of Server Log Information:
RTSP and HTTP servers will presumably have similar logging
mechanisms, and thus should be equally guarded in protecting
the contents of those logs, thus protecting the privacy of the
サーバログ情報の乱用: RTSPとHTTPサーバは、おそらく、同様の伐採メカニズムを持って、その結果、それらのログのコンテンツを保護する際に等しく警備されるべきです、その結果、プライバシーを保護します。
Schulzrinne, et. al. Standards Track [Page 73] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[73ページ]RFC2326リアルタイム
users of the servers. See [H15.3] for HTTP server
recommendations regarding server logs.
サーバのユーザ。 HTTPサーバ推薦に関してサーバログに関して[H15.3]を見てください。
Transfer of Sensitive Information:
There is no reason to believe that information transferred via
RTSP may be any less sensitive than that normally transmitted
via HTTP. Therefore, all of the precautions regarding the
protection of data privacy and user privacy apply to
implementors of RTSP clients, servers, and proxies. See
[H15.4] for further details.
機密情報の転送: RTSPを通して移された情報が通常、それがHTTPで伝わったより少しも機密でないかもしれないと信じる理由が全くありません。 したがって、データプライバシーとユーザプライバシーの保護に関する注意のすべてがクライアント、サーバ、およびプロキシをRTSPの作成者に適用します。 さらに詳しい明細については[H15.4]を見てください。
Attacks Based On File and Path Names:
Though RTSP URLs are opaque handles that do not necessarily
have file system semantics, it is anticipated that many
implementations will translate portions of the request URLs
directly to file system calls. In such cases, file systems
SHOULD follow the precautions outlined in [H15.5], such as
checking for ".." in path components.
ファイルとパス名に基づく攻撃: RTSP URLは必ずファイルシステム意味論を持っているというわけではない不透明なハンドルですが、多くの実装がシステムコールをファイルするために直接要求URLの一部を翻訳すると予期されます。 「そのような場合、ファイルシステムSHOULDは[H15.5]に概説された」 . . 」 コネがないかどうか経路コンポーネントをチェックなどなどの注意に続きます。
Personal Information:
RTSP clients are often privy to the same information that HTTP
clients are (user name, location, etc.) and thus should be
equally. See [H15.6] for further recommendations.
個人情報: RTSPクライアントはしばしば同じ情報などに関与しています。 さらなる推薦に関して[H15.6]を見てください。
Privacy Issues Connected to Accept Headers:
Since may of the same "Accept" headers exist in RTSP as in
HTTP, the same caveats outlined in [H15.7] with regards to
their use should be followed.
プライバシーの問題はヘッダーを受け入れるために接続しました: 以来、HTTPでは、[H15.7]にあいさつで彼らの使用に概説された同じ警告に続くべきであるとき、同じヘッダーが存在する「受け入れてください」RTSPについてそうするかもしれません。
DNS Spoofing:
Presumably, given the longer connection times typically
associated to RTSP sessions relative to HTTP sessions, RTSP
client DNS optimizations should be less prevalent.
Nonetheless, the recommendations provided in [H15.8] are still
relevant to any implementation which attempts to rely on a
DNS-to-IP mapping to hold beyond a single use of the mapping.
DNSスプーフィング: おそらく、HTTPセッションに比例して通常RTSPセッションまで関連づけられたより長い接続時間を考えて、RTSPクライアントDNS最適化はそれほど一般的であるべきではありません。 それにもかかわらず、[H15.8]に提供された推薦はまだマッピングのただ一つの使用を超えて成立するようにDNSからIPへのマッピングを当てにするのを試みるどんな実装にも関連しています。
Location Headers and Spoofing:
If a single server supports multiple organizations that do not
trust one another, then it must check the values of Location
and Content-Location headers in responses that are generated
under control of said organizations to make sure that they do
not attempt to invalidate resources over which they have no
authority. ([H15.9])
位置のヘッダーとスプーフィング: ただ一つのサーバがお互いを信じない複数の組織をサポートするなら、それはそれらが権威を全く持っていないリソースを無効にするのを試みないのを確実にするために前述の組織のコントロールの下で生成される応答でLocationとContent-位置のヘッダーの値をチェックしなければなりません。 ([H15.9])
In addition to the recommendations in the current HTTP specification (RFC 2068 [2], as of this writing), future HTTP specifications may provide additional guidance on security issues.
現在のHTTP仕様(この書くこと現在RFC2068[2])に基づく推薦に加えて、将来のHTTP仕様は安全保障問題で追加指導を提供するかもしれません。
Schulzrinne, et. al. Standards Track [Page 74] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[74ページ]RFC2326リアルタイム
The following are added considerations for RTSP implementations.
↓これはRTSP実装のための加えられた問題です。
Concentrated denial-of-service attack:
The protocol offers the opportunity for a remote-controlled
denial-of-service attack. The attacker may initiate traffic
flows to one or more IP addresses by specifying them as the
destination in SETUP requests. While the attacker's IP address
may be known in this case, this is not always useful in
prevention of more attacks or ascertaining the attackers
identity. Thus, an RTSP server SHOULD only allow client-
specified destinations for RTSP-initiated traffic flows if the
server has verified the client's identity, either against a
database of known users using RTSP authentication mechanisms
(preferably digest authentication or stronger), or other
secure means.
集中サービス不能攻撃: プロトコルは遠隔操作のサービス不能攻撃の機会を提供します。 攻撃者は、SETUP要求における目的地としてそれらを指定することによって、1つ以上のIPアドレスへの交通の流れを起こすかもしれません。 攻撃者のIPアドレスがこの場合知られているかもしれない間、これは、いつもより多くの攻撃の防止で役に立つというわけではない、攻撃者のアイデンティティを確かめません。 したがって、サーバがクライアントのアイデンティティについて確かめたなら、SHOULDがRTSPによって開始されたトラフィックのためのクライアントの指定された目的地を許容するだけであるRTSPサーバは流れます、RTSP認証機構(望ましくはダイジェスト認証であるか、より強い)、または他の安全な手段を使用する知られているユーザのデータベースに対のどちらかだって。
Session hijacking:
Since there is no relation between a transport layer
connection and an RTSP session, it is possible for a malicious
client to issue requests with random session identifiers which
would affect unsuspecting clients. The server SHOULD use a
large, random and non-sequential session identifier to
minimize the possibility of this kind of attack.
セッションハイジャック: トランスポート層接続とRTSPセッションとの関係が全くないので、悪意があるクライアントが疑わないクライアントに影響する無作為のセッション識別子で要求を出すのは、可能です。 サーバSHOULDは、この種類の攻撃の可能性を最小にするのに大きくて、無作為の、そして、非連続したセッション識別子を使用します。
Authentication:
Servers SHOULD implement both basic and digest [8]
authentication. In environments requiring tighter security for
the control messages, the RTSP control stream may be
encrypted.
認証: サーバSHOULDは、ともに基本的、そして、ダイジェスト[8]が認証であると実装します。 コントロールメッセージのために安全管理強化を必要とする環境で、RTSP制御ストリームは暗号化されるかもしれません。
Stream issues:
RTSP only provides for stream control. Stream delivery issues
are not covered in this section, nor in the rest of this memo.
RTSP implementations will most likely rely on other protocols
such as RTP, IP multicast, RSVP and IGMP, and should address
security considerations brought up in those and other
applicable specifications.
問題を流してください: RTSPはストリームコントロールに備えるだけです。 ストリーム配送問題はこのセクション、およびこのメモの残りでカバーされていません。 RTSP実装は、たぶんIPのRTPや、マルチキャストや、RSVPやIGMPなどの他のプロトコルを当てにして、セキュリティがそれらで持って来られた問題と他の適切な仕様であると扱うべきです。
Persistently suspicious behavior:
RTSP servers SHOULD return error code 403 (Forbidden) upon
receiving a single instance of behavior which is deemed a
security risk. RTSP servers SHOULD also be aware of attempts
to probe the server for weaknesses and entry points and MAY
arbitrarily disconnect and ignore further requests clients
which are deemed to be in violation of local security policy.
持続して疑わしげな振舞い: セキュリティリスクであると考えられる振舞いのただ一つのインスタンスを受けるとき、RTSPサーバSHOULDはエラーコード403(禁じられます)を返します。 RTSPサーバSHOULDも任意に一層の要求クライアントからサーバを弱点と何エントリー・ポイントも調べる試みを意識していて、切断して、無視するかもしれません(ローカルの安全保障政策を違反していると考えられます)。
Schulzrinne, et. al. Standards Track [Page 75] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[75ページ]RFC2326リアルタイム
Appendix A: RTSP Protocol State Machines
付録A: RTSPプロトコル州のマシン
The RTSP client and server state machines describe the behavior of the protocol from RTSP session initialization through RTSP session termination.
RTSPクライアントとサーバ州のマシンはRTSPセッション初期化からRTSPセッション終了によるプロトコルの振舞いについて説明します。
State is defined on a per object basis. An object is uniquely identified by the stream URL and the RTSP session identifier. Any request/reply using aggregate URLs denoting RTSP presentations composed of multiple streams will have an effect on the individual states of all the streams. For example, if the presentation /movie contains two streams, /movie/audio and /movie/video, then the following command:
状態は1対象分類あたりのaで定義されます。 オブジェクトはストリームURLとRTSPセッション識別子によって唯一特定されます。 複数のストリームで構成されたRTSPプレゼンテーションを指示する集合URLを使用するどんな要求/回答もすべてのストリームの個々の州に影響を与えるでしょう。例えば、プレゼンテーション/映画が2つのストリーム、/movie/audio、および/movie/videoを含んでいるなら、以下は命令します:
PLAY rtsp://foo.com/movie RTSP/1.0
CSeq: 559
Session: 12345678
PLAY rtsp://foo.com/映画RTSP/1.0CSeq: 559セッション: 12345678
will have an effect on the states of movie/audio and movie/video.
映画/オーディオと映画/ビデオの州に影響を与えるでしょう。
This example does not imply a standard way to represent streams in
URLs or a relation to the filesystem. See Section 3.2.
この例はURLのストリームを表す標準の方法かファイルシステムとの関係を含意しません。 セクション3.2を見てください。
The requests OPTIONS, ANNOUNCE, DESCRIBE, GET_PARAMETER, SET_PARAMETER do not have any effect on client or server state and are therefore not listed in the state tables.
要求OPTIONS、ANNOUNCE、DESCRIBE、GET_PARAMETER、SET_PARAMETERはクライアントかサーバ状態に少しの効果も持たないで、またしたがって、ステートテーブルに記載されていません。
A.1 Client State Machine
A.1属国マシン
The client can assume the following states:
クライアントは以下の州を仮定できます:
Init:
SETUP has been sent, waiting for reply.
イニット: 回答を待っていて、SETUPを送りました。
Ready:
SETUP reply received or PAUSE reply received while in Playing
state.
準備ができる: Playing状態にある間、SETUP回答が受信されたか、またはPAUSE回答は受信されました。
Playing:
PLAY reply received
プレーします: PLAY回答は受信されました。
Recording:
RECORD reply received
録音: RECORD回答は受信されました。
In general, the client changes state on receipt of replies to requests. Note that some requests are effective at a future time or position (such as a PAUSE), and state also changes accordingly. If no explicit SETUP is required for the object (for example, it is
一般に、クライアントは要求に関する回答を受け取り次第状態を変えます。 いくつかの要求が将来の時間か位置(PAUSEなどの)で有効であることに注意してください、そして、また、それに従って、変化を述べてください。 どんな明白なSETUPもオブジェクトに必要でない、(例えば、それがそうです。
Schulzrinne, et. al. Standards Track [Page 76] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[76ページ]RFC2326リアルタイム
available via a multicast group), state begins at Ready. In this case, there are only two states, Ready and Playing. The client also changes state from Playing/Recording to Ready when the end of the requested range is reached.
マルチキャストグループを通して利用可能である、)、状態はReadyで始まります。 この場合、2つの州、Ready、およびPlayingしかありません。 また、要求された範囲の端に達しているとき、クライアントは状態をPlaying/録音からReadyに変えます。
The "next state" column indicates the state assumed after receiving a success response (2xx). If a request yields a status code of 3xx, the state becomes Init, and a status code of 4xx yields no change in state. Messages not listed for each state MUST NOT be issued by the client in that state, with the exception of messages not affecting state, as listed above. Receiving a REDIRECT from the server is equivalent to receiving a 3xx redirect status from the server.
「次の状態」コラムは、成功を受けた後に州が、応答が(2xx)であると仮定したのを示します。 要求が3xxのステータスコードをもたらすなら、状態はInitになります、そして、4xxのステータスコードは状態で変化を全くもたらしません。 各状態にリストアップされなかったメッセージはその状態でクライアントによって発行されてはいけません、状態に影響しないメッセージを除いて、上に記載されているように。 サーバからREDIRECTを受けるのはサーバから3xxの再直接の状態を取るのに同等です。
state message sent next state after response
Init SETUP Ready
TEARDOWN Init
Ready PLAY Playing
RECORD Recording
TEARDOWN Init
SETUP Ready
Playing PAUSE Ready
TEARDOWN Init
PLAY Playing
SETUP Playing (changed transport)
Recording PAUSE Ready
TEARDOWN Init
RECORD Recording
SETUP Recording (changed transport)
応答Init SETUP Ready TEARDOWN Init Ready PLAY Playing RECORD Recording TEARDOWN Init SETUP Ready Playing PAUSE Ready TEARDOWN Init PLAY Playing SETUP Playing(輸送を変える)の後にPAUSE Ready TEARDOWN Init RECORD Recording SETUP Recordingを記録しながら次の状態に送られた州のメッセージ(変えられた輸送)
A.2 Server State Machine
A.2サーバ州のマシン
The server can assume the following states:
サーバは以下の州を仮定できます:
Init:
The initial state, no valid SETUP has been received yet.
イニット: 初期状態であり、まだどんな有効なSETUPも受け取っていません。
Ready:
Last SETUP received was successful, reply sent or after
playing, last PAUSE received was successful, reply sent.
準備ができる: 最後に受け取られたSETUPがうまくいった、プレーした後に受け取られた最後のPAUSEがうまくいった、回答が発信したか、または回答は発信しました。
Playing:
Last PLAY received was successful, reply sent. Data is being
sent.
プレーします: 最後に受け取られたPLAYがうまくいった、回答は発信しました。 データを送ります。
Recording:
The server is recording media data.
録音: サーバはメディアデータを記録しています。
Schulzrinne, et. al. Standards Track [Page 77] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[77ページ]RFC2326リアルタイム
In general, the server changes state on receiving requests. If the server is in state Playing or Recording and in unicast mode, it MAY revert to Init and tear down the RTSP session if it has not received "wellness" information, such as RTCP reports or RTSP commands, from the client for a defined interval, with a default of one minute. The server can declare another timeout value in the Session response header (Section 12.37). If the server is in state Ready, it MAY revert to Init if it does not receive an RTSP request for an interval of more than one minute. Note that some requests (such as PAUSE) may be effective at a future time or position, and server state changes at the appropriate time. The server reverts from state Playing or Recording to state Ready at the end of the range requested by the client.
一般に、要求を受け取るとき、サーバは状態を変えます。 サーバが州のPlayingかRecordingとユニキャストモードであって、「ウェルネス」情報を受け取っていないなら、Initに戻って、RTSPセッションを取りこわすかもしれません、RTCPレポートやRTSPコマンドのように、定義された間隔の間のクライアントから、1分のデフォルトで。 サーバは、Session応答ヘッダ(セクション12.37)で別のタイムアウトが値であると宣言できます。 サーバが州のReadyにあって、1分以上の間隔を求めるRTSP要求を受け取らないなら、それはInitに戻るかもしれません。 いくつかの要求(PAUSEなどの)が将来の時間か位置と、サーバ州の変化で適切な時期で有効であるかもしれないことに注意してください。 サーバは、クライアントによって要求された範囲の端にReadyを述べるために州のPlayingかRecordingから戻ります。
The REDIRECT message, when sent, is effective immediately unless it has a Range header specifying when the redirect is effective. In such a case, server state will also change at the appropriate time.
送って、すぐRangeヘッダーが、それで再直接がいつ有効であるかを指定しない場合、REDIRECTメッセージは有効です。 また、このような場合には、サーバ状態は適切な時期で変化するでしょう。
If no explicit SETUP is required for the object, the state starts at Ready and there are only two states, Ready and Playing.
どんな明白なSETUPもオブジェクトに必要でないなら、状態がReadyで始まります、そして、ReadyとPlaying、2つの州しかありません。
The "next state" column indicates the state assumed after sending a success response (2xx). If a request results in a status code of 3xx, the state becomes Init. A status code of 4xx results in no change.
「次の状態」コラムは、成功を送った後に州が、応答が(2xx)であると仮定したのを示します。 要求が3xxのステータスコードをもたらすなら、状態はInitになります。 4xxのステータスコードは変化を全くもたらしません。
state message received next state
Init SETUP Ready
TEARDOWN Init
Ready PLAY Playing
SETUP Ready
TEARDOWN Init
RECORD Recording
Playing PLAY Playing
PAUSE Ready
TEARDOWN Init
SETUP Playing
Recording RECORD Recording
PAUSE Ready
TEARDOWN Init
SETUP Recording
州のメッセージは次の州のInit SETUP Ready TEARDOWN Init Ready PLAY Playing SETUP Ready TEARDOWN Init RECORD Recording Playing PLAY Playing PAUSE Ready TEARDOWN Init SETUP Playing Recording RECORD Recording PAUSE Ready TEARDOWN Init SETUP Recordingを受けました。
Schulzrinne, et. al. Standards Track [Page 78] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[78ページ]RFC2326リアルタイム
Appendix B: Interaction with RTP
付録B: RTPとの相互作用
RTSP allows media clients to control selected, non-contiguous sections of media presentations, rendering those streams with an RTP media layer[24]. The media layer rendering the RTP stream should not be affected by jumps in NPT. Thus, both RTP sequence numbers and RTP timestamps MUST be continuous and monotonic across jumps of NPT.
RTPメディア層の[24]でそれらのストリームをレンダリングして、RTSPはメディアクライアントに選択されて、非隣接のセクションのメディアプレゼンテーションを制御させます。 RTPストリームをレンダリングするメディア層はNPTにおけるジャンプで影響を受けるべきではありません。 したがって、RTP一連番号とRTPタイムスタンプの両方が、NPTのジャンプの向こう側に連続していて単調であるに違いありません。
As an example, assume a clock frequency of 8000 Hz, a packetization interval of 100 ms and an initial sequence number and timestamp of zero. First we play NPT 10 through 15, then skip ahead and play NPT 18 through 20. The first segment is presented as RTP packets with sequence numbers 0 through 49 and timestamp 0 through 39,200. The second segment consists of RTP packets with sequence number 50 through 69, with timestamps 40,000 through 55,200.
例として、ゼロに関する8000Hzのクロック周波数、100msのpacketization間隔、初期シーケンス番号、およびタイムスタンプを仮定してください。 まず最初に、私たちは、18〜20に10〜15にNPTをプレーして、次に、先でスキップして、NPTをプレーします。 最初のセグメントはRTPパケットとして一連番号0〜49とタイムスタンプで0〜3万9200に提示されます。 2番目のセグメントはタイムスタンプで一連番号があるRTPパケットから50〜69に4万〜5万5200に成ります。
We cannot assume that the RTSP client can communicate with the RTP
media agent, as the two may be independent processes. If the RTP
timestamp shows the same gap as the NPT, the media agent will
assume that there is a pause in the presentation. If the jump in
NPT is large enough, the RTP timestamp may roll over and the media
agent may believe later packets to be duplicates of packets just
played out.
私たちは、RTSPクライアントがRTPメディアエージェントとコミュニケートできると思うことができません、2が独立しているプロセスであるかもしれないので。 RTPタイムスタンプがNPTと同じギャップを示していると、メディアエージェントは、プレゼンテーションにおけるくぎりがあると仮定するでしょう。 NPTにおけるジャンプが十分大きいなら、RTPタイムスタンプはひっくり返るかもしれません、そして、メディアエージェントは後でパケットがただ使い果たされたパケットの写しであると信じるかもしれません。
For certain datatypes, tight integration between the RTSP layer and
the RTP layer will be necessary. This by no means precludes the
above restriction. Combined RTSP/RTP media clients should use the
RTP-Info field to determine whether incoming RTP packets were sent
before or after a seek.
RTSP層とRTP層の間のきつい統合はあるデータ型式に、必要になるでしょう。 これは上の制限を決して排除しません。 結合したRTSP/RTPメディアクライアントは、入って来るRTPパケットがシークの前または後に送られたかどうか決定するのにRTP-インフォメーション分野を使用するべきです。
For continuous audio, the server SHOULD set the RTP marker bit at the beginning of serving a new PLAY request. This allows the client to perform playout delay adaptation.
連続したオーディオのために、サーバSHOULDは新しいPLAY要求に役立つ始めにおけるRTPマーカービットを設定します。 これで、クライアントは再生遅れ適合を実行できます。
For scaling (see Section 12.34), RTP timestamps should correspond to the playback timing. For example, when playing video recorded at 30 frames/second at a scale of two and speed (Section 12.35) of one, the server would drop every second frame to maintain and deliver video packets with the normal timestamp spacing of 3,000 per frame, but NPT would increase by 1/15 second for each video frame.
スケーリング(セクション12.34を見る)のために、RTPタイムスタンプは再生タイミングに対応するべきです。 30フレーム/秒に2のスケールと1の速度(セクション12.35)で記録されたビデオを再生するとき、例えば、サーバは1フレームあたり3,000の正常なタイムスタンプスペースでビデオパケットを維持して、提供するためにあらゆる2番目のフレームを下げるでしょうが、NPTはそれぞれのビデオフレームあたり1/15秒増加するでしょう。
The client can maintain a correct display of NPT by noting the RTP timestamp value of the first packet arriving after repositioning. The sequence parameter of the RTP-Info (Section 12.33) header provides the first sequence number of the next segment.
クライアントは、位置を変える後に到着する最初のパケットのRTPタイムスタンプ価値に注意することによって、NPTの正しいディスプレイを維持できます。 RTP-インフォメーション(セクション12.33)ヘッダーの系列パラメタは次のセグメントの最初の一連番号を提供します。
Schulzrinne, et. al. Standards Track [Page 79] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[79ページ]RFC2326リアルタイム
Appendix C: Use of SDP for RTSP Session Descriptions
付録C: SDPのRTSPセッション記述の使用
The Session Description Protocol (SDP, RFC 2327 [6]) may be used to describe streams or presentations in RTSP. Such usage is limited to specifying means of access and encoding(s) for:
Session記述プロトコル、(SDP、RFC2327[6])は、RTSPでストリームかプレゼンテーションについて説明するのに使用されるかもしれません。 そのような用法は以下のためにアクセスの手段を指定して、(s)をコード化するのに制限されます。
aggregate control:
A presentation composed of streams from one or more servers
that are not available for aggregate control. Such a
description is typically retrieved by HTTP or other non-RTSP
means. However, they may be received with ANNOUNCE methods.
コントロールに集めてください: プレゼンテーションは集合コントロールに利用可能でない1つ以上のサーバからストリームで構成されました。 そのような記述はHTTPか他の非RTSP手段で通常検索されます。 しかしながら、ANNOUNCEメソッドでそれらを受け取るかもしれません。
non-aggregate control:
A presentation composed of multiple streams from a single
server that are available for aggregate control. Such a
description is typically returned in reply to a DESCRIBE
request on a URL, or received in an ANNOUNCE method.
非集合のコントロール: プレゼンテーションはただ一つのサーバからの集合コントロールに利用可能な複数のストリームで構成されました。 そのような記述を通常URLに関するDESCRIBE要求に対して返すか、またはANNOUNCEメソッドで受けます。
This appendix describes how an SDP file, retrieved, for example, through HTTP, determines the operation of an RTSP session. It also describes how a client should interpret SDP content returned in reply to a DESCRIBE request. SDP provides no mechanism by which a client can distinguish, without human guidance, between several media streams to be rendered simultaneously and a set of alternatives (e.g., two audio streams spoken in different languages).
この付録は例えばHTTPを通して取られたSDPファイルがどうRTSPセッションの操作を決定するかを説明します。 また、それはクライアントがどうDESCRIBE要求に対して返されたSDP内容を解釈するべきであるかを説明します。 SDPはクライアントが区別できるメカニズムを全く提供しません、人間の指導なしで、同時にレンダリングされるいくつかのメディアストリームと代替手段のセット(例えば異なった言語で話された2つのオーディオストリーム)の間で。
C.1 Definitions
C.1定義
The terms "session-level", "media-level" and other key/attribute names and values used in this appendix are to be used as defined in SDP (RFC 2327 [6]):
SDPで定義されるように「セッションレベル」、「メディアレベル」、他のキー/属性名、および値がこの付録で使用した用語が使用されていることになっている、(RFC2327[6]):
C.1.1 Control URL
C.1.1コントロールURL
The "a=control:" attribute is used to convey the control URL. This attribute is used both for the session and media descriptions. If used for individual media, it indicates the URL to be used for controlling that particular media stream. If found at the session level, the attribute indicates the URL for aggregate control.
「=は以下を制御します」 属性は、コントロールURLを伝えるのに使用されます。 この属性はセッションとメディア記述に使用されます。 独特のメディアに使用されるなら、それは、その特定のメディアストリームを制御するのに使用されるためにURLを示します。 セッションレベルで見つけられるなら、属性は集合コントロールのためにURLを示します。
Example:
a=control:rtsp://example.com/foo
例: =コントロール: rtsp://example.com/foo
This attribute may contain either relative and absolute URLs, following the rules and conventions set out in RFC 1808 [25]. Implementations should look for a base URL in the following order:
約束を守って、この属性は相対的で絶対のURLを含むかもしれません、そして、コンベンションはRFC1808[25]を始められます。 実装は以下のオーダーでベースURLを探すべきです:
Schulzrinne, et. al. Standards Track [Page 80] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[80ページ]RFC2326リアルタイム
1. The RTSP Content-Base field 2. The RTSP Content-Location field 3. The RTSP request URL
1. RTSP Content-基地の分野2。 RTSP Content-位置の分野3。 RTSP要求URL
If this attribute contains only an asterisk (*), then the URL is treated as if it were an empty embedded URL, and thus inherits the entire base URL.
この属性がアスタリスク(*)だけを含んでいるなら、URLは、まるでそれが空の埋め込まれたURLであるかのように扱われて、その結果、全体のベースURLを引き継ぎます。
C.1.2 Media streams
C.1.2メディアストリーム
The "m=" field is used to enumerate the streams. It is expected that all the specified streams will be rendered with appropriate synchronization. If the session is unicast, the port number serves as a recommendation from the server to the client; the client still has to include it in its SETUP request and may ignore this recommendation. If the server has no preference, it SHOULD set the port number value to zero.
「m=」分野は、ストリームを列挙するのに使用されます。すべての指定されたストリームが適切な同期でレンダリングされると予想されます。 セッションがユニキャストであるなら、ポートナンバーはサーバからクライアントまでの推薦として機能します。 クライアントは、SETUP要求でまだそれを入れなければならなくて、この推薦を無視するかもしれません。 サーバはどちらでもよく、それはポート番号がゼロに評価するSHOULDセットです。
Example:
m=audio 0 RTP/AVP 31
例: mはオーディオの0RTP/AVP31と等しいです。
C.1.3 Payload type(s)
C.1.3有効搭載量タイプ(s)
The payload type(s) are specified in the "m=" field. In case the payload type is a static payload type from RFC 1890 [1], no other information is required. In case it is a dynamic payload type, the media attribute "rtpmap" is used to specify what the media is. The "encoding name" within the "rtpmap" attribute may be one of those specified in RFC 1890 (Sections 5 and 6), or an experimental encoding with a "X-" prefix as specified in SDP (RFC 2327 [6]). Codec- specific parameters are not specified in this field, but rather in the "fmtp" attribute described below. Implementors seeking to register new encodings should follow the procedure in RFC 1890 [1]. If the media type is not suited to the RTP AV profile, then it is recommended that a new profile be created and the appropriate profile name be used in lieu of "RTP/AVP" in the "m=" field.
ペイロードタイプは「m=」分野で指定されます。 ペイロードタイプがRFC1890[1]からの静的なペイロードタイプであるといけないので、他の情報は全く必要ではありません。 それがダイナミックなペイロードタイプであるといけないので、メディア属性"rtpmap"はメディアが何であるかを指定するのに使用されます。 "rtpmap"属性の中の「名前をコード化します」は、RFC1890(セクション5と6)で指定されたものの1つ、または指定されるとしての「X」接頭語がSDPにある実験的なコード化であるかもしれません。(RFC2327[6])。 コーデックの特定のパラメタはこの分野にもかかわらず、むしろ以下で説明された"fmtp"属性で指定されません。 新しいencodingsを登録しようとしている作成者はRFC1890[1]で手順に従うべきです。 メディアタイプがRTP AVプロフィールに合っていないなら新しいプロフィールが作成されるのが、お勧めであり、存在という適切なプロフィール名は「m=」分野の"RTP/AVP"の代わりに使用されています。
C.1.4 Format-specific parameters
C.1.4の形式特有のパラメタ
Format-specific parameters are conveyed using the "fmtp" media attribute. The syntax of the "fmtp" attribute is specific to the encoding(s) that the attribute refers to. Note that the packetization interval is conveyed using the "ptime" attribute.
形式特有のパラメタは、"fmtp"メディア属性を使用することで伝えられます。 "fmtp"属性の構文は属性が言及するコード化に特定です。 packetization間隔が"ptime"属性を使用することで運ばれることに注意してください。
Schulzrinne, et. al. Standards Track [Page 81] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[81ページ]RFC2326リアルタイム
C.1.5 Range of presentation
プレゼンテーションのC.1.5範囲
The "a=range" attribute defines the total time range of the stored session. (The length of live sessions can be deduced from the "t" and "r" parameters.) Unless the presentation contains media streams of different durations, the range attribute is a session-level attribute. The unit is specified first, followed by the value range. The units and their values are as defined in Section 3.5, 3.6 and 3.7.
「=は及ぶ」という属性が保存されたセッションの合計時範囲を定義します。 (「t」と「r」パラメタからライブセッションの長さを推論できます。) プレゼンテーションが異なった持続時間のメディアストリームを含んでいない場合、範囲属性はセッションレベル属性です。 値の範囲があとに続いていて、ユニットは最初に、指定されます。 ユニットとそれらの値がセクション3.5、3.6、および3.7で定義されるようにあります。
Examples:
a=range:npt=0-34.4368
a=range:clock=19971113T2115-19971113T2203
例: =範囲: npt=0-34.4368 aは範囲と等しいです: =19971113T2115-19971113T2203の時間を計ってください。
C.1.6 Time of availability
有用性のC.1.6時間
The "t=" field MUST contain suitable values for the start and stop times for both aggregate and non-aggregate stream control. With aggregate control, the server SHOULD indicate a stop time value for which it guarantees the description to be valid, and a start time that is equal to or before the time at which the DESCRIBE request was received. It MAY also indicate start and stop times of 0, meaning that the session is always available. With non-aggregate control, the values should reflect the actual period for which the session is available in keeping with SDP semantics, and not depend on other means (such as the life of the web page containing the description) for this purpose.
「t=」分野は、適当な値を始めに含んでいて、集合の、そして、非集合の両方のストリームコントロールのために回を止めなければなりません。 集合コントロールで、サーバSHOULDはそれが記述が有効であることを保証する停止時間的価値、および時代に時代かDESCRIBE要求が受け取られた前等しい開始時刻を示します。 セッションがいつも利用可能であることを意味する場合、それは、また、始めを示して、0の倍を止めるかもしれません。 非集合のコントロールで、値は、セッションが利用可能である実際の期間をSDP意味論で保つのに反映して、このために他の手段(記述を含むウェブページの寿命などの)に依存するべきではありません。
C.1.7 Connection Information
C.1.7接続情報
In SDP, the "c=" field contains the destination address for the media stream. However, for on-demand unicast streams and some multicast streams, the destination address is specified by the client via the SETUP request. Unless the media content has a fixed destination address, the "c=" field is to be set to a suitable null value. For addresses of type "IP4", this value is "0.0.0.0".
SDPでは、「c=」分野はメディアストリームのための送付先アドレスを含んでいます。 しかしながら、要求次第のユニキャストストリームといくつかのマルチキャストストリームとして、送付先アドレスはSETUP要求でクライアントによって指定されます。 メディア内容に固定送付先アドレスがない場合、「c=」分野は適当なヌル値に設定されることです。 タイプのアドレス、「IP4"、この値がそうである、「0.0 .0 0インチ、」
C.1.8 Entity Tag
C.1.8実体タグ
The optional "a=etag" attribute identifies a version of the session description. It is opaque to the client. SETUP requests may include this identifier in the If-Match field (see section 12.22) to only allow session establishment if this attribute value still corresponds to that of the current description. The attribute value is opaque and may contain any character allowed within SDP attribute values.
任意の"a=etag"属性はセッション記述のバージョンを特定します。 クライアントにとって、それは不透明です。 この属性値がまだ現在の記述のものに対応しているなら、SETUP要求は、セッション設立を許容するだけであるためにIf-マッチ分野(セクション12.22を見る)にこの識別子を含むかもしれません。 属性値は、不透明であり、SDP属性値の中に許容されたどんなキャラクタも含むかもしれません。
Example:
a=etag:158bb3e7c7fd62ce67f12b533f06b83a
例: a=etag: 158bb3e7c7fd62ce67f12b533f06b83a
Schulzrinne, et. al. Standards Track [Page 82] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[82ページ]RFC2326リアルタイム
One could argue that the "o=" field provides identical
functionality. However, it does so in a manner that would put
constraints on servers that need to support multiple session
description types other than SDP for the same piece of media
content.
1つは、「o=」分野が同じ機能性を提供すると主張するかもしれません。 しかしながら、それは同じメディア内容のためのSDP以外の複数のセッション記述タイプをサポートする必要があるサーバに規制を置く方法でそうします。
C.2 Aggregate Control Not Available
利用可能でないC.2集合コントロール
If a presentation does not support aggregate control and multiple media sections are specified, each section MUST have the control URL specified via the "a=control:" attribute.
プレゼンテーションが集合コントロールをサポートしないで、マルチメディア部が指定されるなら、各セクションは「=は以下を制御すること」を通してコントロールURLを指定させなければなりません。 結果と考えます。
Example:
v=0
o=- 2890844256 2890842807 IN IP4 204.34.34.32
s=I came from a web page
t=0 0
c=IN IP4 0.0.0.0
m=video 8002 RTP/AVP 31
a=control:rtsp://audio.com/movie.aud
m=audio 8004 RTP/AVP 3
a=control:rtsp://video.com/movie.vid
例: =-2890844256 2890842807IN IP4 204.34.34.32 s=私がウェブページtから来させたv=0oが0 0c=IN IP4と等しい、0.0、.0、.0m、オーディオの8004RTP/AVP3a=コントロール: =ビデオ8002RTP/AVP31a=コントロール: rtsp://audio.com/movie.aud m=rtsp://video.com/movie.vid
Note that the position of the control URL in the description implies that the client establishes separate RTSP control sessions to the servers audio.com and video.com.
記述におけるコントロールURLの位置が、クライアントが別々のRTSPコントロールセッションをサーバのaudio.comとvideo.comに確立するのを含意することに注意してください。
It is recommended that an SDP file contains the complete media initialization information even if it is delivered to the media client through non-RTSP means. This is necessary as there is no mechanism to indicate that the client should request more detailed media stream information via DESCRIBE.
それが非RTSP手段でメディアクライアントに提供されてもSDPファイルが完全なメディア初期化情報を含むのは、お勧めです。 クライアントが、より詳細なメディアがDESCRIBEを通して情報を流すよう要求するべきであるのを示すためにメカニズムが全くないとき、これが必要です。
C.3 Aggregate Control Available
利用可能なC.3集合コントロール
In this scenario, the server has multiple streams that can be controlled as a whole. In this case, there are both media-level "a=control:" attributes, which are used to specify the stream URLs, and a session-level "a=control:" attribute which is used as the request URL for aggregate control. If the media-level URL is relative, it is resolved to absolute URLs according to Section C.1.1 above.
このシナリオでは、サーバは全体で制御できる複数のストリームを持っています。 この場合、メディア平らな両方があります。「=は以下を制御します」。 属性。(その属性は使用されて、ストリームURL、およびセッションレベルを指定するために、「=は制御する」ということです)。 集合コントロールに要求URLとして使用される属性。 メディアレベルURLが相対的であるなら、それはセクションC.1.1に従った上の絶対URLに決議されています。
If the presentation comprises only a single stream, the media-level "a=control:" attribute may be omitted altogether. However, if the presentation contains more than one stream, each media stream section MUST contain its own "a=control" attribute.
プレゼンテーションはただ一つのストリームだけを包括して、メディアレベルは「aはコントロールと等しいです」です。 属性は全体で省略されるかもしれません。 しかしながら、プレゼンテーションが1つ以上のストリームを含んでいるなら、それぞれのメディアストリーム部はそれ自身の「=コントロール」属性を含まなければなりません。
Schulzrinne, et. al. Standards Track [Page 83] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[83ページ]RFC2326リアルタイム
Example:
v=0
o=- 2890844256 2890842807 IN IP4 204.34.34.32
s=I contain
i=<more info>
t=0 0
c=IN IP4 0.0.0.0
a=control:rtsp://example.com/movie/
m=video 8002 RTP/AVP 31
a=control:trackID=1
m=audio 8004 RTP/AVP 3
a=control:trackID=2
例: v=0o=-2890844256 2890842807IN IP4 204.34.34.32 s=私が<より多くのインフォメーション>t=0 0i=c=IN IP4を含む、0.0、.0、.0、aはコントロールと等しいです: rtsp://example.com/映画/mはオーディオの8004RTP/AVP3a=コントロール: ビデオ8002RTP/AVP31a=コントロール: trackID=1m=trackID=2と等しいです。
In this example, the client is required to establish a single RTSP session to the server, and uses the URLs rtsp://example.com/movie/trackID=1 and rtsp://example.com/movie/trackID=2 to set up the video and audio streams, respectively. The URL rtsp://example.com/movie/ controls the whole movie.
この例では、クライアントは、ビデオをセットアップするのにただ一つのRTSPセッションをサーバに確立するのが必要であり、URL rtsp://example.com/映画/trackID=1とrtsp://example.com/映画/trackID=2を使用します、そして、オーディオはそれぞれ流れます。 URL rtsp://example.com/movie/は映画全体を制御します。
Schulzrinne, et. al. Standards Track [Page 84] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[84ページ]RFC2326リアルタイム
Appendix D: Minimal RTSP implementation
付録D: 最小量のRTSP実装
D.1 Client
D.1クライアント
A client implementation MUST be able to do the following :
クライアント実装は以下ができなければなりません:
* Generate the following requests: SETUP, TEARDOWN, and one of PLAY
(i.e., a minimal playback client) or RECORD (i.e., a minimal
recording client). If RECORD is implemented, ANNOUNCE must be
implemented as well.
* Include the following headers in requests: CSeq, Connection,
Session, Transport. If ANNOUNCE is implemented, the capability to
include headers Content-Language, Content-Encoding, Content-
Length, and Content-Type should be as well.
* Parse and understand the following headers in responses: CSeq,
Connection, Session, Transport, Content-Language, Content-
Encoding, Content-Length, Content-Type. If RECORD is implemented,
the Location header must be understood as well. RTP-compliant
implementations should also implement RTP-Info.
* Understand the class of each error code received and notify the
end-user, if one is present, of error codes in classes 4xx and
5xx. The notification requirement may be relaxed if the end-user
explicitly does not want it for one or all status codes.
* Expect and respond to asynchronous requests from the server, such
as ANNOUNCE. This does not necessarily mean that it should
implement the ANNOUNCE method, merely that it MUST respond
positively or negatively to any request received from the server.
* 以下の要求を生成してください: PLAY(すなわち、最小量の再生クライアント)かRECORD(すなわち、最小量の録音クライアント)のSETUP、TEARDOWN、および1つ。 RECORDが実装されるなら、また、ANNOUNCEを実装しなければなりません。 * 要求で以下のヘッダーを含めてください: CSeq、接続、セッション、輸送。 ANNOUNCEが実装されるなら、ヘッダーContent-言語、Content-コード化、Contentの長さ、およびコンテントタイプを含む能力は同じくらい良いはずです。 * 以下のヘッダーは、応答で分析して、理解しています: CSeq(接続、セッション)は満足している言語、内容がコード化されることでのコンテンツの長さ、コンテントタイプを輸送します。 RECORDが実装されるなら、また、Locationヘッダーを理解しなければなりません。 また、RTP対応することの実装はRTP-インフォメーションを実装するべきです。 * それぞれのエラーコードのクラスが受信されたのを理解してください、そして、エンドユーザに通知してください、1つが存在しているならクラスの4xxと5xxのエラーコードで。 エンドユーザが1かすべてのステータスコードのために明らかにそれが欲しくないなら、通知要件はリラックスするかもしれません。 * ANNOUNCEなどのサーバから非同期要求に予想して、応じてください。 これは、必ずANNOUNCEメソッドを実装するべきであり、単に、明確か否定的にサーバから受け取られたどんな要求にも応じなければならないことを意味するというわけではありません。
Though not required, the following are highly recommended at the time of publication for practical interoperability with initial implementations and/or to be a "good citizen".
必要ではありませんが、以下は公表時点で、初期の実装がある実用的な相互運用性、「善良な市民」であると強く推薦されます。
* Implement RTP/AVP/UDP as a valid transport.
* Inclusion of the User-Agent header.
* Understand SDP session descriptions as defined in Appendix C
* Accept media initialization formats (such as SDP) from standard
input, command line, or other means appropriate to the operating
environment to act as a "helper application" for other
applications (such as web browsers).
* 有効な輸送としてRTP/AVP/UDPを実装してください。 * User-エージェントヘッダーの包含。 * Appendix C*で定義されるSDPセッション記述が他のアプリケーション(ウェブブラウザなどの)のための「支援アプリケーション」として機能する操作環境に適切な標準の入力、コマンドライン、または他の手段から初期化がフォーマットするメディア(SDPなどの)を受け入れるのを理解してください。
There may be RTSP applications different from those initially
envisioned by the contributors to the RTSP specification for which
the requirements above do not make sense. Therefore, the
recommendations above serve only as guidelines instead of strict
requirements.
初めは貢献者によって思い描かれたものから上記の要件が理解できないRTSP仕様まで異なったRTSP利用があるかもしれません。 したがって、単に厳しい要件の代わりにガイドラインとしてのサーブを超えた推薦。
Schulzrinne, et. al. Standards Track [Page 85] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[85ページ]RFC2326リアルタイム
D.1.1 Basic Playback
D.1.1の基本的な再生
To support on-demand playback of media streams, the client MUST
additionally be able to do the following:
* generate the PAUSE request;
* implement the REDIRECT method, and the Location header.
メディアストリームの要求次第の再生をサポートするために、クライアントはさらに、以下ができなければなりません: * PAUSE要求を生成してください。 * REDIRECTがメソッドと、Locationヘッダーであると実装してください。
D.1.2 Authentication-enabled
D.1.2は認証して可能にしました。
In order to access media presentations from RTSP servers that require
authentication, the client MUST additionally be able to do the
following:
* recognize the 401 status code;
* parse and include the WWW-Authenticate header;
* implement Basic Authentication and Digest Authentication.
認証を必要とするRTSPサーバからメディアプレゼンテーションにアクセスするために、クライアントはさらに、以下ができなければなりません: * 401ステータスコードを認識してください。 * 分析して、包含、ヘッダーをWWW認証してください。 * Basic AuthenticationとDigest Authenticationを実装してください。
D.2 Server
D.2サーバ
A minimal server implementation MUST be able to do the following:
最小量のサーバ実装は以下ができなければなりません:
* Implement the following methods: SETUP, TEARDOWN, OPTIONS and
either PLAY (for a minimal playback server) or RECORD (for a
minimal recording server). If RECORD is implemented, ANNOUNCE
should be implemented as well.
* Include the following headers in responses: Connection,
Content-Length, Content-Type, Content-Language, Content-Encoding,
Transport, Public. The capability to include the Location header
should be implemented if the RECORD method is. RTP-compliant
implementations should also implement the RTP-Info field.
* Parse and respond appropriately to the following headers in
requests: Connection, Session, Transport, Require.
* 以下のメソッドを実装してください: SETUPと、TEARDOWNと、OPTIONSとPLAY(最小量の再生サーバのための)かRECORD(最小量の録音サーバのための)のどちらか。 RECORDが実装されるなら、また、ANNOUNCEは実装されるべきです。 * 応答で以下のヘッダーを含めてください: 接続、コンテンツの長さ、コンテントタイプ、満足している言語の、そして、内容をコード化する輸送、公衆。 RECORDメソッドが実装されるなら、Locationヘッダーを含む能力は実装されるべきです。 また、RTP対応することの実装はRTP-インフォメーション分野を実装するべきです。 * 分析してください、そして、適切に要求における以下のヘッダーに応じてください: 接続、セッション、輸送が必要です。
Though not required, the following are highly recommended at the time of publication for practical interoperability with initial implementations and/or to be a "good citizen".
必要ではありませんが、以下は公表時点で、初期の実装がある実用的な相互運用性、「善良な市民」であると強く推薦されます。
* Implement RTP/AVP/UDP as a valid transport.
* Inclusion of the Server header.
* Implement the DESCRIBE method.
* Generate SDP session descriptions as defined in Appendix C
* 有効な輸送としてRTP/AVP/UDPを実装してください。 * Serverヘッダーの包含。 * DESCRIBEがメソッドであると実装してください。 * Appendix Cで定義されるようにセッション記述をSDPに生成してください。
There may be RTSP applications different from those initially
envisioned by the contributors to the RTSP specification for which
the requirements above do not make sense. Therefore, the
recommendations above serve only as guidelines instead of strict
requirements.
初めは貢献者によって思い描かれたものから上記の要件が理解できないRTSP仕様まで異なったRTSP利用があるかもしれません。 したがって、単に厳しい要件の代わりにガイドラインとしてのサーブを超えた推薦。
Schulzrinne, et. al. Standards Track [Page 86] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[86ページ]RFC2326リアルタイム
D.2.1 Basic Playback
D.2.1の基本的な再生
To support on-demand playback of media streams, the server MUST additionally be able to do the following:
メディアの要求次第の再生がストリーム、サーバであるとサポートするのがさらに、以下ができなければなりません:
* Recognize the Range header, and return an error if seeking is not
supported.
* Implement the PAUSE method.
* Rangeヘッダーを見分けてください、そして、探知がサポートされないなら、誤りを返してください。 * PAUSEがメソッドであると実装してください。
In addition, in order to support commonly-accepted user interface features, the following are highly recommended for on-demand media servers:
一般的に受け入れられたユーザーインタフェースの特徴をサポートして、さらに、以下は要求次第のメディアサーバのために強く推薦されます:
* Include and parse the Range header, with NPT units.
Implementation of SMPTE units is recommended.
* Include the length of the media presentation in the media
initialization information.
* Include mappings from data-specific timestamps to NPT. When RTP
is used, the rtptime portion of the RTP-Info field may be used to
map RTP timestamps to NPT.
* NPTユニットでRangeヘッダーを含んで、分析してください。 SMPTEユニットの実装はお勧めです。 * メディア初期化情報のメディアプレゼンテーションの長さを含めてください。 * データ特有のタイムスタンプからNPTまでのマッピングを含めてください。 RTPが使用されているとき、RTP-インフォメーション分野のrtptime部分は、RTPタイムスタンプをNPTに写像するのに使用されるかもしれません。
Client implementations may use the presence of length information
to determine if the clip is seekable, and visibly disable seeking
features for clips for which the length information is unavailable.
A common use of the presentation length is to implement a "slider
bar" which serves as both a progress indicator and a timeline
positioning tool.
クライアント実装は、クリップが「探-可能」かどうか決定するのに長さの情報の存在を使用して、長さの情報が入手できないクリップのために探知が特徴であることを明らかに無効にするかもしれません。 プレゼンテーションの長さの一般の使用は進歩インディケータとスケジュール位置決めツールの両方として機能する「スライダーバー」を実装することです。
Mappings from RTP timestamps to NPT are necessary to ensure correct
positioning of the slider bar.
RTPタイムスタンプからNPTまでのマッピングが、スライダーバーの正しい位置決めを確実にするのに必要です。
D.2.2 Authentication-enabled
D.2.2は認証して可能にしました。
In order to correctly handle client authentication, the server MUST additionally be able to do the following:
正しくクライアント認証を扱うために、サーバはさらに、以下ができなければなりません:
* Generate the 401 status code when authentication is required for
the resource.
* Parse and include the WWW-Authenticate header
* Implement Basic Authentication and Digest Authentication
* 認証がリソースに必要であったら401状態がコードであると生成してください。 * 分析して、包含、ヘッダー*の道具Basic AuthenticationとDigest AuthenticationをWWW認証してください。
Schulzrinne, et. al. Standards Track [Page 87] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[87ページ]RFC2326リアルタイム
Appendix E: Authors' Addresses
付録E: 作者のアドレス
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenueニューヨーク10027ニューヨーク(米国)のヘニングSchulzrinne部
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Anup Rao Netscape Communications Corp. 501 E. Middlefield Road Mountain View, CA 94043 USA
Anupラオネットスケープ・コミュニケーションズ501E.Middlefield Roadカリフォルニア94043マウンテンビュー(米国)
EMail: anup@netscape.com
メール: anup@netscape.com
Robert Lanphier RealNetworks 1111 Third Avenue Suite 2900 Seattle, WA 98101 USA
ロバートLanphierリアルネットワークス1111第3アベニュースイート2900ワシントン98101シアトル(米国)
EMail: robla@real.com
メール: robla@real.com
Schulzrinne, et. al. Standards Track [Page 88] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[88ページ]RFC2326リアルタイム
Appendix F: Acknowledgements
付録F: 承認
This memo is based on the functionality of the original RTSP document submitted in October 96. It also borrows format and descriptions from HTTP/1.1.
このメモは10月96日に提出されたオリジナルのRTSPドキュメントの機能性に基づいています。 また、それはHTTP/1.1から形式と記述を借ります。
This document has benefited greatly from the comments of all those participating in the MMUSIC-WG. In addition to those already mentioned, the following individuals have contributed to this specification:
このドキュメントは大いにMMUSIC-WGに参加するすべてのもののコメントの利益を得ました。 既に言及されたものに加えて、以下の個人はこの仕様に貢献しました:
Rahul Agarwal, Torsten Braun, Brent Browning, Bruce Butterfield, Steve Casner, Francisco Cortes, Kelly Djahandari, Martin Dunsmuir, Eric Fleischman, Jay Geagan, Andy Grignon, V. Guruprasad, Peter Haight, Mark Handley, Brad Hefta-Gaub, John K. Ho, Philipp Hoschka, Anne Jones, Anders Klemets, Ruth Lang, Stephanie Leif, Jonathan Lennox, Eduardo F. Llach, Rob McCool, David Oran, Maria Papadopouli, Sujal Patel, Ema Patki, Alagu Periyannan, Igor Plotnikov, Pinaki Shah, David Singer, Jeff Smith, Alexander Sokolsky, Dale Stammen, and John Francis Stracke.
Rahul Agarwal、Torstenブラウン、ブレント褐色着色剤、ブルース・バターフィールド、スティーブCasner、フランシスココルテス、ケリーDjahandari、マーチン・ダンスミュア、エリック・フライシュマン、ジェイGeagan、アンディGrignon、V.Guruprasad(ピーターヘイト)はハンドレーをマークします、ブラッドHefta-Gaub、ジョンK; おーい、イーゴリのデヴィッド歌手(ジェフ・スミス)のフィリップHoschka、アン・ジョーンズ、アンダースKlemets、ルース・ラング、ステファニー・リーフ、ジョナサンレノックス、エドゥアルドF.Llach、ロブMcCool、デヴィッド・オラン、マリアPapadopouli、Sujalパテル、Ema Patki、Alagu Periyannan、プロトニコフ、Pinakiシャー、アレクサンダーSokolsky、デールStammen、およびジョンフランシスStracke。
Schulzrinne, et. al. Standards Track [Page 89] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[89ページ]RFC2326リアルタイム
References
参照
1 Schulzrinne, H., "RTP profile for audio and video conferences
with minimal control", RFC 1890, January 1996.
1 Schulzrinne、H.、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC1890、1996年1月。
2 Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext transfer protocol - HTTP/1.1", RFC
2068, January 1997.
2フィールディング、R.、Gettys、J.、ムガール人、J.、ニールセン、H.、およびT.バーナーズ・リー、「ハイパーテキスト転送は議定書を作ります--HTTP/1.1インチ、RFC2068、1997年1月。」
3 Yergeau, F., Nicol, G., Adams, G., and M. Duerst,
"Internationalization of the hypertext markup language", RFC
2070, January 1997.
3 1997年1月のYergeauとF.とニコルとG.とアダムス、G.とM.Duerst、「ハイパーテキストマークアップ言語の国際化」RFC2070。
4 Bradner, S., "Key words for use in RFCs to indicate
requirement levels", BCP 14, RFC 2119, March 1997.
4 ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
5 ISO/IEC, "Information technology - generic coding of moving
pictures and associated audio information - part 6: extension
for digital storage media and control," Draft International
Standard ISO 13818-6, International Organization for
Standardization ISO/IEC JTC1/SC29/WG11, Geneva, Switzerland,
Nov. 1995.
5 ISO/IEC、「情報技術(映画と関連オーディオ情報の一般的なコード化)は6を分けます」。 「デジタル蓄積メディアとコントロールのための拡大」、国際規格案ISO13818-6(WG11、国際標準化機構ISO/IEC JTC1/SC29/ジュネーブ(スイス)1995年11月)。
6 Handley, M., and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
6 ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
7 Franks, J., Hallam-Baker, P., and J. Hostetler, "An extension to
HTTP: digest access authentication", RFC 2069, January 1997.
7 フランクス、J.、ハラム-ベイカー、P.、およびJ.Hostetler、「HTTPへの拡大:」 「ダイジェストアクセス認証」、RFC2069、1997年1月。
8 Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
8 ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
9 Hinden, B. and C. Partridge, "Version 2 of the reliable data
protocol (RDP)", RFC 1151, April 1990.
9 HindenとB.とC.Partridge、「確実な資料プロトコル(RDP)のバージョン2」、RFC1151、1990年4月。
10 Postel, J., "Transmission control protocol", STD 7, RFC 793,
September 1981.
10 ポステル、J.、「トランスミッション制御プロトコル」、STD7、RFC793、1981年9月。
11 H. Schulzrinne, "A comprehensive multimedia control
architecture for the Internet," in Proc. International
Workshop on Network and Operating System Support for Digital
Audio and Video (NOSSDAV), (St. Louis, Missouri), May 1997.
11 H.Schulzrinne、Procで「包括的なマルチメディアはインターネットに構造を制御します」。 ネットワークに関する国際ワークショップとデジタル・オーディオのオペレーティングシステムサポートとビデオ(NOSSDAV)、(セントルイス(ミズーリ))は1997がそうするかもしれません。
12 International Telecommunication Union, "Visual telephone
systems and equipment for local area networks which provide a
non-guaranteed quality of service," Recommendation H.323,
Telecommunication Standardization Sector of ITU, Geneva,
Switzerland, May 1996.
12 国際電気通信連合、「展示はサービスの非保証品質を提供するローカル・エリア・ネットワークのためにシステムと設備に電話をします」、Recommendation H.323、ITUのTelecommunication Standardization Sector、ジュネーブ(スイス)1996年5月。
Schulzrinne, et. al. Standards Track [Page 90] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[90ページ]RFC2326リアルタイム
13 McMahon, P., "GSS-API authentication method for SOCKS version
5", RFC 1961, June 1996.
13 マクマホン、P.、「SOCKSのためのGSS-API認証方法、バージョン5インチ、RFC1961、1996インチ年6月。
14 J. Miller, P. Resnick, and D. Singer, "Rating services and
rating systems (and their machine readable descriptions),"
Recommendation REC-PICS-services-961031, W3C (World Wide Web
Consortium), Boston, Massachusetts, Oct. 1996.
14 J.ミラー、P.レズニック、およびD.Singer、「サービスと格付けがシステム(そして、彼らのマシンの読み込み可能な記述)であると評定し」て、Recommendation REC-PICSは961031を修理します、W3C(ワールドワイドウェブコンソーシアム)、ボストン(マサチューセッツ)1996年10月。
15 J. Miller, T. Krauskopf, P. Resnick, and W. Treese, "PICS
label distribution label syntax and communication protocols,"
Recommendation REC-PICS-labels-961031, W3C (World Wide Web
Consortium), Boston, Massachusetts, Oct. 1996.
15 J.ミラー、T.Krauskopf、P.レズニック、およびW.Treese、「PICSはラベル構文と通信プロトコルと分配をラベルします」、Recommendation REC-PICSラベル961031、W3C(ワールドワイドウェブコンソーシアム)、ボストン(マサチューセッツ)1996年10月。
16 Crocker, D. and P. Overell, "Augmented BNF for syntax
specifications: ABNF", RFC 2234, November 1997.
16 クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
17 Braden, B., "Requirements for internet hosts - application and
support", STD 3, RFC 1123, October 1989.
17 ブレーデン、B.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
18 Elz, R., "A compact representation of IPv6 addresses", RFC
1924, April 1996.
18 Elz、1996年4月のR.、「IPv6アドレスのコンパクトな表現」RFC1924。
19 Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
resource locators (URL)", RFC 1738, December 1994.
19 バーナーズ・リーとT.とMasinterとL.とM.McCahill、「一定のリソースロケータ(URL)」、RFC1738、1994年12月。
20 Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
20 Yergeau、1998年1月のF.、「UTF-8、ISO10646の変化形式」RFC2279。
22 Braden, B., "T/TCP - TCP extensions for transactions
functional specification", RFC 1644, July 1994.
22 ブレーデン、B.、「T/TCP--、取引に、機能的なTCP拡張子、仕様、」、RFC1644、7月1994日
22 W. R. Stevens, TCP/IP illustrated: the implementation, vol. 2.
Reading, Massachusetts: Addison-Wesley, 1994.
22w.R.スティーブンス、TCP/IPは例証しました: 実現、vol.2。 読書、マサチューセッツ: アディソン-ウエスリー、1994。
23 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: a transport protocol for real-time applications", RFC
1889, January 1996.
23 Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
24 Fielding, R., "Relative uniform resource locators", RFC 1808,
June 1995.
24フィールディング、R.、「相対的な一定のリソースロケータ」、RFC1808、1995年6月。
Schulzrinne, et. al. Standards Track [Page 91] RFC 2326 Real Time Streaming Protocol April 1998
et Schulzrinne、アル。 プロトコル1998年4月に流れる標準化過程[91ページ]RFC2326リアルタイム
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Schulzrinne, et. al. Standards Track [Page 92]
et Schulzrinne、アル。 標準化過程[92ページ]
一覧
スポンサーリンク
