RFC4566 日本語訳
4566 SDP: Session Description Protocol. M. Handley, V. Jacobson, C.Perkins. July 2006. (Format: TXT=108820 bytes) (Obsoletes RFC2327, RFC3266) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Handley
Request for Comments: 4566 UCL
Obsoletes: 2327, 3266 V. Jacobson
Category: Standards Track Packet Design
C. Perkins
University of Glasgow
July 2006
コメントを求めるワーキンググループM.ハンドレー要求をネットワークでつないでください: 4566UCLは以下を時代遅れにします。 2327、3266V.ジェーコブソンカテゴリ: 規格は2006年7月にグラスゴーのパケットデザインC.パーキンス大学を追跡します。
SDP: Session Description Protocol
SDP: セッション記述プロトコル
Status of This 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 (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation.
このメモはSession記述プロトコル(SDP)を定義します。 SDPは、セッション発表(セッション招待、および他の形式のマルチメディアセッション開始)の目的のためのマルチメディアセッションについて説明するために意図します。
Table of Contents
目次
1. Introduction ....................................................3
2. Glossary of Terms ...............................................3
3. Examples of SDP Usage ...........................................4
3.1. Session Initiation .........................................4
3.2. Streaming Media ............................................4
3.3. Email and the World Wide Web ...............................4
3.4. Multicast Session Announcement .............................4
4. Requirements and Recommendations ................................5
4.1. Media and Transport Information ............................6
4.2. Timing Information .........................................6
4.3. Private Sessions ...........................................7
4.4. Obtaining Further Information about a Session ..............7
4.5. Categorisation .............................................7
4.6. Internationalisation .......................................7
1. 序論…3 2. 用語の用語集…3 3. SDP用法に関する例…4 3.1. セッション開始…4 3.2. メディアを流します…4 3.3. メールとWWW…4 3.4. マルチキャストセッション発表…4 4. 要件と推薦…5 4.1. メディアと輸送情報…6 4.2. タイミング情報…6 4.3. 個人的なセッション…7 4.4. セッション頃に詳細を得ます…7 4.5. 分類…7 4.6. 国際化…7
Handley, et al. Standards Track [Page 1] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[1ページ]。
5. SDP Specification ...............................................7
5.1. Protocol Version ("v=") ...................................10
5.2. Origin ("o=") .............................................11
5.3. Session Name ("s=") .......................................12
5.4. Session Information ("i=") ................................12
5.5. URI ("u=") ................................................13
5.6. Email Address and Phone Number ("e=" and "p=") ............13
5.7. Connection Data ("c=") ....................................14
5.8. Bandwidth ("b=") ..........................................16
5.9. Timing ("t=") .............................................17
5.10. Repeat Times ("r=") ......................................18
5.11. Time Zones ("z=") ........................................19
5.12. Encryption Keys ("k=") ...................................19
5.13. Attributes ("a=") ........................................21
5.14. Media Descriptions ("m=") ................................22
6. SDP Attributes .................................................24
7. Security Considerations ........................................31
8. IANA Considerations ............................................33
8.1. The "application/sdp" Media Type ..........................33
8.2. Registration of Parameters ................................34
8.2.1. Media Types ("media") ..............................34
8.2.2. Transport Protocols ("proto") ......................34
8.2.3. Media Formats ("fmt") ..............................35
8.2.4. Attribute Names ("att-field") ......................36
8.2.5. Bandwidth Specifiers ("bwtype") ....................37
8.2.6. Network Types ("nettype") ..........................37
8.2.7. Address Types ("addrtype") .........................38
8.2.8. Registration Procedure .............................38
8.3. Encryption Key Access Methods .............................39
9. SDP Grammar ....................................................39
10. Summary of Changes from RFC 2327 ..............................44
11. Acknowledgements ..............................................45
12. References ....................................................45
12.1. Normative References .....................................45
12.2. Informative References ...................................46
5. SDP仕様…7 5.1. バージョン(「=」への)について議定書の中で述べてください…10 5.2. 発生源(「o=」)…11 5.3. セッション名(「s=」)…12 5.4. セッション情報(「i=」)…12 5.5. URI(「u=」)…13 5.6. Eメールアドレスと電話番号(「e=」と「p=」)…13 5.7. 接続データ(「c=」)…14 5.8. 帯域幅(「b=」)…16 5.9. タイミング(「t=」)…17 5.10. 回(「r=」)を繰り返してください…18 5.11. 時間帯(「z=」)…19 5.12. 暗号化キー(「k=」)…19 5.13. 属性(「=」)…21 5.14. メディア記述(「m=」)…22 6. SDP属性…24 7. セキュリティ問題…31 8. IANA問題…33 8.1. 「アプリケーション/sdp」メディアタイプ…33 8.2. パラメタの登録…34 8.2.1. メディアは(「メディア」)をタイプします…34 8.2.2. プロトコル("proto")を輸送してください…34 8.2.3. メディアは("fmt")をフォーマットします…35 8.2.4. 名前(「att-分野」)を結果と考えてください…36 8.2.5. 帯域幅特許説明書の作成書("bwtype")…37 8.2.6. タイプ("nettype")をネットワークでつないでください…37 8.2.7. アドレスは("addrtype")をタイプします…38 8.2.8. 登録手順…38 8.3. 暗号化の主要なアクセス法…39 9. SDP文法…39 10. RFC2327からの変化の概要…44 11. 承認…45 12. 参照…45 12.1. 標準の参照…45 12.2. 有益な参照…46
Handley, et al. Standards Track [Page 2] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[2ページ]。
1. Introduction
1. 序論
When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants.
マルチメディア電子会議を開始するとき、ナレーターの声IPは電話をします、ストリーミング・ビデオ、または他のセッションに、メディアの詳細、輸送アドレス、および他のセッション記述メタデータを関係者に伝えるという要件があります。
SDP provides a standard representation for such information, irrespective of how that information is transported. SDP is purely a format for session description -- it does not incorporate a transport protocol, and it is intended to use different transport protocols as appropriate, including the Session Announcement Protocol [14], Session Initiation Protocol [15], Real Time Streaming Protocol [16], electronic mail using the MIME extensions, and the Hypertext Transport Protocol.
その情報がどう輸送されるかの如何にかかわらずSDPはそのような情報の標準の表現を提供します。 SDPは純粋にセッション記述のための形式です--トランスポート・プロトコルを取り入れません、そして、適宜異なったトランスポート・プロトコルを使用するのは意図しています、Session Announcementプロトコル[14]、Session Initiationプロトコル[15]、レアルTime Streamingプロトコル[16]、MIME拡張子を使用する電子メール、およびハイパーテキストTransportプロトコルを含んでいて。
SDP is intended to be general purpose so that it can be used in a wide range of network environments and applications. However, it is not intended to support negotiation of session content or media encodings: this is viewed as outside the scope of session description.
SDPがさまざまなネットワーク環境とアプリケーションでそれを使用できるように汎用であることを意図します。 しかしながら、セッション内容かメディアencodingsの交渉をサポートすることを意図しません: これはセッション記述の範囲のように見られます。
This memo obsoletes RFC 2327 [6] and RFC 3266 [10]. Section 10 outlines the changes introduced in this memo.
このメモはRFC2327[6]とRFC3266[10]を時代遅れにします。 セクション10はこのメモで導入された変化について概説します。
2. Glossary of Terms
2. 用語の用語集
The following terms are used in this document and have specific meaning within the context of this document.
次の用語は、本書では使用されて、このドキュメントの文脈の中に特定の意味を持っています。
Conference: A multimedia conference is a set of two or more
communicating users along with the software they are using to
communicate.
コンファレンス: マルチメディア会議は交信するために彼らが使用しているソフトウェアに伴うユーザを伝える2人以上のセット以上です。
Session: A multimedia session is a set of multimedia senders and
receivers and the data streams flowing from senders to receivers.
A multimedia conference is an example of a multimedia session.
セッション: マルチメディアセッションは、1セットのマルチメディア送付者と受信機と送付者から受信機まで流れるデータ・ストリームです。 マルチメディア会議はマルチメディアセッションに関する例です。
Session Description: A well-defined format for conveying sufficient
information to discover and participate in a multimedia session.
セッション記述: マルチメディアセッションのときに発見して、参加するために十分な情報を伝えるための明確な形式。
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 [3].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[3]で説明されるように本書では解釈されることであるべきですか?
Handley, et al. Standards Track [Page 3] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[3ページ]。
3. Examples of SDP Usage
3. SDP用法に関する例
3.1. Session Initiation
3.1. セッション開始
The Session Initiation Protocol (SIP) [15] is an application-layer control protocol for creating, modifying, and terminating sessions such as Internet multimedia conferences, Internet telephone calls, and multimedia distribution. The SIP messages used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. These session descriptions are commonly formatted using SDP. When used with SIP, the offer/answer model [17] provides a limited framework for negotiation using SDP.
Session Initiationプロトコル(SIP)[15]はインターネットマルチメディア会議などのセッション、インターネット通話を作成して、変更して、終えるための応用層制御プロトコルと、マルチメディア分配です。 セッションを作成するのに使用されるSIPメッセージは関係者が1セットのコンパチブルメディアタイプに同意できるセッション記述を運びます。 これらのセッション記述は、SDPを使用することで一般的にフォーマットされます。 SIPと共に使用されると、申し出/答えモデル[17]は、SDPを使用することで限られたフレームワークを交渉に提供します。
3.2. Streaming Media
3.2. ストリーミング・メディア
The Real Time Streaming Protocol (RTSP) [16], 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. An RTSP client and server negotiate an appropriate set of parameters for media delivery, partially using SDP syntax to describe those parameters.
レアルTime Streamingプロトコル(RTSP)[16]はリアルタイムの特性があるデータの配送のコントロールのためのアプリケーションレベルプロトコルです。 RTSPは、オーディオやビデオなどのリアルタイムデータの制御されて、要求次第の配送を可能にするために広げることができるフレームワークを提供します。 RTSPクライアントとサーバはメディア配送のための適切なセットのパラメタを交渉します、それらのパラメタについて説明するのにSDP構文を部分的に使用して。
3.3. Email and the World Wide Web
3.3. メールとWWW
Alternative means of conveying session descriptions include electronic mail and the World Wide Web (WWW). For both email and WWW distribution, the media type "application/sdp" is used. This enables the automatic launching of applications for participation in the session from the WWW client or mail reader in a standard manner.
セッション記述を伝える代替の手段は電子メールとWWW(WWW)を含んでいます。 メールとWWW分配、メディアの両方に関しては、タイプ「アプリケーション/sdp」は使用されています。 これはWWWクライアントかメール読者から標準の方法でセッションにおける参加のアプリケーションの自動発射を可能にします。
Note that announcements of multicast sessions made only via email or the WWW do not have the property that the receiver of a session announcement can necessarily receive the session because the multicast sessions may be restricted in scope, and access to the WWW server or reception of email is possible outside this scope.
マルチキャストセッションが範囲で制限されるかもしれないのでセッション発表の受信機が必ずそうすることができる特性がメールかWWWを通してだけされたマルチキャストセッションの発表でセッションを受けないで、メールのWWWサーバかレセプションへのアクセスがこの範囲の外で可能であることに注意してください。
3.4. Multicast Session Announcement
3.4. マルチキャストセッション発表
In order to assist the advertisement of multicast multimedia conferences and other multicast sessions, and to communicate the relevant session setup information to prospective participants, a distributed session directory may be used. An instance of such a session directory periodically sends packets containing a description of the session to a well-known multicast group. These advertisements are received by other session directories such that potential remote participants can use the session description to start the tools required to participate in the session.
マルチキャストマルチメディア会議と他のマルチキャストセッションの広告を促進して、関連セッションセットアップ情報を参加予定者に伝えるために、分配されたセッションディレクトリは使用されるかもしれません。 そのようなセッションディレクトリのインスタンスは定期的によく知られるマルチキャストグループにセッションの記述を含むパケットを送ります。 他のセッションディレクトリは、潜在的リモート関係者がセッションのときに参加するのに必要であるツールを始めるのにセッション記述を使用できるように、これらの広告を受け取ります。
Handley, et al. Standards Track [Page 4] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[4ページ]。
One protocol used to implement such a distributed directory is the Session Announcement Protocol (SAP) [14]. SDP provides the recommended session description format for such session announcements.
そのような分配されたディレクトリを実装するのに使用される1つのプロトコルがSession Announcementプロトコル(SAP)[14]です。 SDPはそのようなセッション発表のために記述形式をお勧めのセッションに提供します。
4. Requirements and Recommendations
4. 要件と推薦
The purpose of SDP is to convey information about media streams in multimedia sessions to allow the recipients of a session description to participate in the session. SDP is primarily intended for use in an internetwork, although it is sufficiently general that it can describe conferences in other network environments. Media streams can be many-to-many. Sessions need not be continually active.
SDPの目的はマルチメディアセッションのときにセッション記述の受取人がセッションのときに参加するのを許容するためにメディアストリームに関して情報を伝達することです。 SDPはインターネットワークにおける使用のために主として意図します、他のネットワーク環境における会議について説明できるのが、十分一般的ですが。 メディアストリームは多くに多くであるかもしれません。 セッションは絶えず活発である必要はありません。
Thus far, multicast-based sessions on the Internet have differed from many other forms of conferencing in that anyone receiving the traffic can join the session (unless the session traffic is encrypted). In such an environment, SDP serves two primary purposes. It is a means to communicate the existence of a session, and it is a means to convey sufficient information to enable joining and participating in the session. In a unicast environment, only the latter purpose is likely to be relevant.
これまでのところ、インターネットのマルチキャストベースのセッションはトラフィックを受けるだれでもセッションに参加できるという(セッショントラフィックが暗号化されていない場合)点において他の多くのフォームの会議と異なっていました。 そのような環境で、SDPは2つのプライマリ目的に役立ちます。 それはセッションの存在を伝える手段です、そして、可能にするセッションのときに接合して、参加する十分な情報を伝える手段です。 ユニキャスト環境で、後者の目的だけが関連している傾向があります。
An SDP session description includes the following:
SDPセッション記述は以下を含んでいます:
o Session name and purpose
o セッション名と目的
o Time(s) the session is active
o (s) セッションが活発である時
o The media comprising the session
o セッションを包括するメディア
o Information needed to receive those media (addresses, ports,
formats, etc.)
o 情報は、それらのメディアを受け取る必要がありました。(アドレス、ポート、形式など)
As resources necessary to participate in a session may be limited, some additional information may also be desirable:
会議に参加するのに必要なリソースが制限されるかもしれないので、また、何らかの追加情報も望ましいかもしれません:
o Information about the bandwidth to be used by the session
o セッションで使用されるべき帯域幅に関する情報
o Contact information for the person responsible for the session
o セッションに責任がある人への問い合わせ先
In general, SDP must convey sufficient information to enable applications to join a session (with the possible exception of encryption keys) and to announce the resources to be used to any non-participants that may need to know. (This latter feature is primarily useful when SDP is used with a multicast session announcement protocol.)
一般に、SDPは、アプリケーションがセッション(暗号化キーの可能な例外がある)に参加して、知る必要があるかもしれないどんな非関係者にも使用されるためにリソースを示すのを可能にするために十分な情報を伝えなければなりません。 (SDPがマルチキャストセッション発表プロトコルと共に使用されるとき、この後者の特徴は主として役に立ちます。)
Handley, et al. Standards Track [Page 5] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[5ページ]。
4.1. Media and Transport Information
4.1. メディアと輸送情報
An SDP session description includes the following media information:
SDPセッション記述は以下のメディア情報を含んでいます:
o The type of media (video, audio, etc.)
o メディアのタイプ(ビデオ、オーディオなど)
o The transport protocol (RTP/UDP/IP, H.320, etc.)
o トランスポート・プロトコル(RTP/UDP/IP、H.320など)
o The format of the media (H.261 video, MPEG video, etc.)
o メディアの形式(H.261ビデオ、MPEGビデオなど)
In addition to media format and transport protocol, SDP conveys address and port details. For an IP multicast session, these comprise:
メディア形式とトランスポート・プロトコルに加えて、SDPはアドレスとポートの詳細を伝えます。 IPマルチキャストセッションのために、これらは以下を包括します。
o The multicast group address for media
o メディアのためのマルチキャストグループアドレス
o The transport port for media
o メディアのための輸送ポート
This address and port are the destination address and destination port of the multicast stream, whether being sent, received, or both.
このアドレスとポートは、マルチキャストストリームの送付先アドレスと仕向港です、受け取って、送るか、または両方であることにかかわらず。
For unicast IP sessions, the following are conveyed:
ユニキャストIPセッションのために、以下は運ばれます:
o The remote address for media
o メディアに、リモートなアドレス
o The remote transport port for media
o メディアにおいて、遠く離れた輸送ポート
The semantics of this address and port depend on the media and transport protocol defined. By default, this SHOULD be the remote address and remote port to which data is sent. Some media types may redefine this behaviour, but this is NOT RECOMMENDED since it complicates implementations (including middleboxes that must parse the addresses to open Network Address Translation (NAT) or firewall pinholes).
このアドレスとポートの意味論はプロトコルが定義したメディアと輸送に頼っています。 デフォルトで、このSHOULD、データが送られるリモートアドレスと遠く離れたポートになってください。 何人かのメディアタイプがこのふるまいを再定義するかもしれませんが、実装(Network Address Translation(NAT)かファイアウォールピンホールを開くためにアドレスを分析しなければならないmiddleboxesを含んでいる)を複雑にするので、これはNOT RECOMMENDEDです。
4.2. Timing Information
4.2. タイミング情報
Sessions may be either bounded or unbounded in time. Whether or not they are bounded, they may be only active at specific times. SDP can convey:
セッションは、時間内に、バウンドしているか、または限りないかもしれません。 境界があるか否かに関係なく、それらは単に特定の時にアクティブであるかもしれません。 SDPは以下を運ぶことができます。
o An arbitrary list of start and stop times bounding the session
o 始めの任意のリストと停止回の制限はセッションです。
o For each bound, repeat times such as "every Wednesday at 10am for
one hour"
o 各バウンドには、「1時間の毎週水曜日の午前10時」などの倍を繰り返してください。
This timing information is globally consistent, irrespective of local time zone or daylight saving time (see Section 5.9).
このタイミング情報は現地時間のゾーンか夏時間の如何にかかわらずグローバルに一貫しています(セクション5.9を見てください)。
Handley, et al. Standards Track [Page 6] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[6ページ]。
4.3. Private Sessions
4.3. 個人的なセッション
It is possible to create both public sessions and private sessions. SDP itself does not distinguish between these; private sessions are typically conveyed by encrypting the session description during distribution. The details of how encryption is performed are dependent on the mechanism used to convey SDP; mechanisms are currently defined for SDP transported using SAP [14] and SIP [15], and others may be defined in the future.
公共のセッションと個人的なセッションの両方を作成するのは可能です。 SDP自身はこれらを見分けません。 個人的なセッションは、分配の間、セッション記述を暗号化することによって、通常伝えられます。 暗号化がどう実行されるかに関する詳細はSDPを運ぶのに使用されるメカニズムに依存しています。 メカニズムは現在SAP[14]とSIP[15]を使用することで輸送されたSDPのために定義されます、そして、他のものは将来、定義されるかもしれません。
If a session announcement is private, it is possible to use that private announcement to convey encryption keys necessary to decode each of the media in a conference, including enough information to know which encryption scheme is used for each media.
セッション発表が個人的であるなら、会議でそれぞれのメディアを解読するのに必要な暗号化キーを運ぶのにその個人的な発表を使用するのは可能です、どの暗号化体系がそれぞれに使用されるかを知ることができるくらいの情報を含んでいて。メディア。
4.4. Obtaining Further Information about a Session
4.4. セッション頃に詳細を得ます。
A session description should convey enough information to decide whether or not to participate in a session. SDP may include additional pointers in the form of Uniform Resource Identifiers (URIs) for more information about the session.
セッション記述は会議に参加するかどうか決めることができるくらいの情報を伝えるべきです。 SDPはセッション頃に詳しい情報のためのUniform Resource Identifier(URI)の形に追加指針を含むかもしれません。
4.5. Categorisation
4.5. 分類
When many session descriptions are being distributed by SAP, or any other advertisement mechanism, it may be desirable to filter session announcements that are of interest from those that are not. SDP supports a categorisation mechanism for sessions that is capable of being automated (the "a=cat:" attribute; see Section 6).
多くのセッション記述がSAP、またはいかなる他の広告メカニズムによっても広げられているとき、そうしないそれらから興味があるセッション発表をフィルターにかけるのは望ましいかもしれません。 SDPはセッションのための自動化されることができる分類メカニズムをサポートします(「aは猫と等しい」という属性; セクション6を見てください)。
4.6. Internationalisation
4.6. 国際化
The SDP specification recommends the use of the ISO 10646 character sets in the UTF-8 encoding [5] to allow many different languages to be represented. However, to assist in compact representations, SDP also allows other character sets such as ISO 8859-1 to be used when desired. Internationalisation only applies to free-text fields (session name and background information), and not to SDP as a whole.
SDP仕様は、[5]をコード化するUTF-8におけるISO10646文字集合の使用が、多くの異なった言語が表されるのを許容することを勧めます。 しかしながら、コンパクトな表現を助けるために、また、望まれていると、SDPは、ISO8859-1などの他の文字集合が使用されるのを許容します。 国際化は全体でSDPではなく、無料のテキストフィールド(セッション名と基礎的な情報)に適用されるだけです。
5. SDP Specification
5. SDP仕様
An SDP session description is denoted by the media type "application/sdp" (See Section 8).
SDPセッション記述はメディアタイプ「アプリケーション/sdp」によって指示されます(セクション8を見てください)。
An SDP session description is entirely textual using the ISO 10646 character set in UTF-8 encoding. SDP field names and attribute names use only the US-ASCII subset of UTF-8, but textual fields and attribute values MAY use the full ISO 10646 character set. Field and
SDPセッション記述は、UTF-8コード化にISO10646文字集合を使用することで完全に原文です。 SDPフィールド名と属性名はUTF-8の米国-ASCII部分集合だけを使用しますが、原文の分野と属性値は完全なISO10646文字集合を使用するかもしれません。 そして分野。
Handley, et al. Standards Track [Page 7] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[7ページ]。
attribute values that use the full UTF-8 character set are never directly compared, hence there is no requirement for UTF-8 normalisation. The textual form, as opposed to a binary encoding such as ASN.1 or XDR, was chosen to enhance portability, to enable a variety of transports to be used, and to allow flexible, text-based toolkits to be used to generate and process session descriptions. However, since SDP may be used in environments where the maximum permissible size of a session description is limited, the encoding is deliberately compact. Also, since announcements may be transported via very unreliable means or damaged by an intermediate caching server, the encoding was designed with strict order and formatting rules so that most errors would result in malformed session announcements that could be detected easily and discarded. This also allows rapid discarding of encrypted session announcements for which a receiver does not have the correct key.
完全なUTF-8文字集合を使用する属性値が直接決して比較されません、したがって、UTF-8正常化のための要件が全くありません。 ASN.1かXDRとしてそのようなものをコード化するバイナリーと対照的に、機能アップの移植性は、さまざまな輸送が、フレキシブルで、テキストベースのツールキットがセッション記述を生成して、処理するのに使用されるのを使用されて、許容するのを可能にするために原文のフォームに選ばれました。 しかしながら、SDPがセッション記述の最大の許されているサイズが限られている環境で使用されるかもしれないので、コード化は故意にコンパクトです。 また、発表は全く頼り無い手段で輸送されるか、または中間的キャッシュサーバによって破損させられるかもしれないのでコード化が厳しい注文と形式規則で設計されたので、ほとんどの誤りが容易に検出して、捨てることができた奇形のセッション発表をもたらすでしょう。 また、これは受信機には正しいキーがない暗号化されたセッション発表を急速な捨てることを許します。
An SDP session description consists of a number of lines of text of the form:
SDPセッション記述はフォームの原本の多くの系列から成ります:
<type>=<value>
<タイプ>は<値の>と等しいです。
where <type> MUST be exactly one case-significant character and <value> is structured text whose format depends on <type>. In general, <value> is either a number of fields delimited by a single space character or a free format string, and is case-significant unless a specific field defines otherwise. Whitespace MUST NOT be used on either side of the "=" sign.
<タイプ>がどこのまさに1つのケース重要なキャラクタと<価値の>であるに違いないかは形式を<タイプ>に依存する構造化されたテキストです。 一般に、<値の>がシングルスペースキャラクタによって区切られた多くの分野かフリー・フォーマットストリングのどちらかであり、ケース重要である、そうでなければ、特定の分野は定義します。 「=」サインのどちらの側面でも空白を使用してはいけません。
An SDP session description consists of a session-level section followed by zero or more media-level sections. The session-level part starts with a "v=" line and continues to the first media-level section. Each media-level section starts with an "m=" line and continues to the next media-level section or end of the whole session description. In general, session-level values are the default for all media unless overridden by an equivalent media-level value.
SDPセッション記述はゼロがあとに続いたセッションレベル部か、よりメディア平らなセクションから成ります。 セッションレベル部分は、「v=」系列から始まって、最初のメディアレベル部に続きます。 それぞれのメディアレベル部は、「m=」系列から始まって、全体のセッション記述の次のメディアレベル部か終わりまで続きます。 一般に、同等なメディアレベル値によってくつがえされない場合、セッションレベル値はすべてのメディアのためのデフォルトです。
Some lines in each description are REQUIRED and some are OPTIONAL, but all MUST appear in exactly the order given here (the fixed order greatly enhances error detection and allows for a simple parser). OPTIONAL items are marked with a "*".
各記述におけるいくつかの系列がREQUIREDです、そして、何かがOPTIONALですが、すべてがまさにここに与えられたオーダーに現れなければなりません(固定オーダーは、誤り検出を大いに機能アップして、簡単なパーサを考慮します)。 OPTIONALの品目は「*」でマークされます。
Handley, et al. Standards Track [Page 8] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[8ページ]。
Session description
v= (protocol version)
o= (originator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information -- not required if included in
all media)
b=* (zero or more bandwidth information lines)
One or more time descriptions ("t=" and "r=" lines; see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions
セッション..記述..プロトコル..バージョン..創始者..セッション..識別子..セッション..名前..セッション..情報..URI..記述..Eメールアドレス..電話番号..接続..情報..必要..含む..メディア..零点..多い..帯域幅..情報..系列..以上..時間..記述..立ち並ぶ..見る..以下に..時間帯..調整..暗号化..主要..零点..多い..セッション..属性..系列..ゼロに合わせる..メディア..記述
Time description
t= (time the session is active)
r=* (zero or more repeat times)
時間記述t=(セッションが活発である時)rは*と等しいです。(ゼロか以上が回を繰り返します)
Media description, if present
m= (media name and transport address)
i=* (media title)
c=* (connection information -- optional if included at
session level)
b=* (zero or more bandwidth information lines)
k=* (encryption key)
a=* (zero or more media attribute lines)
メディア記述、現在のm=(メディアは、アドレスを命名して、輸送します)iが*(メディアタイトル)と等しいならcが*と等しい、(接続情報--、任意である、セッションレベル) b=*(ゼロか、より多くの帯域幅情報系列)k=*(暗号化キー)a=*では、含まれています。(属性が裏打ちするゼロか、より多くのメディア)
The set of type letters is deliberately small and not intended to be
extensible -- an SDP parser MUST completely ignore any session
description that contains a type letter that it does not understand.
The attribute mechanism ("a=" described below) is the primary means
for extending SDP and tailoring it to particular applications or
media. Some attributes (the ones listed in Section 6 of this memo)
have a defined meaning, but others may be added on an application-,
media-, or session-specific basis. An SDP parser MUST ignore any
attribute it doesn't understand.
タイプライターの活字のセットは、故意に小さく、広げることができることを意図しません--SDPパーサはそれが理解していないタイプライターの活字を含むどんなセッション記述も完全に無視しなければなりません。 属性メカニズム(以下で説明された「=」)は、特定用途かメディアにSDPを広げていて、それを適合させるためのプライマリ手段です。 いくつかの属性(このメモのセクション6に記載されたもの)に、定義された意味がありますが、他のものはアプリケーション、メディア、またはセッション特有のベースで加えられるかもしれません。 SDPパーサはそれが理解していないどんな属性も無視しなければなりません。
An SDP session description may contain URIs that reference external content in the "u=", "k=", and "a=" lines. These URIs may be dereferenced in some cases, making the session description non-self- contained.
SDPセッション記述は「u=」、「k=」、および「=」の参照の外部の内容が裏打ちするURIを含むかもしれません。 セッション記述をして、いくつかの場合、これらのURIが「反-参照をつけ」られるかもしれない、非、-、自己に含まれています。
Handley, et al. Standards Track [Page 9] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[9ページ]。
The connection ("c=") and attribute ("a=") information in the
session-level section applies to all the media of that session unless
overridden by connection information or an attribute of the same name
in the media description. For instance, in the example below, each
media behaves as if it were given a "recvonly" attribute.
メディア記述における、同じ名前の接続情報か属性によってくつがえされない場合、セッションレベル部の接続(「c=」)と属性(「=」)情報はそのセッションのすべてのメディアに適用されます。 例えば、以下と、それぞれ例では、メディアはまるで"recvonly"属性をそれに与えるかのように振る舞います。
An example SDP description is:
例のSDP記述は以下の通りです。
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
0mのオーディオ49170RTP/AVP=ビデオ51372RTP/AVP99 2873397496 2873404696a=recvonly j.doe@example.com (ジェーン・ドウ)c=IN IP4 224.2.17.12/127セッション記述プロトコルuのv=0 o=jdoe2890844526 2890842807IN IP4 10.47.16.5 s=SDP Seminar i=A Seminar= http://www.example.com/seminars/sdp.pdf e=t=m=a=rtpmap: 99h263-1998/90000
Text fields such as the session name and information are octet strings that may contain any octet with the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence CRLF (0x0d0a) is used to end a record, although parsers SHOULD be tolerant and also accept records terminated with a single newline character. If the "a=charset" attribute is not present, these octet strings MUST be interpreted as containing ISO-10646 characters in UTF-8 encoding (the presence of the "a=charset" attribute may force some fields to be interpreted differently).
セッション名や情報などのテキストフィールドは0×00の(Nul)、0x0a(ASCIIニューライン)、および0x0d(ASCII復帰)の例外があるどんな八重奏も含む八重奏ストリングです。 CRLFを配列してください。(0x0d0a)は記録を終わらせるのに使用されます、パーサSHOULDが、許容性があって、また、記録が単独のニューラインキャラクタと共に終えられると受け入れますが。 "a=charset"属性が存在していないなら、UTF-8コード化にISO-10646キャラクタを含んでいて、これらの八重奏ストリングを解釈しなければなりません("a=charset"属性の存在はいくつかの分野を強制的に異なって解釈させられるかもしれません)。
A session description can contain domain names in the "o=", "u=", "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply with [1], [2]. Internationalised domain names (IDNs) MUST be represented using the ASCII Compatible Encoding (ACE) form defined in [11] and MUST NOT be directly represented in UTF-8 or any other encoding (this requirement is for compatibility with RFC 2327 and other SDP-related standards, which predate the development of internationalised domain names).
セッション記述は「o=」、「u=」、「e=」、「c=」、および「=」系列におけるドメイン名を含むことができます。 SDP MUSTで使用されるどんなドメイン名も[1]、[2]に従います。 国際化しているドメイン名(IDNs)は、[11]で定義されたASCII Compatible Encoding(ACE)書式を使用して、表さなければならなくて、UTF-8かいかなる他のコード化でも直接表されてはいけません(この要件は国際化しているドメイン名の開発より前に起こるRFC2327との互換性と他のSDP関連の規格のためのものです)。
5.1. Protocol Version ("v=")
5.1. プロトコルバージョン(「v=」)
v=0
v=0
The "v=" field gives the version of the Session Description Protocol. This memo defines version 0. There is no minor version number.
「v=」分野はSession記述プロトコルのバージョンを与えます。 このメモはバージョン0を定義します。 マイナーバージョン番号が全くありません。
Handley, et al. Standards Track [Page 10] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[10ページ]。
5.2. Origin ("o=")
5.2. 発生源(「o=」)
o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>
o=<ユーザ名><sess-イド><sess-バージョン><nettype><addrtype><ユニキャストアドレス>。
The "o=" field gives the originator of the session (her username and the address of the user's host) plus a session identifier and version number:
「o=」分野はセッション(彼女のユーザ名とユーザのホストのアドレス)、セッション識別子、およびバージョン番号を創始者に与えます:
<username> is the user's login on the originating host, or it is "-"
if the originating host does not support the concept of user IDs.
The <username> MUST NOT contain spaces.
<ユーザ名>は送信元ホストにおけるユーザのログインであるか送信元ホストがユーザIDの概念をサポートしないなら、それが「-」です。 <ユーザ名>は空間を含んではいけません。
<sess-id> is a numeric string such that the tuple of <username>,
<sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a
globally unique identifier for the session. The method of
<sess-id> allocation is up to the creating tool, but it has been
suggested that a Network Time Protocol (NTP) format timestamp be
used to ensure uniqueness [13].
<sess-イド>が数値ストリングであるので、<ユーザ名>、<sess-イド>、<nettype>、<addrtype>、および<ユニキャストアドレス>のtupleはセッションのためのグローバルにユニークな識別子を形成します。 イドをsessしている<>配分のメソッドは作成ツールまで達していますが、Network Timeプロトコル(NTP)形式タイムスタンプがユニークさ[13]を確実にするのに使用されることが提案されました。
<sess-version> is a version number for this session description. Its
usage is up to the creating tool, so long as <sess-version> is
increased when a modification is made to the session data. Again,
it is RECOMMENDED that an NTP format timestamp is used.
<sess-バージョン>はこのセッション記述のバージョン番号です。 用法は作成ツールまで達しています、変更をセッションデータにするとき、<sess-バージョン>を増強する限り。 一方、NTP形式タイムスタンプが使用されているのは、RECOMMENDEDです。
<nettype> is a text string giving the type of network. Initially
"IN" is defined to have the meaning "Internet", but other values
MAY be registered in the future (see Section 8).
<nettype>はネットワークのタイプに与えるテキスト文字列です。 初めは、「IN」は意味「インターネット」を持つために定義されますが、他の値は将来、示されるかもしれません(セクション8を見てください)。
<addrtype> is a text string giving the type of the address that
follows. Initially "IP4" and "IP6" are defined, but other values
MAY be registered in the future (see Section 8).
<addrtype>は従うアドレスのタイプに与えるテキスト文字列です。 初めは、「IP4"、「IP6"は定義されますが、他の値は将来、示セクション8を(見てください)にされるかもしれない」。
<unicast-address> is the address of the machine from which the
session was created. For an address type of IP4, this is either
the fully qualified domain name of the machine or the dotted-
decimal representation of the IP version 4 address of the machine.
For an address type of IP6, this is either the fully qualified
domain name of the machine or the compressed textual
representation of the IP version 6 address of the machine. For
both IP4 and IP6, the fully qualified domain name is the form that
SHOULD be given unless this is unavailable, in which case the
globally unique address MAY be substituted. A local IP address
MUST NOT be used in any context where the SDP description might
leave the scope in which the address is meaningful (for example, a
local address MUST NOT be included in an application-level
referral that might leave the scope).
<ユニキャストアドレス>はセッションが作成されたマシンのアドレスです。 IP4のアドレスタイプにおいて、これは、マシンに関する完全修飾ドメイン名かマシンのIPバージョン4アドレスの点を打たされた10進表現のどちらかです。 IP6のアドレスタイプにおいて、これは、マシンに関する完全修飾ドメイン名かマシンのIPバージョン6アドレスの圧縮された原文の表現のどちらかです。 IP4とIP6の両方に関しては、完全修飾ドメイン名はこれが入手できなくない場合SHOULDがある書式を与えて、その場合、グローバルにユニークなアドレスを代入するかもしれないということです。 SDP記述がアドレスが重要である範囲を出るかもしれない(例えば、範囲を出るかもしれないアプリケーションレベル紹介にローカルアドレスを含んではいけません)どんな文脈でもローカルアイピーアドレスを使用してはいけません。
Handley, et al. Standards Track [Page 11] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[11ページ]。
In general, the "o=" field serves as a globally unique identifier for this version of this session description, and the subfields excepting the version taken together identify the session irrespective of any modifications.
一般に、「o=」分野はこのセッション記述のこのバージョンのためのグローバルにユニークな識別子として機能します、そして、一緒に取られたバージョンを除いた部分体はどんな変更の如何にかかわらずセッションを特定します。
For privacy reasons, it is sometimes desirable to obfuscate the username and IP address of the session originator. If this is a concern, an arbitrary <username> and private <unicast-address> MAY be chosen to populate the "o=" field, provided that these are selected in a manner that does not affect the global uniqueness of the field.
プライバシー理由で、セッション創始者のユーザ名とIPアドレスを困惑させるのは時々望ましいです。 これが関心であるなら、任意の<ユーザ名>と個人的な<ユニキャストアドレス>は「o=」分野に居住するために選ばれるかもしれません、これらが分野のグローバルなユニークさに影響しない方法で選択されれば。
5.3. Session Name ("s=")
5.3. セッション名(「s=」)
s=<session name>
sは<セッション名の>と等しいです。
The "s=" field is the textual session name. There MUST be one and only one "s=" field per session description. The "s=" field MUST NOT be empty and SHOULD contain ISO 10646 characters (but see also the "a=charset" attribute). If a session has no meaningful name, the value "s= " SHOULD be used (i.e., a single space as the session name).
「s=」分野は原文のセッション名です。 セッション記述あたり1つの唯一無二の「s=」分野があるに違いありません。 「s=」分野は人影がないはずがありません、そして、SHOULDはISO10646キャラクタを含んでいます(また、"a=charset"属性を見てください)。 セッションであるなら、重要な名前がない、値の「s=」SHOULDは使用されましたか?(すなわち、セッション名としてのシングルスペース)
5.4. Session Information ("i=")
5.4. セッション情報(「i=」)
i=<session description>
iは<セッション記述>と等しいです。
The "i=" field provides textual information about the session. There MUST be at most one session-level "i=" field per session description, and at most one "i=" field per media. If the "a=charset" attribute is present, it specifies the character set used in the "i=" field. If the "a=charset" attribute is not present, the "i=" field MUST contain ISO 10646 characters in UTF-8 encoding.
「i=」分野はセッション頃に文字情報を提供します。 セッション記述あたりのセッションレベル「i=」分野、および高々1メディアあたり1つの「i=」分野しか最も1つにあるはずがありません。 "a=charset"属性が存在しているなら、それは「i=」分野で使用される文字集合を指定します。 "a=charset"属性であるなら、プレゼント、分野が含まなければならない「i=」ISOはUTF-8コード化で10646のキャラクタではありませんか?
A single "i=" field MAY also be used for each media definition. In media definitions, "i=" fields are primarily intended for labelling media streams. As such, they are most likely to be useful when a single session has more than one distinct media stream of the same media type. An example would be two different whiteboards, one for slides and one for feedback and questions.
また、ただ一つの「i=」分野はそれぞれのメディア定義に使用されるかもしれません。 メディア定義では、「i=」分野は、メディアをストリームに分類するために主として意図します。そういうものとして、それらはただ一つのセッションに同じメディアタイプの1つ以上の異なったメディアの流れがあるとき、役に立つ最も傾向があります。 例は、2個の異なったホワイトボードと、スライドのためのものとフィードバックと質問のためのものでしょう。
The "i=" field is intended to provide a free-form human-readable description of the session or the purpose of a media stream. It is not suitable for parsing by automata.
「i=」分野がセッションの人間読み込み可能な記述かメディアストリームの目的を自由形式に提供することを意図します。 それはオートマトンで分析するのに適当ではありません。
Handley, et al. Standards Track [Page 12] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[12ページ]。
5.5. URI ("u=")
5.5. URI(「u=」)
u=<uri>
uは<uri>と等しいです。
A URI is a Uniform Resource Identifier as used by WWW clients [7]. The URI should be a pointer to additional information about the session. This field is OPTIONAL, but if it is present it MUST be specified before the first media field. No more than one URI field is allowed per session description.
WWWクライアント[7]によって使用されるようにURIはUniform Resource Identifierです。 セッション頃にURIは追加情報への指針であるべきです。 この分野はOPTIONALですが、それが存在しているなら、最初のメディア分野の前にそれを指定しなければなりません。 1つ未満のURI分野がセッション記述単位で許容されています。
5.6. Email Address and Phone Number ("e=" and "p=")
5.6. Eメールアドレスと電話番号(「e=」と「p=」)
e=<email-address>
p=<phone-number>
<Eメールアドレス>e=pは<電話番号>と等しいです。
The "e=" and "p=" lines specify contact information for the person responsible for the conference. This is not necessarily the same person that created the conference announcement.
「e=」と「p=」系列は会議に責任がある人に問い合わせ先を指定します。 これは会議発表を作成した必ず同じ人ではありません。
Inclusion of an email address or phone number is OPTIONAL. Note that the previous version of SDP specified that either an email field or a phone field MUST be specified, but this was widely ignored. The change brings the specification into line with common usage.
Eメールアドレスか電話番号の包含はOPTIONALです。 SDPの旧バージョンが、メール分野か電話分野のどちらかを指定しなければなりませんでしたが、これが広く無視されたと指定したことに注意してください。 変化は一般的な用法に仕様を一致させます。
If an email address or phone number is present, it MUST be specified before the first media field. More than one email or phone field can be given for a session description.
Eメールアドレスか電話番号が存在しているなら、最初のメディア分野の前にそれを指定しなければなりません。 セッション記述のために1つ以上のメールか電話野原を与えることができます。
Phone numbers SHOULD be given in the form of an international public telecommunication number (see ITU-T Recommendation E.164) preceded by a "+". Spaces and hyphens may be used to split up a phone field to aid readability if desired. For example:
電話番号SHOULD、「+」が先行した国際的な公共の電気通信番号(ITU-t Recommendation E.164を見る)の形で与えてください。 望まれているなら、空間とハイフンは、読み易さを支援するために電話分野を分けるのに使用されるかもしれません。 例えば:
p=+1 617 555-6011
pは+1 617 555-6011と等しいです。
Both email addresses and phone numbers can have an OPTIONAL free text string associated with them, normally giving the name of the person who may be contacted. This MUST be enclosed in parentheses if it is present. For example:
Eメールアドレスと電話番号の両方がそれらに関連しているOPTIONAL結合していないテキスト文字列を持つことができます、通常、連絡されるかもしれない人の名前を与えて。 それが存在しているなら、括弧にこれを同封しなければなりません。 例えば:
e=j.doe@example.com (Jane Doe)
eは j.doe@example.com と等しいです。(ジェーン・ドウ)
The alternative RFC 2822 [29] name quoting convention is also allowed for both email addresses and phone numbers. For example:
また、コンベンションを引用する代替のRFC2822[29]名はEメールアドレスと電話番号の両方のために許容されています。 例えば:
e=Jane Doe <j.doe@example.com>
eがジェーン Doe <j.doe@example.com と等しい、gt。
Handley, et al. Standards Track [Page 13] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[13ページ]。
The free text string SHOULD be in the ISO-10646 character set with UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if the appropriate session-level "a=charset" attribute is set.
無料のテキストがコネがUTF-8コード化、またはあるいはまた、ISO-8859-1のISO-10646文字集合であったならSHOULDを結ぶか、または適切なセッションレベル"a=charset"属性が設定されるなら、もう一方はencodingsされます。
5.7. Connection Data ("c=")
5.7. 接続データ(「c=」)
c=<nettype> <addrtype> <connection-address>
<nettype><addrtype><接続c=アドレス>。
The "c=" field contains connection data.
「c=」分野は接続データを含んでいます。
A session description MUST contain either at least one "c=" field in each media description or a single "c=" field at the session level. It MAY contain a single session-level "c=" field and additional "c=" field(s) per media description, in which case the per-media values override the session-level settings for the respective media.
セッション記述はセッションレベルにそれぞれのメディア記述における少なくとも1つの「c=」分野かただ一つの「c=」分野のどちらかを含まなければなりません。 それはメディア記述あたりただ一つのセッションレベル「c=」分野と1つの追加「c=」分野を含むかもしれません、その場合、1メディアあたりの値はそれぞれのメディアのためにセッションレベル設定をくつがえします。
The first sub-field ("<nettype>") is the network type, which is a
text string giving the type of network. Initially, "IN" is defined
to have the meaning "Internet", but other values MAY be registered in
the future (see Section 8).
最初のサブ分野(「<nettype>」)はネットワークタイプです(ネットワークのタイプに与えるテキスト文字列です)。 初めは、「IN」は意味「インターネット」を持つために定義されますが、他の値は将来、示されるかもしれません(セクション8を見てください)。
The second sub-field ("<addrtype>") is the address type. This allows
SDP to be used for sessions that are not IP based. This memo only
defines IP4 and IP6, but other values MAY be registered in the future
(see Section 8).
2番目のサブ分野(「<addrtype>」)はアドレスタイプです。 これは、SDPが基づくIPでないセッションに使用されるのを許容します。 このメモはIP4とIP6を定義するだけですが、他の値は将来、示されるかもしれません(セクション8を見てください)。
The third sub-field ("<connection-address>") is the connection
address. OPTIONAL sub-fields MAY be added after the connection
address depending on the value of the <addrtype> field.
3番目のサブ分野(「<接続アドレス>」)は接続アドレスです。 OPTIONALサブ分野は<addrtype>分野の値に依存する接続アドレスの後に加えられるかもしれません。
When the <addrtype> is IP4 and IP6, the connection address is defined as follows:
<addrtype>がIP4とIP6であるときに、接続アドレスは以下の通り定義されます:
o If the session is multicast, the connection address will be an IP
multicast group address. If the session is not multicast, then
the connection address contains the unicast IP address of the
expected data source or data relay or data sink as determined by
additional attribute fields. It is not expected that unicast
addresses will be given in a session description that is
communicated by a multicast announcement, though this is not
prohibited.
o セッションがマルチキャストであるなら、接続アドレスはIPマルチキャストグループアドレスになるでしょう。 セッションがマルチキャストでないなら、接続アドレスは追加属性分野で決定するように予想されたデータ送信端末、データリレーまたはデータ受信端末のユニキャストIPアドレスを含んでいます。 ユニキャストアドレスがマルチキャスト発表で伝えられるセッション記述で与えられないと予想されます、これは禁止されていませんが。
o Sessions using an IPv4 multicast connection address MUST also have
a time to live (TTL) value present in addition to the multicast
address. The TTL and the address together define the scope with
which multicast packets sent in this conference will be sent. TTL
values MUST be in the range 0-255. Although the TTL MUST be
specified, its use to scope multicast traffic is deprecated;
o また、IPv4マルチキャスト接続アドレスを使用するセッションはマルチキャストアドレスに加えた現在のライブ(TTL)値に苦労しなければなりません。 どのマルチキャストパケットが、この会議が送られるのを送ったかでTTLと一緒にアドレスは範囲を決めます。 TTL値が範囲0-255にあるに違いありません。 TTL MUSTですが、指定されてください、そして、範囲マルチキャストトラフィックへの使用は推奨しないです。
Handley, et al. Standards Track [Page 14] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[14ページ]。
applications SHOULD use an administratively scoped address
instead.
アプリケーションSHOULDは代わりに行政上見られたアドレスを使用します。
The TTL for the session is appended to the address using a slash as a separator. An example is:
分離符としてスラッシュを使用することでセッションのためのTTLをアドレスに追加します。 例は以下の通りです。
c=IN IP4 224.2.36.42/127
cがIN IP4 224.2.36.42/と等しい、127
IPv6 multicast does not use TTL scoping, and hence the TTL value MUST NOT be present for IPv6 multicast. It is expected that IPv6 scoped addresses will be used to limit the scope of conferences.
IPv6マルチキャストはTTLの見ることを使用しません、そして、したがって、TTL値はIPv6マルチキャストのために存在しているはずがありません。 IPv6が、アドレスが会議の範囲を制限するのに使用されるのを見たと予想されます。
Hierarchical or layered encoding schemes are data streams where the encoding from a single media source is split into a number of layers. The receiver can choose the desired quality (and hence bandwidth) by only subscribing to a subset of these layers. Such layered encodings are normally transmitted in multiple multicast groups to allow multicast pruning. This technique keeps unwanted traffic from sites only requiring certain levels of the hierarchy. For applications requiring multiple multicast groups, we allow the following notation to be used for the connection address:
階層的であるか層にされたコード化体系は単独のメディア・ソースからのコード化が多くの層に分けられるところのデータ・ストリームです。 受信機は、これらの層の部分集合に加入するだけで必要な品質(そして、したがって、帯域幅)を選ぶことができます。 通常、そのような層にされたencodingsは、マルチキャスト刈り込みを許容するために複数のマルチキャストグループで伝えられます。 このテクニックは階層構造のあるレベルを必要とするだけであるサイトから求められていないトラフィックを妨げます。 複数のマルチキャストグループを必要とするアプリケーションのために、私たちは、以下の記法が接続アドレスに使用されるのを許します:
<base multicast address>[/<ttl>]/<number of addresses>
アドレス>の<ベースマルチキャストアドレス>[/<ttl>]/<番号
If the number of addresses is not given, it is assumed to be one. Multicast addresses so assigned are contiguously allocated above the base address, so that, for example:
アドレスの数が与えられないなら、それは1であると思われます。 近接してそのように割り当てられたマルチキャストアドレスをベースアドレスの上に割り当てて、そうがそれである、例えば:
c=IN IP4 224.2.1.1/127/3
cがIN IP4 224.2.1.1/と等しい、127/3
would state that addresses 224.2.1.1, 224.2.1.2, and 224.2.1.3 are to be used at a TTL of 127. This is semantically identical to including multiple "c=" lines in a media description:
そして、そのアドレスが述べるだろう、224.2、.1、.1、224.2 .1 .2、224.2 .1 .3は127のTTLで使用されることです。 これはメディア記述に複数の「c=」系列を含んでいるのと意味的に同じです:
c=IN IP4 224.2.1.1/127
c=IN IP4 224.2.1.2/127
c=IN IP4 224.2.1.3/127
IP4 224.2.1.1/127c=IN IP4 224.2.1.2/127c=IN IP4 224.2.1.3/のc=、127
Similarly, an IPv6 example would be:
同様に、IPv6の例は以下の通りでしょう。
c=IN IP6 FF15::101/3
IP6 FF15のc=:、:101/3
which is semantically equivalent to:
どれが以下に意味的に同等ですか?
c=IN IP6 FF15::101
c=IN IP6 FF15::102
c=IN IP6 FF15::103
IP6 FF15のc=:、:101 IP6 FF15のc=:、:102 IP6 FF15のc=:、:103
Handley, et al. Standards Track [Page 15] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[15ページ]。
(remembering that the TTL field is not present in IPv6 multicast).
(TTL分野がIPv6マルチキャストで存在していないのを覚えています。)
Multiple addresses or "c=" lines MAY be specified on a per-media basis only if they provide multicast addresses for different layers in a hierarchical or layered encoding scheme. They MUST NOT be specified for a session-level "c=" field.
異なった層のためのマルチキャストアドレスを階層的であるか層にされたコード化体系に提供する場合にだけ、複数のアドレスか「c=」系列が1メディアあたり1個のベースで指定されるかもしれません。 セッションレベル「c=」分野にそれらを指定してはいけません。
The slash notation for multiple addresses described above MUST NOT be used for IP unicast addresses.
IPユニキャストアドレスに上で説明された複数のアドレスのためのスラッシュ記法を使用してはいけません。
5.8. Bandwidth ("b=")
5.8. 帯域幅(「b=」)
b=<bwtype>:<bandwidth>
<bwtype b=>: <帯域幅>。
This OPTIONAL field denotes the proposed bandwidth to be used by the session or media. The <bwtype> is an alphanumeric modifier giving the meaning of the <bandwidth> figure. Two values are defined in this specification, but other values MAY be registered in the future (see Section 8 and [21], [25]):
セッションかメディアによって使用されるように、このOPTIONAL分野は提案された帯域幅を指示します。 <bwtype>は<帯域幅>数値の意味を与える英数字の修飾語です。 2つの値がこの仕様に基づき定義されますが、他の値は将来、示されるかもしれません。(セクション8と[21]を見てください、[25]):
CT If the bandwidth of a session or media in a session is different
from the bandwidth implicit from the scope, a "b=CT:..." line
SHOULD be supplied for the session giving the proposed upper limit
to the bandwidth used (the "conference total" bandwidth). The
primary purpose of this is to give an approximate idea as to
whether two or more sessions can coexist simultaneously. When
using the CT modifier with RTP, if several RTP sessions are part
of the conference, the conference total refers to total bandwidth
of all RTP sessions.
セッションかセッションにおけるメディアの帯域幅は異なっています。コネチカットIf、範囲、「bはコネチカットと等しい」…系列SHOULDからの暗黙の帯域幅から、提案された上限を帯域幅に与えると使用されたセッション(「会議合計」帯域幅)のために供給してください。 このプライマリ目的は2つ以上のセッションが同時に共存できるかどうかに関して大体の考えを与えることです。 いくつかのRTPセッションが会議の一部であるならRTPとのコネチカット修飾語を使用するとき、会議合計はすべてのRTPセッションの総帯域幅について言及します。
AS The bandwidth is interpreted to be application specific (it will
be the application's concept of maximum bandwidth). Normally,
this will coincide with what is set on the application's "maximum
bandwidth" control if applicable. For RTP-based applications, AS
gives the RTP "session bandwidth" as defined in Section 6.2 of
[19].
アプリケーションが特定であったなら(それはアプリケーションの最大の帯域幅の概念になるでしょう)帯域幅が解釈されるAS。 通常、これは適切であるならアプリケーションの「最大の帯域幅」コントロールに設定されることと同時に起こるでしょう。 RTPベースのアプリケーションのために、ASは[19]のセクション6.2で定義されるようにRTP「セッション帯域幅」を与えます。
Note that CT gives a total bandwidth figure for all the media at all sites. AS gives a bandwidth figure for a single media at a single site, although there may be many sites sending simultaneously.
コネチカットがすべてのサイトで総帯域幅図にすべてのメディアを支払うことに注意してください。 ASはただ一つのサイトのただ一つのメディアのために帯域幅図に与えます、同時に発信する多くのサイトがあるかもしれませんが。
A prefix "X-" is defined for <bwtype> names. This is intended for experimental purposes only. For example:
接頭語「X」は<bwtype>名のために定義されます。 これは実験目的だけのために意図します。 例えば:
b=X-YZ:128
b=X-YZ: 128
Handley, et al. Standards Track [Page 16] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[16ページ]。
Use of the "X-" prefix is NOT RECOMMENDED: instead new modifiers SHOULD be registered with IANA in the standard namespace. SDP parsers MUST ignore bandwidth fields with unknown modifiers. Modifiers MUST be alphanumeric and, although no length limit is given, it is recommended that they be short.
「X」接頭語の使用は推薦されません: 代わりに新しい修飾語SHOULD、標準の名前空間でIANAに登録されてください。 SDPパーサは未知の修飾語がある帯域幅分野を無視しなければなりません。 修飾語は英数字であるに違いありません、そして、長さの限界を全く与えませんが、それらが短いのは、お勧めです。
The <bandwidth> is interpreted as kilobits per second by default. The definition of a new <bwtype> modifier MAY specify that the bandwidth is to be interpreted in some alternative unit (the "CT" and "AS" modifiers defined in this memo use the default units).
<帯域幅>はデフォルトで1秒あたりのキロビットとして解釈されます。 新しい<bwtype>修飾語の定義は、帯域幅が何らかの代替のユニットで解釈されることになっていると指定するかもしれません(修飾語がこのメモで定義した「コネチカット」と“AS"はデフォルト単位を使用します)。
5.9. Timing ("t=")
5.9. タイミング(「t=」)
t=<start-time> <stop-time>
<開始時刻><停止t=時間>。
The "t=" lines specify the start and stop times for a session. Multiple "t=" lines MAY be used if a session is active at multiple irregularly spaced times; each additional "t=" line specifies an additional period of time for which the session will be active. If the session is active at regular times, an "r=" line (see below) should be used in addition to, and following, a "t=" line -- in which case the "t=" line specifies the start and stop times of the repeat sequence.
「t=」系列は、始めを指定して、セッションのために回を止めます。 セッションが複数の不規則に区切られた回活発であるなら、複数の「t=」系列は使用されるかもしれません。 それぞれの追加「t=」系列はセッションが活発になる追加期間を指定します。 「r=」系列(以下を見る)は、セッションが通常の時に活発であるなら「t=」系列--どれが「t=」をケースに入れるかで立ち並んでいるのが反復系列の始めと停止倍を指定するのに使用されて、続くべきです。
The first and second sub-fields give the start and stop times, respectively, for the session. These values are the decimal representation of Network Time Protocol (NTP) time values in seconds since 1900 [13]. To convert these values to UNIX time, subtract decimal 2208988800.
1番目と2番目のサブ分野は、セッションのために始めを与えて、それぞれ回を止めます。 これらの値は1900[13]以来の秒のNetwork Timeプロトコル(NTP)時間的価値の10進表現です。 UNIX時間までこれらの値を変換するには、10進2208988800を引き算してください。
NTP timestamps are elsewhere represented by 64-bit values, which wrap sometime in the year 2036. Since SDP uses an arbitrary length decimal representation, this should not cause an issue (SDP timestamps MUST continue counting seconds since 1900, NTP will use the value modulo the 64-bit limit).
NTPタイムスタンプはほかの場所に64ビットの値によって表されて、いつか年間のどの包装が2036であるか。 SDPが任意の長さの10進表現を使用するので、これは問題を引き起こすべきではありません(SDPタイムスタンプが1900年以来の数えている秒を続けなければならなくて、NTPは64ビットが制限する値の法を使用するでしょう)。
If the <stop-time> is set to zero, then the session is not bounded, though it will not become active until after the <start-time>. If the <start-time> is also zero, the session is regarded as permanent.
<停止時間>がゼロに用意ができているなら、セッションは境界がありません、<開始時刻>の後までアクティブにならないでしょうが。 また、<開始時刻>がゼロであるなら、セッションは永久的であると見なされます。
User interfaces SHOULD strongly discourage the creation of unbounded and permanent sessions as they give no information about when the session is actually going to terminate, and so make scheduling difficult.
彼らがセッションが終えるので実際にスケジューリングを難しくする時の情報を全く教えないとき、ユーザインタフェースSHOULDは強く限りなくて永久的なセッションの作成に水をさしています。
The general assumption may be made, when displaying unbounded sessions that have not timed out to the user, that an unbounded session will only be active until half an hour from the current time
限りないそうした表示セッションがユーザへの外で調節されなかったとき、限りないセッションが現在の時間からの30分まで活発になるだけであるという一般的な仮定はされるかもしれません。
Handley, et al. Standards Track [Page 17] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[17ページ]。
or the session start time, whichever is the later. If behaviour other than this is required, an end-time SHOULD be given and modified as appropriate when new information becomes available about when the session should really end.
または、セッション開始時刻。(その開始時刻は、より遅いです)。 これを除いたふるまいが必要であるなら、新情報がセッションが本当に終わるべきである時に関して利用可能になるとき、与えられていて、適宜変更された終わり-時間SHOULDです。
Permanent sessions may be shown to the user as never being active unless there are associated repeat times that state precisely when the session will be active.
活発であるとセッションが正確にいつなるか述べる関連反復時間がない場合、永久的なセッションは決して活発でないユーザに示されるかもしれません。
5.10. Repeat Times ("r=")
5.10. 回を繰り返してください。(「r=」)
r=<repeat interval> <active duration> <offsets from start-time>
<r=反復間隔の>の<のアクティブな持続時間><は開始時刻>から相殺されます。
"r=" fields specify repeat times for a session. For example, if a session is active at 10am on Monday and 11am on Tuesday for one hour each week for three months, then the <start-time> in the corresponding "t=" field would be the NTP representation of 10am on the first Monday, the <repeat interval> would be 1 week, the <active duration> would be 1 hour, and the offsets would be zero and 25 hours. The corresponding "t=" field stop time would be the NTP representation of the end of the last session three months later. By default, all fields are in seconds, so the "r=" and "t=" fields might be the following:
「r=」分野はセッションとして反復時間を指定します。 オフセットは、例えば、セッションがそれぞれの週に月曜日午前10時と火曜日午前11時に1時間3カ月活発であるなら、最初の月曜日に対応する「t=」分野の<開始時刻>は午前10時のNTP表現であるだろう、<反復間隔>は1週間であるだろう、<のアクティブな持続時間>は1時間であるだろう、ゼロと25時間でしょう。 3カ月後に対応する「t=」分野停止時間は納会の終わりのNTP表現でしょう。 秒に、デフォルトで、すべての分野があるので、「r=」と「t=」分野は以下であるかもしれません:
t=3034423619 3042462419
r=604800 3600 0 90000
t=3034423619 3042462419r=604800 3600 0 90000
To make description more compact, times may also be given in units of days, hours, or minutes. The syntax for these is a number immediately followed by a single case-sensitive character. Fractional units are not allowed -- a smaller unit should be used instead. The following unit specification characters are allowed:
また、記述をよりコンパクトにするように、ユニットの何日も、何時間も、または数分間回を与えるかもしれません。 これらのための構文はすぐに単独の大文字と小文字を区別するキャラクタによっていうことになられた数です。 断片的なユニットは許容されていません--より小さい単位は代わりに使用されるべきです。 以下のユニット仕様キャラクタは許容されています:
d - days (86400 seconds)
h - hours (3600 seconds)
m - minutes (60 seconds)
s - seconds (allowed for completeness)
d--何日(86400秒)ものh--何時間(3600秒)ものm--数分(60秒)s--秒(完全性を考慮します)
Thus, the above session announcement could also have been written:
したがって、また、上のセッション発表は書かれたかもしれません:
r=7d 1h 0 25h
r=7d 1h0 25h
Monthly and yearly repeats cannot be directly specified with a single SDP repeat time; instead, separate "t=" fields should be used to explicitly list the session times.
ただ一つのSDP反復時間で直接月毎の、そして、年一度の反復を指定できません。 代わりに、別々の「t=」分野は、明らかにセッション時間を記載するのに使用されるべきです。
Handley, et al. Standards Track [Page 18] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[18ページ]。
5.11. Time Zones ("z=")
5.11. 時間帯(「z=」)
z=<adjustment time> <offset> <adjustment time> <offset> ....
<の<のオフセット><調整調整時間>z=時間><は>を相殺しました…
To schedule a repeated session that spans a change from daylight saving time to standard time or vice versa, it is necessary to specify offsets from the base time. This is required because different time zones change time at different times of day, different countries change to or from daylight saving time on different dates, and some countries do not have daylight saving time at all.
逆もまた同様です、繰り返されたセッションの計画をするように、それは夏時間から標準時までの変化にかかっているか、またはベース時間からオフセットを指定するのが必要です。 異なった時間帯が日のいろいろな時間の時に変化して、夏時間か異なった期日の夏時間と異なった国が変化して、いくつかの国には全く夏時間がないので、これが必要です。
Thus, in order to schedule a session that is at the same time winter and summer, it must be possible to specify unambiguously by whose time zone a session is scheduled. To simplify this task for receivers, we allow the sender to specify the NTP time that a time zone adjustment happens and the offset from the time when the session was first scheduled. The "z=" field allows the sender to specify a list of these adjustment times and offsets from the base time.
したがって、同時に冬、夏であるセッションの計画をするように、セッションがだれの時間帯によって予定されているかを明白に指定するのは可能でなければなりません。 受信機のためのこのタスクを簡素化するために、私たちは送付者にセッションが最初に予定されていた時から時間帯の調整が起こる時間のNTPとオフセットを指定させます。 「z=」分野で、送付者はベース時間からこれらの調整時間とオフセットのリストを指定できます。
An example might be the following:
例は以下であるかもしれません:
z=2882844526 -1h 2898848070 0
z=2882844526 -1h2898848070 0
This specifies that at time 2882844526, the time base by which the session's repeat times are calculated is shifted back by 1 hour, and that at time 2898848070, the session's original time base is restored. Adjustments are always relative to the specified start time -- they are not cumulative. Adjustments apply to all "t=" and "r=" lines in a session description.
これは時2882844526に、セッションの反復時代が計算される時間ベースが1時間移動して、時2898848070にセッションの元の時間ベースが回復すると指定します。 調整はいつも指定された開始時刻に比例しています--それらは累積していません。 調整はセッション記述におけるすべての「t=」と「r=」系列に適用されます。
If a session is likely to last several years, it is expected that the session announcement will be modified periodically rather than transmit several years' worth of adjustments in one session announcement.
セッションが数年続きそうであるなら、セッション発表が1つのセッション発表における、数年の調整の価値を伝えるより定期的にむしろ変更されると予想されます。
5.12. Encryption Keys ("k=")
5.12. 暗号化キー(「k=」)
k=<method>
k=<method>:<encryption key>
<<メソッド>k=k=メソッド>: <暗号化の主要な>。
If transported over a secure and trusted channel, the Session
Description Protocol MAY be used to convey encryption keys. A simple
mechanism for key exchange is provided by the key field ("k="),
although this is primarily supported for compatibility with older
implementations and its use is NOT RECOMMENDED. Work is in progress
to define new key exchange mechanisms for use with SDP [27] [28], and
it is expected that new applications will use those mechanisms.
安全で信じられたチャンネルの上に輸送されるなら、Session記述プロトコルは、暗号化キーを運ぶのに使用されるかもしれません。 キーフィールド(「k=」)で主要な交換のための簡単なメカニズムを提供します、これは、より古い実装との互換性のために主としてサポートされます、そして、使用はNOT RECOMMENDEDですが。 仕事は使用のためにSDP[27][28]で新しい主要な交換メカニズムを定義するために進行しています、そして、新しいアプリケーションがそれらのメカニズムを使用すると予想されます。
Handley, et al. Standards Track [Page 19] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[19ページ]。
A key field is permitted before the first media entry (in which case it applies to all media in the session), or for each media entry as required. The format of keys and their usage are outside the scope of this document, and the key field provides no way to indicate the encryption algorithm to be used, key type, or other information about the key: this is assumed to be provided by the higher-level protocol using SDP. If there is a need to convey this information within SDP, the extensions mentioned previously SHOULD be used. Many security protocols require two keys: one for confidentiality, another for integrity. This specification does not support transfer of two keys.
キーフィールドは必要に応じて最初のメディアエントリー(その場合、それはセッションのときにすべてのメディアに適用される)の前かそれぞれのメディアエントリーに受入れられます。 このドキュメントの範囲の外にキーの形式とそれらの用法があります、そして、キーフィールドは暗号化アルゴリズムが中古の、そして、主要なタイプ、またはキーの他の情報であることを示す方法を全く提供しません: 上位レベル・プロトコルによってSDPを使用することでこれが提供されると思われます。 SDPの中でこの情報を伝える必要があれば、拡大は、以前に、SHOULDが使用されると言及しました。 多くのセキュリティプロトコルが2個のキーを必要とします: 秘密性のためのもの、保全のための別。 この仕様は2個のキーの転送をサポートしません。
The method indicates the mechanism to be used to obtain a usable key by external means, or from the encoded encryption key given. The following methods are defined:
メソッドは、外部の手段で使用可能なキーを入手するのに使用するか、またはコード化された暗号化キーから与えるためにメカニズムを示します。 以下のメソッドは定義されます:
k=clear:<encryption key>
k=は: <暗号化の主要な>をきれいにします。
The encryption key is included untransformed in this key field.
This method MUST NOT be used unless it can be guaranteed that
the SDP is conveyed over a secure channel. The encryption key
is interpreted as text according to the charset attribute; use
the "k=base64:" method to convey characters that are otherwise
prohibited in SDP.
暗号化キーはこのキーフィールドで「非-変え」られた状態で含まれています。 SDPが安全なチャンネルの上まで運ばれるのを保証できないなら、このメソッドを使用してはいけません。 charset属性に従って、暗号化キーはテキストとして解釈されます。 使用、「k=base64:」 別の方法でSDPで禁止されているキャラクタを運ぶメソッド。
k=base64:<encoded encryption key>
k=base64: <は暗号化の主要な>をコード化しました。
The encryption key is included in this key field but has been
base64 encoded [12] because it includes characters that are
prohibited in SDP. This method MUST NOT be used unless it can
be guaranteed that the SDP is conveyed over a secure channel.
暗号化キーは、このキーフィールドに含まれていますが、[12] SDPで禁止されているキャラクタを含んでいるのでコード化されたbase64です。 SDPが安全なチャンネルの上まで運ばれるのを保証できないなら、このメソッドを使用してはいけません。
k=uri:<URI to obtain key>
k=uri: 主要な>を入手する<URI
A Uniform Resource Identifier is included in the key field.
The URI refers to the data containing the key, and may require
additional authentication before the key can be returned. When
a request is made to the given URI, the reply should specify
the encoding for the key. The URI is often an Secure Socket
Layer/Transport Layer Security (SSL/TLS)-protected HTTP URI
("https:"), although this is not required.
Uniform Resource Identifierはキーフィールドに含まれています。 URIは、キーを含むデータを示して、キーを返すことができる前に追加認証を必要とするかもしれません。 要求を与えられたURIにするとき、回答はキーのためのコード化を指定するべきです。 これは必要ではありませんが、しばしばURIはSecure Socket Layer/輸送Layer Security(SSL/TLS)の保護されたHTTP URI(「以下をhttpsする」)です。
k=prompt
k=プロンプト
No key is included in this SDP description, but the session or
media stream referred to by this key field is encrypted. The
user should be prompted for the key when attempting to join the
session, and this user-supplied key should then be used to
キーは全くこのSDP記述に含まれていませんが、このキーフィールドによって言及されたセッションかメディア小川が暗号化されています。 ユーザは次にセッション、およびこのユーザによって供給されたキーに参加する試みが使用されるべきであるキーのためにうながされるべきです。
Handley, et al. Standards Track [Page 20] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[20ページ]。
decrypt the media streams. The use of user-specified keys is
NOT RECOMMENDED, since such keys tend to have weak security
properties.
メディアがストリームであると解読してください。ユーザによって指定されたキーの使用はNOT RECOMMENDEDです、そのようなキーが、弱いセキュリティの特性を持っている傾向があるので。
The key field MUST NOT be used unless it can be guaranteed that the SDP is conveyed over a secure and trusted channel. An example of such a channel might be SDP embedded inside an S/MIME message or a TLS-protected HTTP session. It is important to ensure that the secure channel is with the party that is authorised to join the session, not an intermediary: if a caching proxy server is used, it is important to ensure that the proxy is either trusted or unable to access the SDP.
SDPが安全で信じられたチャンネルの上まで運ばれるのを保証できないなら、キーフィールドを使用してはいけません。 そのようなチャンネルに関する例はS/MIMEメッセージかTLSによって保護されたHTTPセッションのときに埋め込まれたSDPであるかもしれません。 安全なチャンネルが仲介者ではなく、セッションに参加するのが認可されるパーティーと共にあるのを保証するのは重要です: キャッシュプロキシサーバが使用されているなら、プロキシが確実に信じられるか、またはSDPにアクセスできないようになるようにするのは重要です。
5.13. Attributes ("a=")
5.13. 属性(「=」)
a=<attribute>
a=<attribute>:<value>
=<属性>a=<属性>: <値の>。
Attributes are the primary means for extending SDP. Attributes may be defined to be used as "session-level" attributes, "media-level" attributes, or both.
属性は、SDPを広げるためのプライマリ手段です。 属性は、「セッションレベル」属性、「メディアレベル」属性、または両方として使用されるために定義されるかもしれません。
A media description may have any number of attributes ("a=" fields)
that are media specific. These are referred to as "media-level"
attributes and add information about the media stream. Attribute
fields can also be added before the first media field; these
"session-level" attributes convey additional information that applies
to the conference as a whole rather than to individual media.
メディア記述には、メディア詳細であるいろいろな属性(「a=」分野)があるかもしれません。 これらは、「メディアレベル」属性と呼ばれて、メディアストリームの情報を加えます。 また、最初のメディア分野の前に属性分野を加えることができます。 これらの「セッションレベル」属性は独特のメディアにというよりむしろ全体で会議に適用される追加情報を伝えます。
Attribute fields may be of two forms:
属性分野は2つのフォームのものであるかもしれません:
o A property attribute is simply of the form "a=<flag>". These are
binary attributes, and the presence of the attribute conveys that
the attribute is a property of the session. An example might be
"a=recvonly".
o 特性の属性は単にフォームでは、「=<は>に旗を揚げる」ということです。 これらはバイナリ属性です、そして、属性の存在は属性がセッションの特性であることを運びます。 例は"a=recvonly"であるかもしれません。
o A value attribute is of the form "a=<attribute>:<value>". For
example, a whiteboard could have the value attribute "a=orient:
landscape"
o 値の属性はフォーム「=<属性>: <値の>」のものです。 ホワイトボードには、例えば、値の属性があるかもしれません。「=は以下を適応します」。 「風景」
Attribute interpretation depends on the media tool being invoked. Thus receivers of session descriptions should be configurable in their interpretation of session descriptions in general and of attributes in particular.
属性解釈は呼び出されるメディアツールによります。 したがって、セッション記述の受信機は彼らの一般に、セッション記述と特に属性の解釈で構成可能であるべきです。
Attribute names MUST use the US-ASCII subset of ISO-10646/UTF-8.
属性名はISO-10646/UTF-8の米国-ASCII部分集合を使用しなければなりません。
Handley, et al. Standards Track [Page 21] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[21ページ]。
Attribute values are octet strings, and MAY use any octet value except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute values are to be interpreted as in ISO-10646 character set with UTF-8 encoding. Unlike other text fields, attribute values are NOT normally affected by the "charset" attribute as this would make comparisons against known values problematic. However, when an attribute is defined, it can be defined to be charset dependent, in which case its value should be interpreted in the session charset rather than in ISO-10646.
属性値は、八重奏ストリングであり、0×00の(Nul)、0x0A(LF)、および0x0D(CR)以外のどんな八重奏値も使用するかもしれません。 デフォルトで、属性値はUTF-8コード化があるISO-10646文字集合で解釈されることです。 他のテキストフィールドと異なって、知られている値に対する比較がこれで問題が多くなるだろうというとき、通常、属性値は"charset"属性で影響を受けません。 しかしながら、属性が定義されるとき、charset扶養家族になるようにそれを定義できます、その場合、値はISO-10646でというよりむしろセッションcharsetのときに解釈されるべきです。
Attributes MUST be registered with IANA (see Section 8). If an attribute is received that is not understood, it MUST be ignored by the receiver.
属性をIANAに示さなければなりません(セクション8を見てください)。 属性が受け取られているなら、それは理解されないで、受信機でそれを無視しなければなりません。
5.14. Media Descriptions ("m=")
5.14. メディア記述(「m=」)
m=<media> <port> <proto> <fmt> ...
m=<メディア><は><proto><fmt>を移植します…
A session description may contain a number of media descriptions. Each media description starts with an "m=" field and is terminated by either the next "m=" field or by the end of the session description. A media field has several sub-fields:
セッション記述は多くのメディア記述を含むかもしれません。 それぞれのメディア記述は、「m=」野原から始まって、次の「m=」分野かセッション記述の終わりまでに終えられます。 メディア分野には、いくつかのサブ分野があります:
<media> is the media type. Currently defined media are "audio",
"video", "text", "application", and "message", although this list
may be extended in the future (see Section 8).
<メディア>はメディアタイプです。 現在定義されたメディアは、「オーディオ」と、「ビデオ」と、「テキスト」と、「アプリケーション」と、「メッセージ」です、このリストは将来、広げられるかもしれませんが(セクション8を見てください)。
<port> is the transport port to which the media stream is sent. The
meaning of the transport port depends on the network being used as
specified in the relevant "c=" field, and on the transport
protocol defined in the <proto> sub-field of the media field.
Other ports used by the media application (such as the RTP Control
Protocol (RTCP) port [19]) MAY be derived algorithmically from the
base media port or MAY be specified in a separate attribute (for
example, "a=rtcp:" as defined in [22]).
<ポート>はメディア小川が送られる輸送ポートです。 輸送ポートの意味は関連「c=」分野で指定されるように使用されるネットワークと、そして、メディア分野の<proto>サブ分野で定義されたトランスポート・プロトコルに頼っています。 他のポートがメディアアプリケーションで使用した、(RTP Controlプロトコル(RTCP)が[19])を移植するとき、そのようなものをベースメディア港からalgorithmicallyに派生するか、または別々の属性で指定するかもしれない、(例えば、「a=rtcp:」 [22])で定義されるように。
If non-contiguous ports are used or if they don't follow the
parity rule of even RTP ports and odd RTCP ports, the "a=rtcp:"
attribute MUST be used. Applications that are requested to send
media to a <port> that is odd and where the "a=rtcp:" is present
MUST NOT subtract 1 from the RTP port: that is, they MUST send the
RTP to the port indicated in <port> and send the RTCP to the port
indicated in the "a=rtcp" attribute.
非隣接のポートが使用されているか、またはRTPポートと変なRTCPポートさえのパリティ規則に従わないなら「a=rtcp:」 属性を使用しなければなりません。 メディアを<に送るよう要求されている申込み書が変な>とどこを移植するか、「a=rtcp:」 プレゼントがRTPポートから1を引き算してはいけないということです: すなわち、彼らは、<ポート>で示されたポートにRTPを送って、"a=rtcp"属性で示されたポートにRTCPを送らなければなりません。
For applications where hierarchically encoded streams are being
sent to a unicast address, it may be necessary to specify multiple
transport ports. This is done using a similar notation to that
used for IP multicast addresses in the "c=" field:
階層的でコード化された小川がユニキャストアドレスに送られるアプリケーションに、複数の輸送ポートを指定するのが必要であるかもしれません。 これは「c=」分野でIPマルチキャストアドレスに使用されるそれに同様の記法を使用し終わっています:
Handley, et al. Standards Track [Page 22] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[22ページ]。
m=<media> <port>/<number of ports> <proto> <fmt> ...
m=<メディア><は>/<ポートの数><proto><fmt>を移植します…
In such a case, the ports used depend on the transport protocol.
For RTP, the default is that only the even-numbered ports are used
for data with the corresponding one-higher odd ports used for the
RTCP belonging to the RTP session, and the <number of ports>
denoting the number of RTP sessions. For example:
このような場合には、使用されるポートはトランスポート・プロトコルによります。 RTPに関しては、デフォルトは偶数のポートだけが対応する1以上高い変なポートがRTCPに使用されているRTPセッション、およびRTPセッションの数を指示する<ポートの数>に属すデータに使用されるということです。 例えば:
m=video 49170/2 RTP/AVP 31
mはビデオ49170/2RTP/AVP31と等しいです。
would specify that ports 49170 and 49171 form one RTP/RTCP pair
and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the
transport protocol and 31 is the format (see below). If non-
contiguous ports are required, they must be signalled using a
separate attribute (for example, "a=rtcp:" as defined in [22]).
49170と49171フォームの1RTP/RTCPの組、49172、および49173のポートが2番目のRTP/RTCP組を形成すると指定するでしょう。 RTP/AVPはトランスポート・プロトコルです、そして、31は形式(以下を見る)です。 非隣接のポートが必要であるなら、別々の属性を使用することでそれらに合図しなければならない、(例えば、「a=rtcp:」 [22])で定義されるように。
If multiple addresses are specified in the "c=" field and multiple
ports are specified in the "m=" field, a one-to-one mapping from
port to the corresponding address is implied. For example:
複数のアドレスが「c=」分野で指定されて、複数のポートが「m=」分野で指定されるなら、1〜1つのポートから対応するアドレスまでのマッピングが含意されます。 例えば:
c=IN IP4 224.2.1.1/127/2
m=video 49170/2 RTP/AVP 31
cは.1/127/2mのIN IP4 224.2.1=ビデオ49170/2RTP/AVP31と等しいです。
would imply that address 224.2.1.1 is used with ports 49170 and
49171, and address 224.2.1.2 is used with ports 49172 and 49173.
そのアドレスが含意するだろう、224.2、.1、.1、ポート49170と49171、およびアドレスと共に使用される、224.2、.1、.2、ポート49172と49173と共に使用されます。
The semantics of multiple "m=" lines using the same transport
address are undefined. This implies that, unlike limited past
practice, there is no implicit grouping defined by such means and
an explicit grouping framework (for example, [18]) should instead
be used to express the intended semantics.
同じ輸送アドレスを使用する複数の「m=」系列の意味論は未定義です。 これは、そのような手段と明白な組分けフレームワークによって定義されたどんな暗黙の組分けも限られた過去の習慣と異なっていないのを含意します。(例えば、[18])は代わりに意図している意味論を言い表すのが使用されるべきです。
<proto> is the transport protocol. The meaning of the transport
protocol is dependent on the address type field in the relevant
"c=" field. Thus a "c=" field of IP4 indicates that the transport
protocol runs over IP4. The following transport protocols are
defined, but may be extended through registration of new protocols
with IANA (see Section 8):
<proto>はトランスポート・プロトコルです。 トランスポート・プロトコルの意味は関連「c=」分野のアドレスタイプフィールドに依存しています。 したがって、IP4の「c=」分野は、トランスポート・プロトコルがIP4をひくのを示します。 以下のトランスポート・プロトコルは、定義されますが、IANAとの新しいプロトコルの登録で広げられるかもしれません(セクション8を見てください):
* udp: denotes an unspecified protocol running over UDP.
* udp: UDPをひく不特定のプロトコルを指示します。
* RTP/AVP: denotes RTP [19] used under the RTP Profile for Audio
and Video Conferences with Minimal Control [20] running over
UDP.
* RTP/AVP: Minimal ControlがあるAudioとVideoコンファレンスに[20] UDPをひきながらRTP Profileの下で使用されるRTP[19]を指示します。
* RTP/SAVP: denotes the Secure Real-time Transport Protocol [23]
running over UDP.
* RTP/SAVP: UDPをひきながら、Secureレアル-時間Transportプロトコル[23]を指示します。
Handley, et al. Standards Track [Page 23] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[23ページ]。
The main reason to specify the transport protocol in addition to
the media format is that the same standard media formats may be
carried over different transport protocols even when the network
protocol is the same -- a historical example is vat Pulse Code
Modulation (PCM) audio and RTP PCM audio; another might be TCP/RTP
PCM audio. In addition, relays and monitoring tools that are
transport-protocol-specific but format-independent are possible.
メディア形式に加えてトランスポート・プロトコルを指定する主な理由はネットワーク・プロトコルが同じであるときにさえ、同じ標準のメディア形式が異なったトランスポート・プロトコルの上まで運ばれるかもしれないということです--歴史的な例は、大タンクパルスコードの変調(PCM)オーディオとRTP PCMオーディオです。 別のものはTCP/RTP PCMオーディオであるかもしれません。 さらに、輸送プロトコル詳細にもかかわらず、形式独立者であるリレーとモニターしている道具は可能です。
<fmt> is a media format description. The fourth and any subsequent
sub-fields describe the format of the media. The interpretation
of the media format depends on the value of the <proto> sub-field.
<fmt>はメディア書式の記述です。 4番目とどんなその後のサブ分野もメディアの形式について説明します。 メディア形式の解釈は<proto>サブ分野の値に依存します。
If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt>
sub-fields contain RTP payload type numbers. When a list of
payload type numbers is given, this implies that all of these
payload formats MAY be used in the session, but the first of these
formats SHOULD be used as the default format for the session. For
dynamic payload type assignments the "a=rtpmap:" attribute (see
Section 6) SHOULD be used to map from an RTP payload type number
to a media encoding name that identifies the payload format. The
"a=fmtp:" attribute MAY be used to specify format parameters (see
Section 6).
<proto>サブ分野が"RTP/AVP"か"RTP/SAVP"であるなら、<fmt>サブ分野はRTPペイロード形式数を含んでいます。 ペイロード形式数のリストを与えるとき、これは、ペイロードがしかし、中古のコネがセッション、これらの形式SHOULDの1番目であったかもしれないならフォーマットするこれらのすべてがセッションに省略時書式として使用されるのを含意します。 ダイナミックなペイロードタイプ課題、「a=rtpmap:」 (セクション6を見ます)SHOULDを結果と考えてください。使用されて、RTPからペイロード形式を特定するメディアコード化への数が命名するペイロードタイプを写像してください。 「a=fmtp:」 属性は、形式パラメタを指定するのに使用されるかもしれません(セクション6を見てください)。
If the <proto> sub-field is "udp" the <fmt> sub-fields MUST
reference a media type describing the format under the "audio",
"video", "text", "application", or "message" top-level media
types. The media type registration SHOULD define the packet
format for use with UDP transport.
<proto>サブ分野が"udp"であるなら、<fmt>サブ分野は「オーディオ」の下で形式について説明するメディアタイプ、「ビデオ」という参照、「テキスト」、「アプリケーション」、または「メッセージ」トップレベルメディアタイプがそうしなければなりません。 登録SHOULDがパケット・フォーマットを定義するメディアタイプはUDPと共に輸送を使用します。
For media using other transport protocols, the <fmt> field is
protocol specific. Rules for interpretation of the <fmt> sub-
field MUST be defined when registering new protocols (see Section
8.2.2).
他のトランスポート・プロトコルを使用するメディアにおいて、<fmt>分野はプロトコル特有です。 新しいプロトコルを登録するとき、<fmt>サブ分野の解釈のための規則を定義しなければなりません(セクション8.2.2を見てください)。
6. SDP Attributes
6. SDP属性
The following attributes are defined. Since application writers may add new attributes as they are required, this list is not exhaustive. Registration procedures for new attributes are defined in Section 8.2.4.
以下の属性は定義されます。 それらが必要であるようにアプリケーション作家が新しい属性を加えるかもしれないので、このリストは徹底的ではありません。 新しい属性のための登録手順はセクション8.2.4で定義されます。
a=cat:<category>
=猫: <カテゴリ>。
This attribute gives the dot-separated hierarchical category of
the session. This is to enable a receiver to filter unwanted
sessions by category. There is no central registry of
categories. It is a session-level attribute, and it is not
dependent on charset.
この属性はセッションのドットで切り離された階層的なカテゴリを与えます。 これは、受信機がカテゴリで求められていないセッションをフィルターにかけるのを可能にするためのものです。 カテゴリのどんな中央の登録もありません。 それはセッションレベル属性です、そして、charsetに依存していません。
Handley, et al. Standards Track [Page 24] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[24ページ]。
a=keywds:<keywords>
a=keywds: <キーワード>。
Like the cat attribute, this is to assist identifying wanted
sessions at the receiver. This allows a receiver to select
interesting session based on keywords describing the purpose of
the session; there is no central registry of keywords. It is a
session-level attribute. It is a charset-dependent attribute,
meaning that its value should be interpreted in the charset
specified for the session description if one is specified, or
by default in ISO 10646/UTF-8.
猫属性のように、これは、受信機で欲しいセッションを特定するのを補助するためのものです。受信機がセッションの目的について説明するキーワードに基づく興味深いセッションを選択するのを許容します。 キーワードのどんな中央の登録もありません。 それはセッションレベル属性です。 それはcharset依存する属性です、値が1つがデフォルトでISO10646/UTF-8で指定されるならセッション記述に指定されたcharsetで解釈されるべきであることを意味して。
a=tool:<name and version of tool>
=ツール: <名とツール>のバージョン
This gives the name and version number of the tool used to
create the session description. It is a session-level
attribute, and it is not dependent on charset.
これはツールの数が以前はよく作成していた名前とバージョンにセッション記述を与えます。 それはセッションレベル属性です、そして、charsetに依存していません。
a=ptime:<packet time>
a=ptime: <パケット時間>。
This gives the length of time in milliseconds represented by
the media in a packet. This is probably only meaningful for
audio data, but may be used with other media types if it makes
sense. It should not be necessary to know ptime to decode RTP
or vat audio, and it is intended as a recommendation for the
encoding/packetisation of audio. It is a media-level
attribute, and it is not dependent on charset.
これはパケットにメディアによって表されたミリセカンドで表現される時間の長さを与えます。 これは、たぶんオーディオデータだけには重要ですが、理解できるなら、他のメディアタイプで使用されるかもしれません。 ptimeがRTPか大タンクオーディオを解読するのを知るのは必要であるべきでなくて、それはオーディオのコード化/packetisationのための推薦として意図します。 それはメディアレベル属性です、そして、charsetに依存していません。
a=maxptime:<maximum packet time>
a=maxptime: <の最大のパケット時間>。
This gives the maximum amount of media that can be encapsulated
in each packet, expressed as time in milliseconds. The time
SHALL be calculated as the sum of the time the media present in
the packet represents. For frame-based codecs, the time SHOULD
be an integer multiple of the frame size. This attribute is
probably only meaningful for audio data, but may be used with
other media types if it makes sense. It is a media-level
attribute, and it is not dependent on charset. Note that this
attribute was introduced after RFC 2327, and non-updated
implementations will ignore this attribute.
これは時間としてミリセカンドで言い表された各パケットでカプセル化することができる最大の量のメディアに与えます。 メディアがパケットが表すコネを現代の合計で提示するので計算されていて、SHALLを調節してください。 フレームベースのコーデックのために調節する、フレームの整数倍数がサイズであったならSHOULDを調節してください。 この属性は、たぶんオーディオデータだけには重要ですが、理解できるなら、他のメディアタイプで使用されるかもしれません。 それはメディアレベル属性です、そして、charsetに依存していません。 この属性がRFC2327の後に導入されたことに注意してください。そうすれば、非アップデートされた実装はこの属性を無視するでしょう。
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
parameters>]
a=rtpmap: 名前>/<時計レート>をコード化する<ペイロードタイプ><。[パラメタ>をコード化する/<]
This attribute maps from an RTP payload type number (as used in
an "m=" line) to an encoding name denoting the payload format
to be used. It also provides information on the clock rate and
encoding parameters. It is a media-level attribute that is not
dependent on charset.
この属性はペイロード形式数(「m=」系列に使用されるように)をRTPから使用されるためにペイロード形式を指示するコード化名に写像します。 また、それはクロックレートとパラメタをコード化することの情報を提供します。 それはcharsetに依存しないメディアレベル属性です。
Handley, et al. Standards Track [Page 25] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[25ページ]。
Although an RTP profile may make static assignments of payload
type numbers to payload formats, it is more common for that
assignment to be done dynamically using "a=rtpmap:" attributes.
As an example of a static payload type, consider u-law PCM
coded single-channel audio sampled at 8 kHz. This is
completely defined in the RTP Audio/Video profile as payload
type 0, so there is no need for an "a=rtpmap:" attribute, and
the media for such a stream sent to UDP port 49232 can be
specified as:
RTPプロフィールがペイロード形式数の静的な課題をペイロード形式にするかもしれませんが、その課題がダイナミックに使用し終わっているのが、より一般的である、「a=rtpmap:」 属性。 静的なペイロードタイプに関する例として、u-法のPCMが8kHzで抽出された単独のチャンネルオーディオをコード化したと考えてください。 これがRTP Audio/ビデオプロフィールでペイロードタイプ0と完全に定義されるので必要は全くない、「a=rtpmap:」 属性、および49232を指定できるUDPポートに送られたそのようなストリームのためのメディア:
m=audio 49232 RTP/AVP 0
mはオーディオの49232RTP/AVP0と等しいです。
An example of a dynamic payload type is 16-bit linear encoded
stereo audio sampled at 16 kHz. If we wish to use the dynamic
RTP/AVP payload type 98 for this stream, additional information
is required to decode it:
ダイナミックなペイロードタイプに関する例は16kHzで抽出された16ビットの直線的なコード化されたステレオオーディオです。 このストリームにダイナミックなRTP/AVPペイロードタイプ98を使用したいと思うなら、追加情報がそれを解読するのに必要です:
m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2
オーディオの49232RTP/AVP98m=a=rtpmap: 98L16/16000/2
Up to one rtpmap attribute can be defined for each media format
specified. Thus, we might have the following:
指定されたそれぞれのメディア形式のために最大1つのrtpmap属性を定義できます。 したがって、私たちには、以下があるかもしれません:
m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2
オーディオの49230RTP/AVP96 97 98m=a=rtpmap: 96L8/8000 a=rtpmap: 97L16/8000 a=rtpmap: 98L16/11025/2
RTP profiles that specify the use of dynamic payload types MUST
define the set of valid encoding names and/or a means to
register encoding names if that profile is to be used with SDP.
The "RTP/AVP" and "RTP/SAVP" profiles use media subtypes for
encoding names, under the top-level media type denoted in the
"m=" line. In the example above, the media types are
"audio/l8" and "audio/l16".
そのプロフィールがSDPと共に使用されるつもりであるなら名前をコード化して、ダイナミックなペイロードタイプの使用を指定するRTPプロフィールは妥当なコード化名、そして/または、登録する手段のセットを定義しなければなりません。 "RTP/AVP"と"RTP/SAVP"というプロフィールは名前をコード化するのにメディア血液型亜型を使用します、タイプが「m=」系列で指示したトップレベルメディアの下で。 メディアタイプが上では、例では、そうである、「オーディオ/l8"と「オーディオ/l16"。」
For audio streams, <encoding parameters> indicates the number
of audio channels. This parameter is OPTIONAL and may be
omitted if the number of channels is one, provided that no
additional parameters are needed.
オーディオストリームのために、パラメタ>をコード化する<は音声チャンネルの数を示します。 このパラメタは、チャンネルの数が1であるならOPTIONALであり、省略されるかもしれません、どんな追加パラメタも必要でなければ。
For video streams, no encoding parameters are currently
specified.
ビデオストリームとして、コード化パラメタは全く現在、指定されません。
Additional encoding parameters MAY be defined in the future,
but codec-specific parameters SHOULD NOT be added. Parameters
added to an "a=rtpmap:" attribute SHOULD only be those required
for a session directory to make the choice of appropriate media
追加コード化パラメタは将来、定義されましたが、コーデック特有のパラメタSHOULD NOTであるかもしれません。加えられます。 パラメタが加えた、「a=rtpmap:」 作るセッションディレクトリに必要であるものが適切なメディアの選択であったならSHOULDだけを結果と考えてください。
Handley, et al. Standards Track [Page 26] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[26ページ]。
to participate in a session. Codec-specific parameters should
be added in other attributes (for example, "a=fmtp:").
会議に参加するために。 コーデック特有のパラメタが他の属性で加えられるべきである、(例えば、「a=fmtp:」、)
Note: RTP audio formats typically do not include information
about the number of samples per packet. If a non-default (as
defined in the RTP Audio/Video Profile) packetisation is
required, the "ptime" attribute is used as given above.
以下に注意してください。 RTPオーディオ形式は1パケットあたりのサンプルの数の情報を通常含んでいません。 非デフォルト(RTP Audio/ビデオProfileで定義されるように)packetisationが必要であるなら、"ptime"属性は上に与えるように使用されています。
a=recvonly
a=recvonly
This specifies that the tools should be started in receive-only
mode where applicable. It can be either a session- or media-
level attribute, and it is not dependent on charset. Note that
recvonly applies to the media only, not to any associated
control protocol (e.g., an RTP-based system in recvonly mode
SHOULD still send RTCP packets).
これは、ツールが適切であるところから受信専用モードで始められるべきであると指定します。 それはセッションかメディアレベルが結果と考えるどちらかであるかもしれません、そして、charsetに依存していません。 recvonlyがどんな関連制御プロトコルではなく、メディアだけにも適用されることに注意してください(例えば、recvonlyモードSHOULDのRTPベースのシステムはまだパケットをRTCPに送ります)。
a=sendrecv
a=sendrecv
This specifies that the tools should be started in send and
receive mode. This is necessary for interactive conferences
with tools that default to receive-only mode. It can be either
a session or media-level attribute, and it is not dependent on
charset.
これは、ツールで出発するべきであると指定します。モードを送って、受けてください。 これが受信専用モードをデフォルトとするツールとの対話的な会議に必要です。 それは、セッションかメディアレベル属性のどちらかであるかもしれません、そして、charsetに依存していません。
If none of the attributes "sendonly", "recvonly", "inactive",
and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
default for sessions that are not of the conference type
"broadcast" or "H332" (see below).
属性のいずれも"sendonlyする"ではありません、「recvonlyです」、「不活発であり」、"sendrecv"は存在しています、「sendrecvである」というSHOULDであるなら、会議タイプ「放送」か"H332"(以下を見る)のものでないセッションのためのデフォルトとして想定されてください。
a=sendonly
a=sendonly
This specifies that the tools should be started in send-only
mode. An example may be where a different unicast address is
to be used for a traffic destination than for a traffic source.
In such a case, two media descriptions may be used, one
sendonly and one recvonly. It can be either a session- or
media-level attribute, but would normally only be used as a
media attribute. It is not dependent on charset. Note that
sendonly applies only to the media, and any associated control
protocol (e.g., RTCP) SHOULD still be received and processed as
normal.
これが、ツールで始められるべきであると指定する、発信、-単に、モード。 例はトラフィックの目的地に使用されるトラフィックソースと異なったユニキャストアドレスがことであるところであるかもしれません。 このような場合には、2つのメディア記述が使用されるかもしれなくて、1sendonlyと1つはrecvonlyされます。 それは、セッションかメディアレベル属性のどちらかであることができますが、通常、メディア属性として使用されるだけでしょう。 それはcharsetに依存していません。 それでも、sendonlyがメディア、およびどんな関連制御プロトコル(例えば、RTCP)SHOULDだけにも適用されることに注意してください、そして、受け取られていて標準として処理されてください。
a=inactive
a=不活発です。
This specifies that the tools should be started in inactive
mode. This is necessary for interactive conferences where
users can put other users on hold. No media is sent over an
これは、ツールが不活発なモードで始められるべきであると指定します。 これがユーザが他のユーザを保留にすることができる対話的な会議に必要です。 メディアは全く移動されません。
Handley, et al. Standards Track [Page 27] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[27ページ]。
inactive media stream. Note that an RTP-based system SHOULD
still send RTCP, even if started inactive. It can be either a
session or media-level attribute, and it is not dependent on
charset.
不活発なメディアは流れます。 不活発な状態で始められても、RTPベースのシステムSHOULDがまだRTCPを送ることに注意してください。 それは、セッションかメディアレベル属性のどちらかであるかもしれません、そして、charsetに依存していません。
a=orient:<orientation>
=は: <オリエンテーション>を適応させます。
Normally this is only used for a whiteboard or presentation
tool. It specifies the orientation of a the workspace on the
screen. It is a media-level attribute. Permitted values are
"portrait", "landscape", and "seascape" (upside-down
landscape). It is not dependent on charset.
通常、これはホワイトボードかプレゼンテーション・ツールに使用されるだけです。 それはaのオリエンテーションを指定します。スクリーンの上のワークスペース。 それはメディアレベル属性です。 値が受入れられているのは、「肖像」と、「風景」と、「海景」(逆さの風景)です。 それはcharsetに依存していません。
a=type:<conference type>
=タイプ: <会議タイプ>。
This specifies the type of the conference. Suggested values
are "broadcast", "meeting", "moderated", "test", and "H332".
"recvonly" should be the default for "type:broadcast" sessions,
"type:meeting" should imply "sendrecv", and "type:moderated"
should indicate the use of a floor control tool and that the
media tools are started so as to mute new sites joining the
conference.
これは会議のタイプを指定します。 「加減され」て、「テスト」、および"H332"に「会っ」て、提案された値は「放送されます」。 「タイプしてください: 放送してください」というセッションのためのデフォルト、「タイプ: ミーティング」が"sendrecv"を含意して、「加減されていた状態で以下をタイプするべきである」という「recvonlyに」ことであるべきです。床のコントロールツールの使用と、メディアツールが会議に参加しながら新しいサイトに音を消すために始められるのを示すべきです。
Specifying the attribute "type:H332" indicates that this
loosely coupled session is part of an H.332 session as defined
in the ITU H.332 specification [26]. Media tools should be
started "recvonly".
属性「タイプ: H332」を指定するのは、この緩く結合したセッションがITU H.332仕様[26]に基づき定義されるようにH.332セッションの一部であることを示します。 メディアツールは「recvonlyに」始められるべきです。
Specifying the attribute "type:test" is suggested as a hint
that, unless explicitly requested otherwise, receivers can
safely avoid displaying this session description to users.
属性を指定して、「タイプしてください: テストしてください」は別の方法で明らかに要求されない場合受信機が、このセッション記述をユーザに表示するのを安全に避けることができるというヒントとして示されます。
The type attribute is a session-level attribute, and it is not
dependent on charset.
タイプ属性はセッションレベル属性です、そして、それはcharsetに依存していません。
a=charset:<character set>
a=charset: <文字集合>。
This specifies the character set to be used to display the
session name and information data. By default, the ISO-10646
character set in UTF-8 encoding is used. If a more compact
representation is required, other character sets may be used.
For example, the ISO 8859-1 is specified with the following SDP
attribute:
これは、セッション名とインフォメーション・データを表示するのに使用されるために文字集合を指定します。 デフォルトで、UTF-8コード化におけるISO-10646文字集合は使用されています。 よりコンパクトな表現が必要であるなら、他の文字集合は使用されるかもしれません。 例えば、ISO8859-1は以下のSDP属性で指定されます:
a=charset:ISO-8859-1
a=charset: ISO-8859-1
Handley, et al. Standards Track [Page 28] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[28ページ]。
This is a session-level attribute and is not dependent on
charset. The charset specified MUST be one of those registered
with IANA, such as ISO-8859-1. The character set identifier is
a US-ASCII string and MUST be compared against the IANA
identifiers using a case-insensitive comparison. If the
identifier is not recognised or not supported, all strings that
are affected by it SHOULD be regarded as octet strings.
これは、セッションレベル属性であり、charsetに依存していません。 charsetはともに記名されたものの1つがISO-8859-1などのIANAであったに違いないなら指定しました。 文字集合識別子を米国-ASCIIストリングであり、大文字と小文字を区別しない比較を使用して、IANA識別子に対してたとえなければなりません。 識別子が認識されないか、またはサポートされないなら、すべてがそれで影響を受けるそれを結ぶ、SHOULD、八重奏ストリングと見なされてください。
Note that a character set specified MUST still prohibit the use
of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets
requiring the use of these characters MUST define a quoting
mechanism that prevents these bytes from appearing within text
fields.
文字集合が指定したというメモはまだバイト0x00(Nul)、0x0A(LF)、および0x0d(CR)の使用を禁止しなければなりません。 これらのキャラクタの使用を必要とする文字集合はこれらのバイトがテキストフィールドの中に現れるのを防ぐ引用メカニズムを定義しなければなりません。
a=sdplang:<language tag>
a=sdplang: <言語タグ>。
This can be a session-level attribute or a media-level
attribute. As a session-level attribute, it specifies the
language for the session description. As a media-level
attribute, it specifies the language for any media-level SDP
information field associated with that media. Multiple sdplang
attributes can be provided either at session or media level if
multiple languages in the session description or media use
multiple languages, in which case the order of the attributes
indicates the order of importance of the various languages in
the session or media from most important to least important.
これは、セッションレベル属性かメディアレベル属性であるかもしれません。 セッションレベル属性として、それはセッション記述に言語を指定します。 メディアレベル属性として、それはそのメディアに関連しているどんなメディアレベルSDP情報フィールドにも言語を指定します。 セッション記述かメディアにおける複数の言語が複数の言語を使用するなら、セッションかメディアレベルで複数のsdplang属性を提供できます、その場合、属性の注文は大部分から最も重要でなく重要な状態でセッションかメディアにおける、様々な言語の重要性の注文を示します。
In general, sending session descriptions consisting of multiple
languages is discouraged. Instead, multiple descriptions
SHOULD be sent describing the session, one in each language.
However, this is not possible with all transport mechanisms,
and so multiple sdplang attributes are allowed although NOT
RECOMMENDED.
一般に、セッション記述を複数の言語から成らせるのは、お勧めできないです。 代わりに複数の記述SHOULD、各言語でセッション、1について説明させてください。 しかしながら、これがすべての移送機構で可能で、およびとても複数のsdplangでないので、NOT RECOMMENDEDですが、属性は許容されています。
The "sdplang" attribute value must be a single RFC 3066
language tag in US-ASCII [9]. It is not dependent on the
charset attribute. An "sdplang" attribute SHOULD be specified
when a session is of sufficient scope to cross geographic
boundaries where the language of recipients cannot be assumed,
or where the session is in a different language from the
locally assumed norm.
"sdplang"属性値は米国-ASCII[9]の独身のRFC3066言語タグでなければなりません。 それはcharset属性に依存していません。 セッションが受取人の言語を想定できない地理的な境界に交差できるくらいの範囲のものである、または局所的に想定された標準と異なった言語にはセッションがあるところで指定されていて、"sdplang"はSHOULDを結果と考えます。
a=lang:<language tag>
a=lang: <言語タグ>。
This can be a session-level attribute or a media-level
attribute. As a session-level attribute, it specifies the
default language for the session being described. As a media-
level attribute, it specifies the language for that media,
これは、セッションレベル属性かメディアレベル属性であるかもしれません。 セッションレベル属性として、それは説明されるセッションとしてデフォルト言語を指定します。 メディアの平らな属性として、それはそのメディアに言語を指定します。
Handley, et al. Standards Track [Page 29] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[29ページ]。
overriding any session-level language specified. Multiple lang
attributes can be provided either at session or media level if
the session description or media use multiple languages, in
which case the order of the attributes indicates the order of
importance of the various languages in the session or media
from most important to least important.
どんなセッションレベル言語もくつがえすのは指定しました。 セッション記述かメディアが複数の言語を使用するなら、セッションかメディアレベルで複数のlang属性を提供できます、その場合、属性の注文は大部分から最も重要でなく重要な状態でセッションかメディアにおける、様々な言語の重要性の注文を示します。
The "lang" attribute value must be a single RFC 3066 language
tag in US-ASCII [9]. It is not dependent on the charset
attribute. A "lang" attribute SHOULD be specified when a
session is of sufficient scope to cross geographic boundaries
where the language of recipients cannot be assumed, or where
the session is in a different language from the locally assumed
norm.
"lang"属性値は米国-ASCII[9]の独身のRFC3066言語タグでなければなりません。 それはcharset属性に依存していません。 セッションが受取人の言語を想定できない地理的な境界に交差できるくらいの範囲のものである、または局所的に想定された標準と異なった言語にはセッションがあるところで指定されていて、"lang"はSHOULDを結果と考えます。
a=framerate:<frame rate>
a=framerate: <フレームレート>。
This gives the maximum video frame rate in frames/sec. It is
intended as a recommendation for the encoding of video data.
Decimal representations of fractional values using the notation
"<integer>.<fraction>" are allowed. It is a media-level
attribute, defined only for video media, and it is not
dependent on charset.
これはフレーム/秒で最大のビデオフレームレートを与えます。 それはビデオ・データのコード化のための推薦として意図します。 記法「<整数><断片>」を使用する断片的な値の10進表現は許容されています。 それはビデオメディアのためだけに定義されたメディアレベル属性です、そして、charsetに依存していません。
a=quality:<quality>
=品質: <品質>。
This gives a suggestion for the quality of the encoding as an
integer value. The intention of the quality attribute for
video is to specify a non-default trade-off between frame-rate
and still-image quality. For video, the value is in the range
0 to 10, with the following suggested meaning:
これは整数値としてのコード化の品質のために提案します。 ビデオのための上質の属性の意志はフレームレートと静止画像品質の間の非デフォルトトレードオフを指定することです。 ビデオに関しては、値が以下の提案された意味と共に範囲に0〜10にあります:
10 - the best still-image quality the compression scheme can
give.
5 - the default behaviour given no quality suggestion.
0 - the worst still-image quality the codec designer thinks
is still usable.
10--圧縮技術が与えることができる中で最も良い静止画像品質。 5--どんな上質の提案も与えられなかったデフォルトのふるまい。 0--コーデックデザイナーが考える中で最も悪い静止画像品質はまだ使用可能です。
It is a media-level attribute, and it is not dependent on
charset.
それはメディアレベル属性です、そして、charsetに依存していません。
a=fmtp:<format> <format specific parameters>
a=fmtp: <形式><形式の特定のパラメタ>。
This attribute allows parameters that are specific to a
particular format to be conveyed in a way that SDP does not
have to understand them. The format must be one of the formats
specified for the media. Format-specific parameters may be any
set of parameters required to be conveyed by SDP and given
この属性は、特定の形式に特定のパラメタがSDPがそれらを理解する必要はない方法で伝えられるのを許容します。 形式はメディアに指定された形式の1つであるに違いありません。 形式特有のパラメタはSDPが運んで、与えるのに必要であるどんなセットのパラメタであるかもしれません。
Handley, et al. Standards Track [Page 30] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[30ページ]。
unchanged to the media tool that will use this format. At most
one instance of this attribute is allowed for each format.
この形式を使用するメディアツールに、変わりがありません。 高々、この属性の1つのインスタンスが各形式のために許容されています。
It is a media-level attribute, and it is not dependent on
charset.
それはメディアレベル属性です、そして、charsetに依存していません。
7. Security Considerations
7. セキュリティ問題
SDP is frequently used with the Session Initiation Protocol [15] using the offer/answer model [17] to agree on parameters for unicast sessions. When used in this manner, the security considerations of those protocols apply.
SDPは、Session Initiationプロトコルと共に[15] ユニキャストセッションのためのパラメタに同意するのに申し出/答えモデル[17]を使用することで頻繁に使用されます。 この様に使用されると、それらのプロトコルのセキュリティ問題は適用されます。
SDP is a session description format that describes multimedia sessions. Entities receiving and acting upon an SDP message SHOULD be aware that a session description cannot be trusted unless it has been obtained by an authenticated transport protocol from a known and trusted source. Many different transport protocols may be used to distribute session description, and the nature of the authentication will differ from transport to transport. For some transports, security features are often not deployed. In case a session description has not been obtained in a trusted manner, the endpoint SHOULD exercise care because, among other attacks, the media sessions received may not be the intended ones, the destination where media is sent to may not be the expected one, any of the parameters of the session may be incorrect, or the media security may be compromised. It is up to the endpoint to make a sensible decision taking into account the security risks of the application and the user preferences and may decide to ask the user whether or not to accept the session.
SDPはマルチメディアセッションについて説明するセッション記述形式です。 SHOULDがそれが認証されたトランスポート・プロトコルによって知られているaから得られていない場合セッション記述を信じることができないのを意識していて、ソースを信じたというSDPメッセージを受け取って、作用する実体。 多くの異なったトランスポート・プロトコルがセッション記述を広げるのに使用されるかもしれません、そして、認証の本質は輸送する輸送と異なるでしょう。 いくつかの輸送において、セキュリティ機能はしばしば配布されるというわけではありません。 メディアが送られる目的地が予想されたものでないかもしれない、セッション記述が信じられた方法で得られていなくて、セッションが受け取ったメディアが他の攻撃の中の意図しているものでないかもしれないので、終点SHOULDは注意するか、セッションのパラメタのどれかが不正確であるかもしれませんか、またはメディアセキュリティが感染されるかもしれません。 それは、賢明な決定をアプリケーションのセキュリティ危険を考慮に入れて、ユーザー選択にするように終点まであって、セッションを受け入れるかどうかユーザに尋ねると決めるかもしれません。
One transport that can be used to distribute session descriptions is the Session Announcement Protocol (SAP). SAP provides both encryption and authentication mechanisms, but due to the nature of session announcements it is likely that there are many occasions where the originator of a session announcement cannot be authenticated because the originator is previously unknown to the receiver of the announcement and because no common public key infrastructure is available.
セッション記述を広げるのに使用できる1つの輸送がSession Announcementプロトコル(SAP)です。 SAPは暗号化と認証機構の両方を提供しますが、セッション発表の本質のために、発表の受信機において、創始者が以前に、未知であり、どんな一般的な公開鍵認証基盤も利用可能でないので、多くの時がセッション発表の創始者を認証できないところにありそうです。
On receiving a session description over an unauthenticated transport mechanism or from an untrusted party, software parsing the session should take a few precautions. Session descriptions contain information required to start software on the receiver's system. Software that parses a session description MUST NOT be able to start other software except that which is specifically configured as appropriate software to participate in multimedia sessions. It is normally considered inappropriate for software parsing a session
非認証された移送機構の上、または、信頼されていないパーティーからセッション記述を受けると、セッションを分析するソフトウェアはいくつかの注意を払うはずです。 セッション記述は受信機のシステムにソフトウェアを出発させるのに必要である情報を含んでいます。 マルチメディアセッションのときに参加するために適切なソフトウェアとして明確に構成されるそれを除いて、セッション記述を分析するソフトウェアは他のソフトウェアを始動できるはずがありません。 通常、それはセッションを分析するソフトウェアに不適当であると考えられます。
Handley, et al. Standards Track [Page 31] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[31ページ]。
description to start, on a user's system, software that is appropriate to participate in multimedia sessions, without the user first being informed that such software will be started and giving the user's consent. Thus, a session description arriving by session announcement, email, session invitation, or WWW page MUST NOT deliver the user into an interactive multimedia session unless the user has explicitly pre-authorised such action. As it is not always simple to tell whether or not a session is interactive, applications that are unsure should assume sessions are interactive.
最初にマルチメディアセッションのときにユーザなしで参加するのが適切なソフトウェアがそのようなソフトウェアが始動されると知らされて、ユーザの同意を与えることでありユーザのシステムを始める記述。 したがって、ユーザが明らかにそのような動作をあらかじめ認可していない場合、セッション発表、メール、セッション招待、またはWWWページ到着するセッション記述はインタラクティブ・マルチメディアセッションまでユーザを提供してはいけません。 セッションが対話的であるかどうか言うのがいつも簡単であるというわけではないときに、不確かなアプリケーションは、セッションが対話的であると仮定するべきです。
In this specification, there are no attributes that would allow the recipient of a session description to be informed to start multimedia tools in a mode where they default to transmitting. Under some circumstances it might be appropriate to define such attributes. If this is done, an application parsing a session description containing such attributes SHOULD either ignore them or inform the user that joining this session will result in the automatic transmission of multimedia data. The default behaviour for an unknown attribute is to ignore it.
この仕様には、モードでマルチメディアツールを始めるためにセッション記述の受取人は知識があるのを許容する属性が全くそれらが伝えるのをデフォルトとするところにありません。 いくつかの状況で、そのような属性を定義するのは適切であるかもしれません。 これが完了しているなら、そのような属性SHOULDを含むセッション記述を分析するアプリケーションは、それらを無視するか、またはこのセッションのときに接合するのがマルチメディアデータのオートマをもたらすことをユーザに知らせます。 未知の属性のためのデフォルトのふるまいはそれを無視することです。
In certain environments, it has become common for intermediary systems to intercept and analyse session descriptions contained within other signalling protocols. This is done for a range of purposes, including but not limited to opening holes in firewalls to allow media streams to pass, or to mark, prioritize, or block traffic selectively. In some cases, such intermediary systems may modify the session description, for example, to have the contents of the session description match NAT bindings dynamically created. These behaviours are NOT RECOMMENDED unless the session description is conveyed in such a manner that allows the intermediary system to conduct proper checks to establish the authenticity of the session description, and the authority of its source to establish such communication sessions. SDP by itself does not include sufficient information to enable these checks: they depend on the encapsulating protocol (e.g., SIP or RTSP).
ある環境で、仲介者システムが他の合図プロトコルの中に含まれたセッション記述を妨害して、分析するのは一般的になりました。 さまざまな目的のためにこれをします、メディアストリームが選択的にトラフィックを通るか、マークするか、最優先するか、または妨げるのを許容するためにファイアウォールの他の初めの穴を含んでいて。 いくつかの場合、例えば、セッション記述のコンテンツにダイナミックに作成されたNAT結合を合わせるように、そのような仲介者システムはセッション記述を変更するかもしれません。 セッション記述が仲介者システムがセッション記述の信憑性、およびそのようなコミュニケーションセッションを確立するソースの大家を証明するために適切なチェックを行うことができるそのような方法で伝えられない場合、これらのふるまいはNOT RECOMMENDEDです。 それ自体でSDPはこれらのチェックを可能にするために十分な情報を含んでいません: 彼らは要約プロトコル(例えば、SIPかRTSP)によります。
Use of the "k=" field poses a significant security risk, since it conveys session encryption keys in the clear. SDP MUST NOT be used to convey key material, unless it can be guaranteed that the channel over which the SDP is delivered is both private and authenticated. Moreover, the "k=" line provides no way to indicate or negotiate cryptographic key algorithms. As it provides for only a single symmetric key, rather than separate keys for confidentiality and integrity, its utility is severely limited. The use of the "k=" line is NOT RECOMMENDED, as discussed in Section 5.12.
明確をセッション暗号化キーを運ぶので、「k=」分野の使用は重要なセキュリティリスクを引き起こします。 そうすることができないなら、SDP MUST NOTが主要な材料を運ぶのに使用されて、SDPが提供されるチャンネルが個人的で、かつ認証されているのが保証されてください。 そのうえ、「k=」系列は暗号化キーアルゴリズムを示すか、または交渉する方法を全く提供しません。秘密性と保全のために別々のキーよりむしろ単一の対称鍵だけに備えるとき、ユーティリティは厳しく制限されます。 「k=」系列の使用はセクション5.12で議論するようにNOT RECOMMENDEDです。
Handley, et al. Standards Track [Page 32] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[32ページ]。
8. IANA Considerations
8. IANA問題
8.1. The "application/sdp" Media Type
8.1. 「アプリケーション/sdp」メディアタイプ
One media type registration from RFC 2327 is to be updated, as defined below.
RFC2327からの1つのメディアタイプ登録は以下で定義されるようにアップデートすることです。
To: ietf-types@iana.org
Subject: Registration of media type "application/sdp"
To: ietf-types@iana.org Subject: メディアの登録は「アプリケーション/sdp」をタイプします。
Type name: application
型名: アプリケーション
Subtype name: sdp
Subtypeは以下を命名します。 sdp
Required parameters: None.
必要なパラメタ: なし。
Optional parameters: None.
任意のパラメタ: なし。
Encoding considerations:
SDP files are primarily UTF-8 format text. The "a=charset:"
attribute may be used to signal the presence of other
character sets in certain parts of an SDP file (see
Section 6 of RFC 4566). Arbitrary binary content cannot
be directly represented in SDP.
問題をコード化します: SDPファイルは主としてUTF-8形式テキストです。 「a=charset:」 属性は、SDPファイルのある部分での他の文字集合の存在に合図するのに使用されるかもしれません(RFC4566のセクション6を見てください)。 SDPに直接任意の2進の内容を表すことができません。
Security considerations:
See Section 7 of RFC 4566
セキュリティ問題: RFC4566のセクション7を見てください。
Interoperability considerations:
See RFC 4566
相互運用性問題: RFC4566を見てください。
Published specification:
See RFC 4566
広められた仕様: RFC4566を見てください。
Applications which use this media type:
Voice over IP, video teleconferencing, streaming media, instant
messaging, among others. See also Section 3 of RFC 4566.
このメディアタイプを使用するアプリケーション: IP、ビデオ遠隔会議、ストリーミング・メディアの上で特にインスタントメッセージングを声に出してください。 また、RFC4566のセクション3を見てください。
Additional information:
追加情報:
Magic number(s): None.
File extension(s): The extension ".sdp" is commonly used.
Macintosh File Type Code(s): "sdp "
マジックナンバー(s): なし。 ファイル拡張子(s): 拡大".sdp"は一般的に使用されます。 マッキントッシュファイルタイプは(s)をコード化します: "sdp"
Person & email address to contact for further information:
Mark Handley <M.Handley@cs.ucl.ac.uk>
Colin Perkins <csp@csperkins.org>
IETF MMUSIC working group <mmusic@ietf.org>
詳細のために連絡する人とEメールアドレス: Handley <M.Handley@cs.ucl.ac.uk をマークしてください、gt;、 group <mmusic@ietf.org を扱うコリンパーキンス<csp@csperkins.org>IETF MMUSIC、gt。
Handley, et al. Standards Track [Page 33] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[33ページ]。
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller:
Authors of RFC 4566
IETF MMUSIC working group delegated from the IESG
コントローラを書くか、または変えてください: IESGから代表として派遣されたRFC4566IETF MMUSICワーキンググループの作者
8.2. Registration of Parameters
8.2. パラメタの登録
There are seven field names that may be registered with IANA. Using the terminology in the SDP specification Backus-Naur Form (BNF), they are "media", "proto", "fmt", "att-field", "bwtype", "nettype", and "addrtype".
IANAに登録されるかもしれない7つのフィールド名があります。 SDP仕様バッカス記法(BNF)に用語を使用して、それらは、「メディア」と、"proto"と、"fmt"と、「att-分野」と、"bwtype"と、"nettype"と、"addrtype"です。
8.2.1. Media Types ("media")
8.2.1. メディアタイプ(「メディア」)
The set of media types is intended to be small and SHOULD NOT be extended except under rare circumstances. The same rules should apply for media names as for top-level media content types, and where possible the same name should be registered for SDP as for MIME. For media other than existing top-level media content types, a Standards Track RFC MUST be produced for a new top-level content type to be registered, and the registration MUST provide good justification why no existing media name is appropriate (the "Standards Action" policy of RFC 2434 [8].
メディアタイプのセットが小さいことを意図します。そして、広げられるまれな状況によるSHOULD NOT。 同じ規則は、トップレベルメディアcontent typeのようにメディア名に申し込んで、MIMEによって同じ名前がSDPのために登録されるべきであるのが可能であるところで申し込むべきです。 既存の最高レベルメディアcontent type以外のメディアにおいて、新しいトップレベルcontent typeが登録されるためにStandards Track RFCを生産しなければなりません、そして、登録は既存のメディア名がないのが適切である理由を良い正当化に提供しなければなりません。(RFC2434[8]の「規格動作」方針。
This memo registers the media types "audio", "video", "text", "application", and "message".
このメモはメディアタイプ「オーディオ」、「ビデオ」、「テキスト」、「アプリケーション」、および「メッセージ」を示します。
Note: The media types "control" and "data" were listed as valid in the previous version of this specification [6]; however, their semantics were never fully specified and they are not widely used. These media types have been removed in this specification, although they still remain valid media type capabilities for a SIP user agent as defined in RFC 3840 [24]. If these media types are considered useful in the future, a Standards Track RFC MUST be produced to document their use. Until that is done, applications SHOULD NOT use these types and SHOULD NOT declare support for them in SIP capabilities declarations (even though they exist in the registry created by RFC 3840).
以下に注意してください。 メディアタイプ「コントロール」と「データ」はこの仕様[6]の旧バージョンで有効であるとして記載されました。 しかしながら、それらの意味論は完全に決して指定されたというわけではありません、そして、それらは広く使用されません。 これらのメディアタイプはこの仕様で外されて、彼らはまだ有効なままで残っていますが、メディアはSIPユーザエージェントのためにRFC3840[24]で定義されるように能力をタイプします。 これらのメディアタイプが将来役に立つと考えられるなら、彼らの使用を記録するためにStandards Track RFCを生産しなければなりません。 それが完了するまで、アプリケーションSHOULD NOTはこれらのタイプを使用します、そして、SHOULD NOTはSIP能力宣言で彼らのサポートを宣言します(RFC3840によって作成された登録に存在していますが)。
8.2.2. Transport Protocols ("proto")
8.2.2. トランスポート・プロトコル("proto")
The "proto" field describes the transport protocol used. This SHOULD reference a standards-track protocol RFC. This memo registers three values: "RTP/AVP" is a reference to RTP [19] used under the RTP Profile for Audio and Video Conferences with Minimal Control [20]
"proto"分野は使用されるトランスポート・プロトコルについて説明します。 このSHOULDは標準化過程プロトコルRFCに参照をつけます。 このメモは3つの値を示します: "RTP/AVP"はMinimal ControlがあるAudioとVideoコンファレンスにRTP Profileの下で使用されるRTP[19]の参照です。[20]
Handley, et al. Standards Track [Page 34] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[34ページ]。
running over UDP/IP, "RTP/SAVP" is a reference to the Secure Real- time Transport Protocol [23], and "udp" indicates an unspecified protocol over UDP.
UDP/IPをひいて、"RTP/SAVP"は安全な本当の時間トランスポート・プロトコル[23]の参照です、そして、"udp"はUDPの上に不特定のプロトコルを示します。
If other RTP profiles are defined in the future, their "proto" name SHOULD be specified in the same manner. For example, an RTP profile whose short name is "XYZ" would be denoted by a "proto" field of "RTP/XYZ".
他のRTPプロフィールが将来定義されるなら、指定されていて、それらの"proto"は同じ方法でSHOULDを命名します。 例えば、"XYZ"がだれの省略名であるかというRTPプロフィールは"RTP/XYZ"の「プロト」分野によって指示されるでしょう。
New transport protocols SHOULD be registered with IANA. Registrations MUST reference an RFC describing the protocol. Such an RFC MAY be Experimental or Informational, although it is preferable that it be Standards Track. Registrations MUST also define the rules by which their "fmt" namespace is managed (see below).
新しさ、登録されていて、IANAと共にプロトコルSHOULDを輸送してください。 登録証明書はプロトコルについて説明するRFCに参照をつけなければなりません。 そのようなRFC MAY、ExperimentalかそれがStandards Trackであることが望ましいのですが、Informationalになってください。 また、登録証明書はそれらの"fmt"名前空間が管理される規則を定義しなければなりません(以下を見てください)。
8.2.3. Media Formats ("fmt")
8.2.3. メディア形式("fmt")
Each transport protocol, defined by the "proto" field, has an associated "fmt" namespace that describes the media formats that may be conveyed by that protocol. Formats cover all the possible encodings that might want to be transported in a multimedia session.
"proto"分野によって定義された各トランスポート・プロトコルはそのプロトコルによって伝えられるかもしれないメディア書式を説明する関連"fmt"名前空間を持っています。 形式はマルチメディアセッションのときに輸送されたいかもしれないすべての可能なencodingsをカバーしています。
RTP payload formats under the "RTP/AVP" and "RTP/SAVP" profiles MUST use the payload type number as their "fmt" value. If the payload type number is dynamically assigned by this session description, an additional "rtpmap" attribute MUST be included to specify the format name and parameters as defined by the media type registration for the payload format. It is RECOMMENDED that other RTP profiles that are registered (in combination with RTP) as SDP transport protocols specify the same rules for the "fmt" namespace.
"RTP/AVP"と"RTP/SAVP"というプロフィールの下のRTPペイロード形式はそれらの"fmt"値としてペイロード形式数を使用しなければなりません。 ペイロード形式数がこのセッション記述でダイナミックに割り当てられるなら、形式名を指定するために追加"rtpmap"属性を含まなければなりません、そして、メディアによって定義されるパラメタはペイロード形式のための登録をタイプします。 他のSDPがプロトコルを輸送するとき登録された(RTPと組み合わせた)RTPプロフィールが"fmt"名前空間に同じ規則を指定するのは、RECOMMENDEDです。
For the "udp" protocol, new formats SHOULD be registered. Use of an existing media subtype for the format is encouraged. If no media subtype exists, it is RECOMMENDED that a suitable one be registered through the IETF process [31] by production of, or reference to, a standards-track RFC that defines the transport protocol for the format.
登録されていて、"udp"プロトコルと、新しさがSHOULDをフォーマットするので。 既存のメディア「副-タイプ」の形式の使用は奨励されます。 メディア「副-タイプ」が全く存在していないなら、適当なものがIETFプロセス[31]を通して生産で示されるのが、RECOMMENDEDである、参照、形式のためにトランスポート・プロトコルを定義する標準化過程RFC。
For other protocols, formats MAY be registered according to the rules of the associated "proto" specification.
他のプロトコルにおいて、関連"proto"仕様の規則に従って、形式は示されるかもしれません。
Registrations of new formats MUST specify which transport protocols they apply to.
新しい形式の登録証明書は、それらが、どのトランスポート・プロトコルがそうするのに申し込むかを指定しなければなりません。
Handley, et al. Standards Track [Page 35] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[35ページ]。
8.2.4. Attribute Names ("att-field")
8.2.4. 属性名(「att-分野」)
Attribute field names ("att-field") MUST be registered with IANA and
documented, because of noticeable issues due to conflicting
attributes under the same name. Unknown attributes in SDP are simply
ignored, but conflicting ones that fragment the protocol are a
serious problem.
属性フィールド名(「att-分野」)をIANAに登録されて、記録しなければなりません、同じ名前の下における闘争属性によるめぼしい問題のために。 SDPの未知の属性は単に無視されますが、プロトコルを断片化する闘争ものは深刻な問題です。
New attribute registrations are accepted according to the "Specification Required" policy of RFC 2434, provided that the specification includes the following information:
「仕様が必要である」というRFC2434の方針に応じて、新しい属性登録証明書を受け入れます、仕様が以下の情報を含んでいれば:
o contact name, email address, and telephone number
o 連絡名、Eメールアドレス、および電話番号
o attribute name (as it will appear in SDP)
o 属性名(SDPに現れるように)
o long-form attribute name in English
o 英語の長いフォーム属性名
o type of attribute (session level, media level, or both)
o 属性のタイプ(セッションレベル、メディアレベル、または両方)
o whether the attribute value is subject to the charset attribute
o 属性値はcharset属性を受けることがあるので
o a one-paragraph explanation of the purpose of the attribute
o 属性の目的の1つのパラグラフの説明
o a specification of appropriate attribute values for this attribute
o この属性のための適切な属性値の仕様
The above is the minimum that IANA will accept. Attributes that are expected to see widespread use and interoperability SHOULD be documented with a standards-track RFC that specifies the attribute more precisely.
上記はIANAが受け入れる最小限です。 普及使用と相互運用性SHOULDが、より正確に属性を指定する標準化過程RFCと共に記録されるのを見ると予想される属性。
Submitters of registrations should ensure that the specification is in the spirit of SDP attributes, most notably that the attribute is platform independent in the sense that it makes no implicit assumptions about operating systems and does not name specific pieces of software in a manner that might inhibit interoperability.
登録証明書のSubmittersはSDP属性の精神には仕様があって、属性がオペレーティングシステムに関するどんな暗黙の仮定もしないで、また特定のソフトウェアを命名しないという意味で相互運用性を禁止するかもしれない方法で最も著しく、プラットホーム独立者であることを確実にするはずです。
IANA has registered the following initial set of attribute names
("att-field" values), with definitions as in Section 6 of this memo
(these definitions update those in RFC 2327):
IANAはこのメモのセクション6のように以下の始発の属性名(「att-分野」値)を定義に登録しました(これらの定義はRFC2327でそれらをアップデートします):
Handley, et al. Standards Track [Page 36] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[36ページ]。
Name | Session or Media level? | Dependent on charset?
----------+-------------------------+----------------------
cat | Session | No
keywds | Session | Yes
tool | Session | No
ptime | Media | No
maxptime | Media | No
rtpmap | Media | No
recvonly | Either | No
sendrecv | Either | No
sendonly | Either | No
inactive | Either | No
orient | Media | No
type | Session | No
charset | Session | No
sdplang | Either | No
lang | Either | No
framerate | Media | No
quality | Media | No
fmtp | Media | No
名前| セッションですかそれともメディアレベルですか? | charsetに依存していますか? ----------+-------------------------+---------------------- 猫| セッション| keywdsがありません。| セッション| はいツール| セッション| ptimeがありません。| メディア| maxptimeがありません。| メディア| rtpmapがありません。| メディア| recvonlyがありません。| どちらか| sendrecvがありません。| どちらか| sendonlyがありません。| どちらか| 不活発でない| どちらか| 適応しません。| メディア| タイプがありません。| セッション| charsetがありません。| セッション| sdplangがありません。| どちらか| langがありません。| どちらか| framerateがありません。| メディア| 品質がありません。| メディア| fmtpがありません。| メディア| いいえ
8.2.5. Bandwidth Specifiers ("bwtype")
8.2.5. 帯域幅特許説明書の作成書("bwtype")
A proliferation of bandwidth specifiers is strongly discouraged.
帯域幅特許説明書の作成書の増殖は強くお勧めできないです。
New bandwidth specifiers ("bwtype" fields) MUST be registered with
IANA. The submission MUST reference a standards-track RFC specifying
the semantics of the bandwidth specifier precisely, and indicating
when it should be used, and why the existing registered bandwidth
specifiers do not suffice.
新しい帯域幅特許説明書の作成書("bwtype"分野)をIANAに登録しなければなりません。 服従は正確に帯域幅特許説明書の作成書の意味論を指定して、それがいつ使用されるべきであるか、そして、既存の登録された帯域幅特許説明書の作成書がなぜ十分でないかを示す標準化過程RFCに参照をつけなければなりません。
IANA has registered the bandwidth specifiers "CT" and "AS" with definitions as in Section 5.8 of this memo (these definitions update those in RFC 2327).
IANAはこのメモのセクション5.8のように帯域幅特許説明書の作成書の「コネチカット」と“AS"を定義に登録しました(これらの定義はRFC2327でそれらをアップデートします)。
8.2.6. Network Types ("nettype")
8.2.6. ネットワークタイプ("nettype")
New network types (the "nettype" field) may be registered with IANA if SDP needs to be used in the context of non-Internet environments. Although these are not normally the preserve of IANA, there may be circumstances when an Internet application needs to interoperate with a non-Internet application, such as when gatewaying an Internet telephone call into the Public Switched Telephone Network (PSTN). The number of network types should be small and should be rarely extended. A new network type cannot be registered without registering at least one address type to be used with that network
SDPが、非インターネット環境の文脈で使用される必要があるなら、新しいネットワークタイプ("nettype"分野)はIANAに示されるかもしれません。 これらは通常IANAの保護区ではありませんが、インターネットアプリケーションが、Public Switched Telephone Network(PSTN)にインターネット通話をgatewayingしながらいつなどの非インターネットアプリケーションで共同利用する必要があるとき、事情があるかもしれません。 ネットワークタイプの数を小さいはずであり、めったに広げるべきではありません。 そのネットワークと共に使用されるために少なくとも1つのアドレスタイプを示さないで、新しいネットワークタイプを示すことができません。
Handley, et al. Standards Track [Page 37] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[37ページ]。
type. A new network type registration MUST reference an RFC that gives details of the network type and address type and specifies how and when they would be used.
タイプしてください。 新しいネットワークタイプ登録は、ネットワークタイプとアドレスタイプの詳細を明らかにするRFCに参照をつけなければならなくて、それらがどのように、いつ使用されるかを指定します。
IANA has registered the network type "IN" to represent the Internet, with definition as in Sections 5.2 and 5.7 of this memo (these definitions update those in RFC 2327).
IANAは、インターネットを表すためにこのメモのセクション5.2と5.7のように「中に」ネットワークタイプを定義に示しました(これらの定義はRFC2327でそれらをアップデートします)。
8.2.7. Address Types ("addrtype")
8.2.7. アドレスタイプ("addrtype")
New address types ("addrtype") may be registered with IANA. An
address type is only meaningful in the context of a network type, and
any registration of an address type MUST specify a registered network
type or be submitted along with a network type registration. A new
address type registration MUST reference an RFC giving details of the
syntax of the address type. Address types are not expected to be
registered frequently.
新しいアドレスタイプ("addrtype")はIANAに示されるかもしれません。 アドレスタイプが単にネットワークタイプの文脈で重要であり、アドレスタイプのどんな登録も登録されたネットワークタイプを指定しなければならないか、またはネットワークタイプ登録と共に提出しなければなりません。 新しいアドレスタイプ登録はアドレスの構文のRFC付与の詳細がタイプする参照がそうしなければなりません。 頻繁にアドレスタイプが登録されないと予想されます。
IANA has registered the address types "IP4" and "IP6" with definitions as in Sections 5.2 and 5.7 of this memo (these definitions update those in RFC 2327).
IANAがアドレスタイプを示した、「IP4"と「定義があるIP6"は同じくらい中で5.2とこの5.7のメモを区分(これらの定義はRFC2327でそれらをアップデートします)」。
8.2.8. Registration Procedure
8.2.8. 登録手順
In the RFC documentation that registers SDP "media", "proto", "fmt", "bwtype", "nettype", and "addrtype" fields, the authors MUST include the following information for IANA to place in the appropriate registry:
SDP「メディア」、"proto"、"fmt"、"bwtype"、"nettype"、および"addrtype"分野を示すRFCドキュメンテーションでは、IANAが適切な登録で入賞するように、作者は以下の情報を入れなければなりません:
o contact name, email address, and telephone number
o 連絡名、Eメールアドレス、および電話番号
o name being registered (as it will appear in SDP)
o 登録される名前(SDPに現れるように)
o long-form name in English
o 英語の長いフォーム名
o type of name ("media", "proto", "fmt", "bwtype", "nettype", or
"addrtype")
o 名前のタイプ(「メディア」、"proto"、"fmt"、"bwtype"、"nettype"、または"addrtype")
o a one-paragraph explanation of the purpose of the registered name
o 登録名の目的の1つのパラグラフの説明
o a reference to the specification for the registered name (this
will typically be an RFC number)
o 仕様の登録名の参照(これは通常RFC番号になるでしょう)
IANA may refer any registration to the IESG for review, and may request revisions to be made before a registration will be made.
IANAは、レビューについてどんな登録もIESGを参照して、登録をする前に作るよう改正に要求するかもしれません。
Handley, et al. Standards Track [Page 38] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[38ページ]。
8.3. Encryption Key Access Methods
8.3. 暗号化の主要なアクセス法
The IANA previously maintained a table of SDP encryption key access
method ("enckey") names. This table is obsolete, since the "k=" line
is not extensible. New registrations MUST NOT be accepted.
IANAは以前に、SDPの暗号化の主要なアクセス法("enckey")名のテーブルを維持しました。 「k=」系列が広げることができないので、このテーブルは時代遅れです。 新しい登録証明書を受け入れてはいけません。
9. SDP Grammar
9. SDP文法
This section provides an Augmented BNF grammar for SDP. ABNF is defined in [4].
このセクションはAugmented BNF文法をSDPに供給します。 ABNFは[4]で定義されます。
; SDP Syntax
session-description = proto-version
origin-field
session-name-field
information-field
uri-field
email-fields
phone-fields
connection-field
bandwidth-fields
time-fields
key-field
attribute-fields
media-descriptions
; SDP Syntaxセッション記述はproto-バージョン発生源分野セッション名前欄情報フィールドuri-分野メール分野電話分野接続分野帯域幅分野時間分野キーフィールド属性分野メディア記述と等しいです。
proto-version = %x76 "=" 1*DIGIT CRLF
;this memo describes version 0
proto-バージョン=%x76は1*ケタCRLFと「等しい」; このメモはバージョン0について説明します。
origin-field = %x6f "=" username SP sess-id SP sess-version SP
nettype SP addrtype SP unicast-address CRLF
発生源分野=%x6fはユーザ名SP sess-イドSP sess-バージョンSP nettype SP addrtype SPユニキャストアドレスCRLFと「等しいです」。
session-name-field = %x73 "=" text CRLF
セッション名前欄=%x73はテキストCRLFと「等しいです」。
information-field = [%x69 "=" text CRLF]
情報フィールド=[%x69「=」テキストCRLF]
uri-field = [%x75 "=" uri CRLF]
uri-分野=[%x75「=」ユリCRLF]
email-fields = *(%x65 "=" email-address CRLF)
メール分野は*と等しいです。(%x65「=」EメールアドレスCRLF)
phone-fields = *(%x70 "=" phone-number CRLF)
電話分野は*と等しいです。(%x70「=」電話番号CRLF)
connection-field = [%x63 "=" nettype SP addrtype SP
connection-address CRLF]
;a connection field must be present
;in every media description or at the
;session-level
または、接続分野が存在していなければならないというあらゆるメディア記述における接続分野=[%x63はnettype SP addrtype SP接続アドレスCRLFと「等しい」]、; セッションレベル
Handley, et al. Standards Track [Page 39] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[39ページ]。
bandwidth-fields = *(%x62 "=" bwtype ":" bandwidth CRLF)
帯域幅分野は*と等しいです。「(%、x62「=」が」 : 」 帯域幅CRLFをbwtypeする、)
time-fields = 1*( %x74 "=" start-time SP stop-time
*(CRLF repeat-fields) CRLF)
[zone-adjustments CRLF]
時間分野=1*(%x74は開始時刻SP停止時間の*(CRLF反復分野)CRLFと「等しいです」)[ゾーン調整CRLF]
repeat-fields = %x72 "=" repeat-interval SP typed-time
1*(SP typed-time)
反復分野は%x72「=」反復間隔SPタイプされた時間1*と等しいです。(SPのタイプされた時間)
zone-adjustments = %x7a "=" time SP ["-"] typed-time
*(SP time SP ["-"] typed-time)
ゾーン調整=%x7aは時間SP[「-」]タイプされた時間*と「等しいです」。(SPの時間のSP[「-」]のタイプされた時間)
key-field = [%x6b "=" key-type CRLF]
キーフィールド=[%x6b「=」主要なタイプCRLF]
attribute-fields = *(%x61 "=" attribute CRLF)
属性分野は*と等しいです。(%x61「=」属性CRLF)
media-descriptions = *( media-field
information-field
*connection-field
bandwidth-fields
key-field
attribute-fields )
メディア記述は*と等しいです。(メディア分野情報フィールド*接続分野帯域幅分野キーフィールド属性分野)
media-field = %x6d "=" media SP port ["/" integer]
SP proto 1*(SP fmt) CRLF
メディア分野=%x6dはメディアSPポート[「/」整数]SPプロト1*(SP fmt)CRLFと「等しいです」。
; sub-rules of 'o='
username = non-ws-string
;pretty wide definition, but doesn't
;include space
; しかし、ユーザ名が非wsのストリング; 全く広い定義と等しいという'o='のサブ規則はそうしません; スペースを含めてください。
sess-id = 1*DIGIT
;should be unique for this username/host
sess-イド=1*DIGIT; このユーザ名/ホストにとってユニークであるべきです。
sess-version = 1*DIGIT
sess-バージョン=1*DIGIT
nettype = token
;typically "IN"
nettype=トークン; 通常「IN」
addrtype = token
;typically "IP4" or "IP6"
addrtypeがトークンと通常等しい、「IP4"か"IP6""
; sub-rules of 'u='
uri = URI-reference
; see RFC 3986
; 'u='uriのサブ規則はURI参照と等しいです。 RFC3986を見てください。
Handley, et al. Standards Track [Page 40] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[40ページ]。
; sub-rules of 'e=', see RFC 2822 for definitions
email-address = address-and-comment / dispname-and-address
/ addr-spec
address-and-comment = addr-spec 1*SP "(" 1*email-safe ")"
dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">"
; 'e='のサブ規則です、定義EメールアドレスのためのRFC2822が">"という「(「1*メール安全な」)」というaddr-仕様アドレスとコメント=addr-仕様1*SP dispnameとアドレス=1*メール安全な1*SP dispnameとアドレスとコメント/アドレス/"<"addr-仕様と等しいのを見てください。
; sub-rules of 'p='
phone-number = phone *SP "(" 1*email-safe ")" /
1*email-safe "<" phone ">" /
phone
; 'p='電話番号1*メール「(「1*メール安全な」)」という=電話*SP/安全な"<"電話">"/電話のサブ規則
phone = ["+"] DIGIT 1*(SP / "-" / DIGIT)
電話は[「+」]ケタ1*と等しいです。(SP/「-」/ケタ)
; sub-rules of 'c=' connection-address = multicast-address / unicast-address
; 'c='接続アドレスのサブ規則はユニキャストマルチキャストアドレス/アドレスと等しいです。
; sub-rules of 'b=' bwtype = token
; 'b='bwtypeのサブ規則はトークンと等しいです。
bandwidth = 1*DIGIT
帯域幅は1*DIGITと等しいです。
; sub-rules of 't=' start-time = time / "0"
; 開始時刻=時間/「0インチ」の間の'=でないサブ規則'
stop-time = time / "0"
= 時間/「0インチ」の間の停止時間
time = POS-DIGIT 9*DIGIT
; Decimal representation of NTP time in
; seconds since 1900. The representation
; of NTP time is an unbounded length field
; containing at least 10 digits. Unlike the
; 64-bit representation used elsewhere, time
; in SDP does not wrap in the year 2036.
時間はPOS-DIGIT9*DIGITと等しいです。 中のNTP時間の10進表現。 1900年以来の秒。 表現。 NTPでは、時間は限りない長さの分野です。 少なくとも10ケタを含んでいます。 。 ほかの場所で使用された、64ビットの表現、時間。 SDPでは、1年間2036を包装しません。
; sub-rules of 'r=' and 'z=' repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit]
; 'r='と'z='反復間隔=POS-DIGIT*DIGITのサブ規則[固定lenタイム・ユニット]
typed-time = 1*DIGIT [fixed-len-time-unit]
タイプされた時間は1*DIGITと等しいです。[固定lenタイム・ユニット]
fixed-len-time-unit = %x64 / %x68 / %x6d / %x73
固定lenタイム・ユニット=%x64/%x68/%x6d/%x73
; sub-rules of 'k='
key-type = %x70 %x72 %x6f %x6d %x70 %x74 / ; "prompt"
%x63 %x6c %x65 %x61 %x72 ":" text / ; "clear:"
%x62 %x61 %x73 %x65 "64:" base64 / ; "base64:"
%x75 %x72 %x69 ":" uri ; "uri:"
; 'k='主要なタイプのサブ規則=%x70%x72%x6f%x6d%x70%x74/。 「「」 %x63%x6c%x65%x61%x72をうながしてください」」 テキスト/。 「クリアしてください」 %x62%x61%x73%x65、「64:」 base64/。 「base64:」 「%x75%x72%x69」:、」 uri。 「uri:」
base64 = *base64-unit [base64-pad]
base64は*base64-ユニットと等しいです。[base64-パッド]
Handley, et al. Standards Track [Page 41] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[41ページ]。
base64-unit = 4base64-char base64-pad = 2base64-char "==" / 3base64-char "=" base64-char = ALPHA / DIGIT / "+" / "/"
「2base64-炭の「= 」 /3base64-炭がbase64-焦げと「等しい」という=アルファ/ケタ/「+」/」base64-ユニット=4base64-炭base64-パッド=/」
; sub-rules of 'a=' attribute = (att-field ":" att-value) / att-field
; 「'=のサブ規則'属性=(」 : 」 att-値をattさばきます)/att-分野
att-field = token
att-分野=トークン
att-value = byte-string
att-値=バイトストリング
; sub-rules of 'm='
media = token
;typically "audio", "video", "text", or
;"application"
; または、'サブ規則であることは、=です'というメディア通常=トークン;「オーディオ」、「ビデオ」、「テキスト」、;、「アプリケーション」
fmt = token
;typically an RTP payload type for audio
;and video media
fmtはトークン(オーディオのための通常RTPペイロードタイプ)とビデオメディアと等しいです。
proto = token *("/" token)
;typically "RTP/AVP" or "udp"
proto=象徴*(「/」象徴); 通常"RTP/AVP"か"udp"
port = 1*DIGIT
ポートは1*DIGITと等しいです。
; generic sub-rules: addressing unicast-address = IP4-address / IP6-address / FQDN / extn-addr
; 一般的なサブ規則: ユニキャストアドレスを記述するのはIP6IP4-アドレス/アドレス/FQDN/extn-addrと等しいです。
multicast-address = IP4-multicast / IP6-multicast / FQDN
/ extn-addr
マルチキャストアドレスはIP6IP4-マルチキャスト/マルチキャスト/FQDN/extn-addrと等しいです。
IP4-multicast = m1 3( "." decimal-uchar )
"/" ttl [ "/" integer ]
; IPv4 multicast addresses may be in the
; range 224.0.0.0 to 239.255.255.255
」 「IP4-マルチキャスト=m1 3(「.」 10進uchar)」/ttl[「/」整数]。 IPv4マルチキャストアドレスがあるかもしれない、。 範囲224.0.0、.0〜239.255、.255、.255
m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
("23" DIGIT )
m1が等しい、(「22インチ(「6インチ/」の「4インチ/」の5インチ/の7インチ/「8インチ/」9インチ)/」(「23インチのケタ)」
IP6-multicast = hexpart [ "/" integer ]
; IPv6 address starting with FF
IP6-マルチキャストはhexpart[「/」整数]と等しいです。 FFから始まるIPv6アドレス
ttl = (POS-DIGIT *2DIGIT) / "0"
ttl=(POS-DIGIT*2DIGIT)/「0インチ」
FQDN = 4*(alpha-numeric / "-" / ".")
; fully qualified domain name as specified
; in RFC 1035 (and updates)
「FQDN=4*、(アルファベット数字式/「-」/、」、」、)、。 指定されるとしての完全修飾ドメイン名。 RFC1035で(そして、アップデート)
Handley, et al. Standards Track [Page 42] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[42ページ]。
IP4-address = b1 3("." decimal-uchar)
IP4-アドレスはb1 3と等しいです。(「. 」 10進uchar、)
b1 = decimal-uchar
; less than "224"
b1は10進ucharと等しいです。 「224」以下
; The following is consistent with RFC 2373 [30], Appendix B. IP6-address = hexpart [ ":" IP4-address ]
; 以下がRFC2373[30]と一致している、Appendix B. IP6-アドレスはhexpartと等しいです。[「:」 IP4-アドレス]
hexpart = hexseq / hexseq "::" [ hexseq ] /
"::" [ hexseq ]
「hexpartはhexseq / hexseqと等しい」:、:、」 「[hexseq]/」:、:、」 [hexseq]
hexseq = hex4 *( ":" hex4)
hexseqはhex4*と等しいです。(「:」 hex4)
hex4 = 1*4HEXDIG
hex4は1*4HEXDIGと等しいです。
; Generic for other address families extn-addr = non-ws-string
; 他のアドレス家族extn-addrのためのジェネリックは非wsのストリングと等しいです。
; generic sub-rules: datatypes
text = byte-string
;default is to interpret this as UTF8 text.
;ISO 8859-1 requires "a=charset:ISO-8859-1"
;session-level attribute to be used
; 一般的なサブ規則: データ型式テキストはバイトストリングと等しいです; デフォルトはUTF8テキストとしてこれを解釈することです。 ;、ISO8859-1が必要である、「a=charset:、ISO8859、1インチ、; 使用されるべきセッションレベル属性、」
byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
;any byte except NUL, CR, or LF
バイトストリング=1*(%のx01-09/%のx0B-0C/%のx0E-FF); NUL、CR、またはLF以外のどんなバイト
non-ws-string = 1*(VCHAR/%x80-FF)
;string of visible characters
非wsのストリング=1*(VCHAR/%x80-FF); 目に見えるキャラクタのストリング
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7E
%x21/%x23-27/%x2A-2B/%x2D-2E/%x30-39/%x41-5A/%x5E-7象徴炭=E
token = 1*(token-char)
象徴=1*(象徴炭)
email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
;any byte except NUL, CR, LF, or the quoting
;characters ()<>
x0B-0C/%のメール安全な=%x01-09/%x0E-27/%x2A-3B/%x3D/%x3F-FF; NUL、CR、LF、または引用を除いたどんなバイトも; キャラクタ()<>。
integer = POS-DIGIT *DIGIT
整数=POS-DIGIT*DIGIT
; generic sub-rules: primitives alpha-numeric = ALPHA / DIGIT
; 一般的なサブ規則: 基関数アルファベット数字式はアルファー/DIGITと等しいです。
POS-DIGIT = %x31-39 ; 1 - 9
POS-ケタ=%x31-39。 1 - 9
Handley, et al. Standards Track [Page 43] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[43ページ]。
decimal-uchar = DIGIT
/ POS-DIGIT DIGIT
/ ("1" 2*(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
10進ucharがDIGIT / POS-DIGIT DIGIT /と等しい、(「1インチ2*(ケタ)/、(「2インチ、(「0インチ/」の1インチ/「2インチ/」3インチ/、「4インチ) ケタ) /」("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
; external references:
; ALPHA, DIGIT, CRLF, SP, VCHAR: from RFC 4234
; URI-reference: from RFC 3986
; addr-spec: from RFC 2822
; 外部参照: ; アルファー、ケタ、CRLF、SP、VCHAR: RFC4234から。 URI参照: RFC3986から。 addr-仕様: RFC2822から
10. Summary of Changes from RFC 2327
10. RFC2327からの変化の概要
The memo has been significantly restructured, incorporating a large number of clarifications to the specification in light of use. With the exception of those items noted below, the changes to the memo are intended to be backward-compatible clarifications. However, due to inconsistencies and unclear definitions in RFC 2327 it is likely that some implementations interpreted that memo in ways that differ from this version of SDP.
使用の観点から多くの明確化を仕様に取り入れて、メモはかなり再構築されました。 以下に述べられたそれらの項目を除いて、メモへの変化は後方コンパチブル明確化であることを意図します。 しかしながら、RFC2327との矛盾と不明瞭な定義のため、いくつかの実現がSDPのこのバージョンと異なっている方法でそのメモを解釈しそうでした。
The ABNF grammar in Section 9 has been extensively revised and updated, correcting a number of mistakes and incorporating the RFC 3266 IPv6 extensions. Known inconsistencies between the grammar and the specification text have been resolved.
セクション9のABNF文法を手広く改訂して、アップデートしました、多くの誤りを修正して、RFC3266IPv6拡張子を取り入れて。 文法と仕様テキストの間の知られている矛盾は決議されました。
A media type registration for SDP is included. Requirements for the registration of attributes and other parameters with IANA have been clarified and tightened (Section 8). It is noted that "text" and "message" are valid media types for use with SDP, but that "control" and "data" are under-specified and deprecated.
SDPのためのメディアタイプ登録は含まれています。 IANAがある属性と他のパラメタの登録のための要件は、はっきりさせられて、きびしくされました(セクション8)。 「コントロール」と「データ」が「テキスト」と「メッセージ」がSDPとの使用のための有効なメディアタイプですが、下の指定されていて推奨しないことに注意されます。
RFC 2119 terms are now used throughout to specify requirements levels. Certain of those requirements, in particular in relation to parameter registration, are stricter than those in RFC 2327.
用語が現在要件レベルを指定するのに使用されるRFC2119。 それらの要件が特にパラメタ登録と関連して確かであるのは、RFCのそれらより厳しい2327です。
The "RTP/SAVP" RTP profile and its "fmt" namespace are registered.
"RTP/SAVP"というRTPプロフィールとその"fmt"名前空間は登録されています。
The attributes "a=inactive" and "a=maxptime" have been added.
属性、「a=不活発である、」 "a=maxptime"は加えられます。
RFC 2327 mandated that either "e=" or "p=" was required. Both are now optional, to reflect actual usage.
RFC2327は、「e=」か「p=」のどちらかが必要であったのを強制しました。 両方が、現在、実際の用法を反映するために任意です。
The significant limitations of the "k=" field are noted, and its use is deprecated.
「k=」分野の重要な制限は注意されます、そして、使用は推奨しないです。
Most uses of the "x-" prefix notation for experimental parameters are disallowed and the other uses are deprecated.
実験パラメタのための「x」前置表記法のほとんどの用途が禁じられます、そして、他の用途は推奨しないです。
Handley, et al. Standards Track [Page 44] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[44ページ]。
11. Acknowledgements
11. 承認
Many people in the IETF Multiparty Multimedia Session Control (MMUSIC) working group have made comments and suggestions contributing to this document. In particular, we would like to thank Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson, and Spencer Dawkins.
IETF Multiparty Multimedia Session Control(MMUSIC)ワーキンググループの多くの人々がこのドキュメントに貢献するコメントと提案をしました。 特に、イブSchooler、スティーブCasner、ビル・フェナー、アリソン・マンキン、ロスフィンリースン、ピーター・パルネス、ヨルク・オット、カルステン・ボルマン、スティーブ・ハンナ、ジョナサンレノックス、キースDrage、ショーン・オルソン、バーニーHoeneisen、ジョナサン・ローゼンバーグ、ジョン・エルウェル、フレミングAndreasen、ジョン・ピーターソン、およびスペンサー・ダウキンズに感謝申し上げます。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[1]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[2]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[4] エドクロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[5]Yergeau、F.、「UTF-8、ISO10646インチ、STD63、RFC3629、11月2003日の変化形式
[6] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[6] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[7]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「一般的な構文」、STD66、RFC3986、2005年1月。
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[8]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[9] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001.
Alvestrand(H.)が「言語の識別のためにタグ付けをする」[9]、BCP47、RFC3066、2001年1月。
[10] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in
Session Description Protocol (SDP)", RFC 3266, June 2002.
オルソン、S.、キャマリロ、G.、およびA.ローチが「IPv6のためにセッション記述プロトコル(SDP)で支持する」[10]、RFC3266、2002年6月。
Handley, et al. Standards Track [Page 45] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[45ページ]。
[11] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", RFC
3490, March 2003.
[11]Faltstrom、P.、ホフマン、P.、およびA.コステロ、「アプリケーション(IDNA)におけるドメイン名を国際的にします」、RFC3490、2003年3月。
[12] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003.
[12]Josefsson、2003年7月のS.、「Base16、Base32、およびBase64データEncodings」RFC3548。
12.2. Informative References
12.2. 有益な参照
[13] Mills, D., "Network Time Protocol (Version 3) Specification,
Implementation", RFC 1305, March 1992.
[13] 工場、D.、「ネットワーク時間プロトコル(バージョン3)仕様、実現」RFC1305、3月1992日
[14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement
Protocol", RFC 2974, October 2000.
[14] ハンドレーとM.とパーキンス、C.とE.ウィーラン、「セッション発表プロトコル」、RFC2974、2000年10月。
[15] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[15] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming
Protocol (RTSP)", RFC 2326, April 1998.
1998年4月の[16]SchulzrinneとH.とラオ、A.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」RFC2326。
[17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[17] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[18] Camarillo, G., Eriksson, G., Holler, J., and H. Schulzrinne,
"Grouping of Media Lines in the Session Description Protocol
(SDP)", RFC 3388, December 2002.
[18]キャマリロ、G.、エリクソン、G.、叫び声、J.、およびH.Schulzrinne、「メディアの組分けはセッション記述プロトコル(SDP)で立ち並んでいます」、RFC3388、2002年12月。
[19] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", STD 64,
RFC 3550, July 2003.
[19]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
[20] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video
Conferences with Minimal Control", STD 65, RFC 3551, July 2003.
[20] Schulzrinne、H.、およびS.Casner、「オーディオのためのRTPプロフィールと最小量があるテレビ会議システムは制御します」、STD65、RFC3551、2003年7月。
[21] Casner, S., "Session Description Protocol (SDP) Bandwidth
Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556,
July 2003.
[21]Casner、S.、「RTP制御プロトコル(RTCP)帯域幅へのセッション記述プロトコル(SDP)帯域幅修飾語」、RFC3556、2003年7月。
[22] Huitema, C., "Real Time Control Protocol (RTCP) attribute in
Session Description Protocol (SDP)", RFC 3605, October 2003.
[22]Huitema、C.、「(RTCP)がSession記述プロトコル(SDP)で結果と考える本当のTime Controlプロトコル」、RFC3605、2003年10月。
[23] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
2004年の[23]Baugher、M.、マグリュー、D.、ジーター、M.、カラーラ、E.、およびK.Norrman、「安全なリアルタイムのトランスポート・プロトコル(SRTP)」、RFC3711行進。
Handley, et al. Standards Track [Page 46] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[46ページ]。
[24] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating
User Agent Capabilities in the Session Initiation Protocol
(SIP)", RFC 3840, August 2004.
[24] ローゼンバーグ、J.、Schulzrinne、H.、およびP.Kyzivat、「ユーザを示して、セッション開始におけるエージェント能力は(一口)について議定書の中で述べます」、RFC3840、2004年8月。
[25] Westerlund, M., "A Transport Independent Bandwidth Modifier for
the Session Description Protocol (SDP)", RFC 3890, September
2004.
[25]Westerlund、M.、「セッション記述プロトコル(SDP)のための輸送の独立している帯域幅修飾語」、RFC3890、2004年9月。
[26] International Telecommunication Union, "H.323 extended for
loosely coupled conferences", ITU Recommendation H.332,
September 1998.
[26]国際電気通信連合、「緩く結合した会議のために広げられたH.323」、ITU Recommendation H.332、1998年9月。
[27] Arkko, J., Carrara, E., Lindholm, F., Naslund, M., and K.
Norrman, "Key Management Extensions for Session Description
Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC
4567, July 2006.
[27] Arkko、J.、カラーラ、E.、リンドホルム、F.、ジーター、M.、およびK.Norrman、「セッション記述のためのKey Management拡大は(SDP)とリアルタイムのストリーミングのプロトコル(RTSP)について議定書の中で述べます」、RFC4567、2006年7月。
[28] Andreasen, F., Baugher, M., and D. Wing, "Session Description
Protocol (SDP) Security Descriptions for Media Streams", RFC
4568, July 2006.
Andreasen、F.、Baugher、M.、およびD.が翼をつけさせる[28]、「メディアの流れのためのセッション記述プロトコル(SDP)セキュリティ記述」、RFC4568(2006年7月)。
[29] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[29] レズニック、P.、「インターネットメッセージ・フォーマット」、RFC2822、2001年4月。
[30] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
[30]HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC2373、1998年7月。
[31] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
解放された[31]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
Handley, et al. Standards Track [Page 47] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[47ページ]。
Authors' Addresses
作者のアドレス
Mark Handley University College London Department of Computer Science Gower Street London WC1E 6BT UK
マークハンドレーユニバーシティ・カレッジロンドンコンピュータサイエンス学部ガウアー・ストリートロンドンWC1E 6BTイギリス
EMail: M.Handley@cs.ucl.ac.uk
メール: M.Handley@cs.ucl.ac.uk
Van Jacobson Packet Design 2465 Latham Street Mountain View, CA 94040 USA
ヴァンジェーコブソン2465レイサム通りマウンテンビュー、パケットデザインカリフォルニア94040米国
EMail: van@packetdesign.com
メール: van@packetdesign.com
Colin Perkins University of Glasgow Department of Computing Science 17 Lilybank Gardens Glasgow G12 8QQ UK
グラスゴー電子計算学17LilybankガーデンズグラスゴーG12 8QQイギリスの部のコリンパーキンス大学
EMail: csp@csperkins.org
メール: csp@csperkins.org
Handley, et al. Standards Track [Page 48] RFC 4566 SDP July 2006
ハンドレー、他 規格はSDP2006年7月にRFC4566を追跡します[48ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Handley, et al. Standards Track [Page 49]
ハンドレー、他 標準化過程[49ページ]
一覧
スポンサーリンク
