[要約] RFC 4566は、SDP（Session Description Protocol）の仕様を定義しており、セッションの特性やメディアの情報を交換するためのプロトコルです。このRFCの目的は、異なるシステム間でのセッションの確立とメディアの共有を容易にすることです。
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
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（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.
このメモはセッション記述プロトコル（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
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
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.
マルチメディア電話会議、Voice-over-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は純粋にセッション記述用のフォーマットであり、トランスポートプロトコルを組み込んでおらず、セッションアナウンスメントプロトコル[14]、セッション開始プロトコル[15]、リアルタイムストリーミングプロトコルなど、必要に応じて異なるトランスポートプロトコルを使用することを目的としています。 [16]、MIME拡張を使用した電子メール、およびハイパーテキスト転送プロトコル。
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は、幅広いネットワーク環境およびアプリケーションで使用できるように、汎用を目的としています。ただし、セッションコンテンツまたはメディアエンコーディングのネゴシエーションをサポートすることは意図されていません。これは、セッションの説明の範囲外と見なされます。
This memo obsoletes RFC 2327 [6] and RFC 3266 [10]. Section 10 outlines the changes introduced in this memo.
このメモはRFC 2327 [6]とRFC 3266 [10]を廃止します。セクション10では、このメモで導入された変更の概要を説明します。
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.
セッション：マルチメディアセッションは、マルチメディアの送信者と受信者、および送信者から受信者に流れるデータストリームのセットです。マルチメディア会議は、マルチメディアセッションの例です。
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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [3]で説明されているように解釈されます。
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.
セッション開始プロトコル（SIP）[15]は、インターネットマルチメディア会議、インターネット電話呼び出し、マルチメディア配信などのセッションを作成、変更、終了するためのアプリケーション層制御プロトコルです。セッションの作成に使用されるSIPメッセージは、参加者が一連の互換性のあるメディアタイプについて合意できるようにするセッションの説明を伝えます。これらのセッションの説明は通常、SDPを使用してフォーマットされます。 SIPで使用すると、オファー/アンサーモデル[17]は、SDPを使用したネゴシエーションのための限定的なフレームワークを提供します。
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.
リアルタイムストリーミングプロトコル（RTSP）[16]は、リアルタイムプロパティを持つデータの配信を制御するためのアプリケーションレベルのプロトコルです。 RTSPは、オーディオやビデオなどのリアルタイムデータの制御されたオンデマンド配信を可能にする拡張可能なフレームワークを提供します。 RTSPクライアントとサーバーは、メディア配信用の適切なパラメーターセットをネゴシエートし、SDP構文を部分的に使用してこれらのパラメーターを記述します。
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.
セッションの説明を伝達する別の方法には、電子メールとWorld Wide Web（WWW）があります。電子メールとWWWの両方の配布では、メディアタイプ「application / 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サーバーへのアクセスまたは電子メールの受信が制限される場合があるため、セッションアナウンスの受信者が必ずセッションを受信できるというプロパティはありません。この範囲外でも可能です。
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.
マルチキャストマルチメディア会議およびその他のマルチキャストセッションのアドバタイズを支援し、関連するセッションセットアップ情報を参加予定者に伝達するために、分散セッションディレクトリを使用できます。このようなセッションディレクトリのインスタンスは、セッションの説明を含むパケットを定期的に既知のマルチキャストグループに送信します。これらのアドバタイズは他のセッションディレクトリによって受信されるため、潜在的なリモート参加者はセッションの説明を使用して、セッションへの参加に必要なツールを起動できます。
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 Protocol（SAP）[14]です。 SDPは、そのようなセッションアナウンスに推奨されるセッション記述形式を提供します。
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 セッションがアクティブな時間
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がマルチキャストセッションアナウンスプロトコルで使用されている場合に主に役立ちます。）
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).
このアドレスとポートのセマンティクスは、定義されたメディアとトランスポートプロトコルによって異なります。デフォルトでは、これはデータが送信されるリモートアドレスとリモートポートである必要があります。一部のメディアタイプはこの動作を再定義する場合がありますが、これは実装が複雑になるため推奨されません（ネットワークアドレス変換（NAT）またはファイアウォールのピンホールを開くためにアドレスを解析する必要があるミドルボックスを含む）。
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 バウンドごとに、「毎週水曜日の午前10時1時間」などの時間を繰り返します。
This timing information is globally consistent, irrespective of local time zone or daylight saving time (see Section 5.9).
このタイミング情報は、ローカルタイムゾーンや夏時間に関係なく、グローバルに一貫しています（セクション5.9を参照）。
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.
セッションアナウンスがプライベートの場合、そのプライベートアナウンスを使用して、各メディアにどの暗号化方式が使用されているかを知るのに十分な情報を含め、会議の各メディアをデコードするために必要な暗号化キーを伝えることができます。
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）の形式で追加のポインターを含めることができます。
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 = cat：」属性。セクション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仕様では、UTF-8エンコーディング[5]でISO 10646文字セットを使用して、さまざまな言語を表現できるようにすることを推奨しています。ただし、コンパクトな表現を支援するために、SDPでは必要に応じてISO 8859-1などの他の文字セットを使用することもできます。国際化はフリーテキストフィールド（セッション名と背景情報）にのみ適用され、SDP全体には適用されません。
An SDP session description is denoted by the media type "application/sdp" (See Section 8).
SDPセッションの説明は、メディアタイプ「application / 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 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.
SDPセッションの説明は、UTF-8エンコーディングのISO 10646文字セットを使用した完全なテキストです。 SDPフィールド名と属性名はUTF-8のUS-ASCIIサブセットのみを使用しますが、テキストフィールドと属性値は完全なISO 10646文字セットを使用する場合があります。完全な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.
ここで、<type>は正確に1つの大文字と小文字を区別する文字でなければならず、<value>はフォーマットが<type>に依存する構造化テキストです。一般に、<値>は、単一の空白文字で区切られたいくつかのフィールドまたは自由形式の文字列であり、特定のフィールドで特に定義されていない限り、大文字小文字が区別されます。 「=」記号の両側で空白を使用してはなりません。
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セッションの説明は、セッションレベルのセクションと、それに続く0個以上のメディアレベルのセクションで構成されます。セッションレベルの部分は「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 "*".
各説明の一部の行は必須であり、一部はオプションですが、すべてここに記載されている順序で正確に表示する必要があります（固定された順序はエラー検出を大幅に強化し、単純なパーサーを可能にします）。 OPTIONALアイテムには「*」が付いています。
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
Time description
t= (time the session is active)
r=* (zero or more repeat times)
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)
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パーサーは、理解できないタイプレターを含むセッション記述を完全に無視する必要があります。属性メカニズム（以下で説明する "a ="）は、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 ="、および "a ="行の外部コンテンツを参照するURIが含まれる場合があります。これらのURIは、場合によっては逆参照される可能性があり、セッションの説明を非自己完結型にします。
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 ="）と属性（ "a ="）の情報は、接続情報またはメディアの説明にある同じ名前の属性で上書きされない限り、そのセッションのすべてのメディアに適用されます。たとえば、以下の例では、各メディアは「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
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).
セッション名や情報などのテキストフィールドは、0x00（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 ="、および "a ="行にドメイン名を含めることができます。 SDPで使用されるすべてのドメイン名は、[1]、[2]に準拠する必要があります。国際化ドメイン名（IDN）は、[11]で定義されているASCII互換エンコーディング（ACE）フォームを使用して表現する必要があり、UTF-8または他のエンコーディングで直接表現してはなりません（この要件は、RFC 2327および他のSDP-との互換性のためです）国際化ドメイン名の開発に先行する関連標準）。
v=0
h = 0
The "v=" field gives the version of the Session Description Protocol. This memo defines version 0. There is no minor version number.
「v =」フィールドは、セッション記述プロトコルのバージョンを示します。このメモはバージョン0を定義します。マイナーバージョン番号はありません。
o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>
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.
<username>は、発信元ホストでのユーザーのログインです。発信元ホストがユーザーIDの概念をサポートしていない場合は "-"です。 <username>にスペースを含めることはできません。
<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-id>は、<username>、<sess-id>、<nettype>、<addrtype>、および<unicast-address>のタプルがセッションのグローバルに一意の識別子を形成するような数値文字列です。 <sess-id>の割り当て方法は作成ツール次第ですが、一意性を確保するためにネットワークタイムプロトコル（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-version>は、このセッションの説明のバージョン番号です。セッションデータに変更が加えられたときに<sess-version>が増加する限り、その使用法は作成ツール次第です。この場合も、NTP形式のタイムスタンプを使用することをお勧めします。
<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).
<unicast-address>は、セッションが作成されたマシンのアドレスです。 IP4のアドレスタイプの場合、これはマシンの完全修飾ドメイン名か、マシンのIPバージョン4アドレスのドット付き10進表記です。 IP6のアドレスタイプの場合、これはマシンの完全修飾ドメイン名、またはマシンのIPバージョン6アドレスの圧縮されたテキスト表現です。 IP4とIP6の両方で、完全修飾ドメイン名は、これが使用できない場合を除いて指定する必要がある形式である必要があります。この場合、グローバルに一意のアドレスで置き換えることができます（MAY）。ローカルIPアドレスは、SDPの説明が意味のあるスコープを離れる可能性があるコンテキストでは使用してはなりません（たとえば、ローカルアドレスは、スコープを離れる可能性のあるアプリケーションレベルの紹介に含めてはなりません）。
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アドレスを難読化することが望ましい場合があります。これが問題になる場合は、任意の<username>とプライベート<unicast-address>を選択して、フィールドのグローバルな一意性に影響を与えない方法で「o =」フィールドを設定できます。
s=<session name>
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 =」フィールドは、テキストのセッション名です。セッションの説明ごとに「s =」フィールドが1つだけ存在する必要があります。 「s =」フィールドは空にしてはならず、ISO 10646文字を含める必要があります（「a = charset」属性も参照してください）。セッションに意味のある名前がない場合、値「s =」を使用する必要があります（つまり、セッション名として単一のスペース）。
i=<session description>
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 =」フィールドは、セッションに関するテキスト情報を提供します。セッションの説明ごとに最大で1つのセッションレベルの「i =」フィールド、およびメディアごとに最大で1つの「i =」フィールドが存在する必要があります。 「a = charset」属性が存在する場合、「i =」フィールドで使用される文字セットを指定します。 「a = charset」属性が存在しない場合、「i =」フィールドには、UTF-8エンコーディングのISO 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 =」フィールドも、各メディア定義に使用できます（MAY）。メディア定義では、「i =」フィールドは主にメディアストリームのラベル付けを目的としています。そのため、単一のセッションに同じメディアタイプの複数の異なるメディアストリームがある場合に、これらが役立つ可能性が最も高くなります。例としては、スライド用とフィードバックと質問用の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 =」フィールドは、セッションまたはメディアストリームの目的について、人間が読み取れる自由形式の説明を提供することを目的としています。オートマトンによる解析には適していません。
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.
URIは、WWWクライアントによって使用されるUniform Resource Identifierです[7]。 URIは、セッションに関する追加情報へのポインタである必要があります。このフィールドはオプションですが、存在する場合は、最初のメディアフィールドの前に指定する必要があります。セッション記述ごとに許可されるURIフィールドは1つだけです。
e=<email-address>
p=<phone-number>
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.
メールアドレスまたは電話番号を含めることはオプションです。以前のバージョンの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.
電子メールアドレスまたは電話番号が存在する場合、最初のメディアフィールドの前に指定する必要があります。セッションの説明には、複数の電子メールまたは電話フィールドを指定できます。
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:
電話番号は、「+」を前に付けた国際公衆電話番号（ITU-T勧告E.164を参照）の形式で指定する必要があります（SHOULD）。必要に応じて、スペースとハイフンを使用して電話フィールドを分割し、読みやすくすることができます。例えば：
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=j.doe@example.com (Jane Doe)
e=j.doe@example.com（Jane Doe）
The alternative RFC 2822 [29] name quoting convention is also allowed for both email addresses and phone numbers. For example:
代替RFC 2822 [29]の名前の引用規則は、電子メールアドレスと電話番号の両方に対しても許可されます。例えば：
e=Jane Doe <j.doe@example.com>
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-10646文字セットにするか、適切なセッションレベルの「a = charset」属性が設定されている場合はISO-8859-1または他のエンコーディングにする必要があります（SHOULD）。
c=<nettype> <addrtype> <connection-address>
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 =」フィールドと追加の「c =」フィールドを含めることができます。その場合、メディアごとの値は、それぞれのメディアのセッションレベルの設定を上書きします。
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>"）はアドレスタイプです。これにより、IPベースではないセッションにSDPを使用できます。このメモは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番目のサブフィールド（ "<connection-address>"）は、接続アドレスです。 <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を指定する必要がありますが、マルチキャストトラフィックのスコープへの使用は非推奨です。
applications SHOULD use an administratively scoped address instead.
アプリケーションは、代わりに管理用スコープのアドレスを使用する必要があります。
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マルチキャストに存在してはなりません（MUST NOT）。会議の範囲を制限するために、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:
階層的または階層的なエンコーディングスキームは、単一のメディアソースからのエンコーディングが複数のレイヤに分割されるデータストリームです。レシーバーは、これらのレイヤーのサブセットにサブスクライブするだけで、目的の品質（および帯域幅）を選択できます。このような階層化されたエンコーディングは通常、マルチキャストプルーニングを可能にするために複数のマルチキャストグループで送信されます。この手法は、階層の特定のレベルのみを必要とするサイトからの不要なトラフィックを保持します。複数のマルチキャストグループを必要とするアプリケーションでは、接続アドレスに次の表記法を使用できます。
<base multicast address>[/<ttl>]/<number of addresses>
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
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はTTL 127で使用されることを示します。これは、メディアの説明に複数の「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
Similarly, an IPv6 example would be:
同様に、IPv6の例は次のようになります。
c=IN IP6 FF15::101/3
which is semantically equivalent to:
これは、意味的には次と同等です。
c=IN IP6 FF15::101
c=IN IP6 FF15::102
c=IN IP6 FF15::103
(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 =」行は、階層または階層化されたエンコーディングスキームの異なるレイヤーにマルチキャストアドレスを提供する場合にのみ、メディアごとに指定できます。セッションレベルの「c =」フィールドには指定しないでください。
The slash notation for multiple addresses described above MUST NOT be used for IP unicast addresses.
上記の複数のアドレスのスラッシュ表記は、IPユニキャストアドレスに使用してはなりません（MUST NOT）。
b=<bwtype>:<bandwidth>
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>は、<bandwidth>の図の意味を示す英数字修飾子です。この仕様では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.
CTセッションまたはセッション内のメディアの帯域幅がスコープの暗黙の帯域幅と異なる場合は、「b = CT：...」行をセッションに指定して、使用する帯域幅の上限を提案する必要があります（ 「会議合計」帯域幅）。これの主な目的は、2つ以上のセッションが同時に共存できるかどうかについておおよその考えを提供することです。 RTPでCT修飾子を使用する場合、複数の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.
CTは、すべてのサイトのすべてのメディアの合計帯域幅の数値を与えることに注意してください。 ASは、単一サイトの単一メディアの帯域幅を示しますが、多くのサイトが同時に送信する場合があります。
A prefix "X-" is defined for <bwtype> names. This is intended for experimental purposes only. For example:
<bwtype>名には、接頭辞「X-」が定義されています。これは実験目的のみを目的としています。例えば：
b=X-YZ:128
b = X-YZ：128
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-」接頭辞の使用は推奨されません。代わりに、新しい修飾子を標準ネームスペースのIANAに登録する必要があります（SHOULD）。 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).
<bandwidth>は、デフォルトでは1秒あたりのキロビット数として解釈されます。新しい<bwtype>修飾子の定義は、帯域幅が別の単位で解釈されることを指定できます（このメモで定義されている "CT"および "AS"修飾子はデフォルトの単位を使用します）。
t=<start-time> <stop-time>
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 =」行は、セッションがアクティブになる追加の期間を指定します。セッションが定期的にアクティブである場合、「t =」行に加えて「r =」行（下記を参照）を使用する必要があります。この場合、「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.
最初と2番目のサブフィールドは、セッションの開始時間と停止時間をそれぞれ示します。これらの値は、1900年以降のネットワークタイムプロトコル（NTP）時間値の秒単位の10進表記です[13]。これらの値を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.
<stop-time>がゼロに設定されている場合、セッションは制限されませんが、<start-time>の後までアクティブにはなりません。 <start-time>もゼロの場合、セッションは永続的と見なされます。
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.
ユーザーインターフェースは、セッションがいつ終了するかについての情報を提供しないため、無制限の永続的なセッションを作成しないことを強く推奨します。これにより、スケジューリングが困難になります。
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 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.
一般に、ユーザーにタイムアウトしていない無制限のセッションを表示する場合、無制限のセッションは、現在時刻またはセッションの開始時刻のいずれか遅い方から30分までしかアクティブにならないと想定されます。これ以外の動作が必要な場合は、セッションが実際に終了する必要がある時期に関する新しい情報が利用可能になったときに、終了時刻を指定し、必要に応じて変更する必要があります。
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.
永続的なセッションは、セッションがいつアクティブになるかを正確に示す関連付けられた繰り返し時間が存在しない限り、アクティブではないことがユーザーに示されることがあります。
r=<repeat interval> <active duration> <offsets from start-time>
"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 =」フィールドの<start-time>は最初の10amのNTP表現になります。月曜日、<繰り返し間隔>は1週間、<アクティブ期間>は1時間、オフセットは0と25時間です。対応する「t =」フィールドの停止時間は、3か月後の最後のセッションの終了のNTP表現になります。デフォルトでは、すべてのフィールドは秒単位であるため、 "r ="および "t ="フィールドは次のようになります。
t=3034423619 3042462419 r=604800 3600 0 90000
t = 3034423619 3042462419 r = 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
T = 7日1時間0 25時間
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 =」フィールドを使用する必要があります。
z=<adjustment time> <offset> <adjustment time> <offset> ....
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 -1h 2898848070 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つのセッションの発表で数年分の調整を送信するのではなく、定期的に変更されることが予想されます。
k=<method>
k=<method>:<encryption key>
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.
安全で信頼できるチャネルを介して転送される場合、セッション記述プロトコルを使用して暗号化キーを伝達できます。鍵交換の簡単なメカニズムは、キーフィールド（ "k ="）によって提供されますが、これは主に古い実装との互換性のためにサポートされており、その使用は推奨されません。 SDPで使用する新しい鍵交換メカニズムを定義する作業が進行中であり[27] [28]、新しいアプリケーションでそれらのメカニズムを使用することが期待されています。
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つのキーが必要です。1つは機密性用、もう1つは整合性用です。この仕様では、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>
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が安全なチャネルを介して伝達されることが保証されない限り、使用してはなりません（MUST NOT）。暗号化キーは、charset属性に従ってテキストとして解釈されます。 「k = base64：」メソッドを使用して、SDPで禁止されている文字を伝えます。
k=base64:<encoded encryption key>
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.
暗号化キーはこのキーフィールドに含まれていますが、SDPで禁止されている文字が含まれているため、base64でエンコードされています[12]。このメソッドは、SDPが安全なチャネルを介して伝達されることが保証されない限り、使用してはなりません（MUST NOT）。
k=uri:<URI to obtain key>
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 / Transport 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 decrypt the media streams. The use of user-specified keys is NOT RECOMMENDED, since such keys tend to have weak security properties.
このSDPの説明にはキーは含まれていませんが、このキーフィールドによって参照されるセッションまたはメディアストリームは暗号化されています。ユーザーは、セッションに参加しようとするときにキーの入力を求められる必要があり、このユーザー指定のキーを使用してメディアストリームを復号化する必要があります。ユーザー指定のキーは弱いセキュリティプロパティを持つ傾向があるため、ユーザー指定のキーの使用は推奨されません。
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が安全で信頼できるチャネルを介して伝達されることが保証されない限り、キーフィールドを使用してはなりません（MUST NOT）。このようなチャネルの例としては、S / MIMEメッセージまたはTLSで保護されたHTTPセッション内に埋め込まれたSDPがあります。安全なチャネルが、仲介者ではなく、セッションへの参加を許可された当事者と一緒にあることを確認することが重要です。キャッシングプロキシサーバーが使用されている場合、プロキシが信頼できるか、SDPにアクセスできないことを確認することが重要です。
a=<attribute>
a=<attribute>:<value>
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 = <フラグ>」の形式です。これらはバイナリ属性であり、属性の存在はその属性がセッションのプロパティであることを伝えます。たとえば、「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 値属性の形式は、「a = <属性>：<値>」です。たとえば、ホワイトボードの値属性は「a = orient：landscape」です。
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のUS-ASCIIサブセットを使用する必要があります。
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.
属性値はオクテット文字列であり、0x00（Nul）、0x0A（LF）、および0x0D（CR）を除くすべてのオクテット値を使用できます（MAY）。デフォルトでは、属性値は、UTF-8エンコーディングのISO-10646文字セットのように解釈されます。他のテキストフィールドとは異なり、属性値は通常、「charset」属性の影響を受けません。これは、既知の値との比較が問題になるためです。ただし、属性が定義されている場合は、文字セットに依存するように定義できます。その場合、その値は、ISO-10646ではなくセッションの文字セットで解釈する必要があります。
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を参照）。理解できない属性が受信された場合、それは受信者によって無視されなければなりません（MUST）。
m=<media> <port> <proto> <fmt> ...
m = <メディア> <ポート> <プロトコル> <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).
<media>はメディアタイプです。現在定義されているメディアは「オーディオ」、「ビデオ」、「テキスト」、「アプリケーション」、「メッセージ」ですが、このリストは将来拡張される可能性があります（セクション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]).
<port>は、メディアストリームの送信先のトランスポートポートです。トランスポートポートの意味は、関連する「c =」フィールドで指定されているように使用されているネットワークと、メディアフィールドの<proto>サブフィールドで定義されているトランスポートプロトコルによって異なります。メディアアプリケーションで使用されるその他のポート（RTP制御プロトコル（RTCP）ポート[19]など）は、ベースメディアポートからアルゴリズムによって派生させるか、別の属性（たとえば、 "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を送信する必要があります。 > RTCPを「a = 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マルチキャストアドレスに使用される表記と同様の表記を使用して行われます。
m=<media> <port>/<number of ports> <proto> <fmt> ...
m = <メディア> <ポート> / <ポート数> <プロトコル> <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つ高い奇数ポートがRTPセッションに属するRTCPに使用され、<ポート数>はRTPセッションの数を示します。例えば：
m=video 49170/2 RTP/AVP 31
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が1つのRTP / RTCPペアを形成し、49172と49173が2番目のRTP / RTCPペアを形成することを指定します。 RTP / AVPはトランスポートプロトコルで、31がフォーマットです（以下を参照）。隣接しないポートが必要な場合は、別の属性を使用して信号を送る必要があります（たとえば、[22]で定義されている "a = rtcp："）。
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
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：UDPで実行される最小制御[20]のオーディオおよびビデオ会議のRTPプロファイルで使用されるRTP [19]を示します。
* RTP/SAVP: denotes the Secure Real-time Transport Protocol [23] running over UDP.
* RTP / SAVP：UDPで実行されているセキュアなリアルタイム転送プロトコル[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オーディオ。もう1つは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ペイロードタイプ番号が含まれます。ペイロードタイプ番号のリストが指定されている場合、これはこれらのすべてのペイロード形式がセッションで使用される可能性があることを意味しますが、これらの形式の最初のものはセッションのデフォルト形式として使用する必要があります。動的なペイロードタイプの割り当ての場合、「a = rtpmap：」属性（セクション6を参照）を使用して、RTPペイロードタイプ番号からペイロード形式を識別するメディアエンコーディング名にマップする必要があります（SHOULD）。 "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>サブフィールドは、「オーディオ」、「ビデオ」、「テキスト」、「アプリケーション」、または「メッセージ」の下のフォーマットを説明するメディアタイプを参照する必要があります。レベルのメディアタイプ。メディアタイプ登録は、UDPトランスポートで使用するパケット形式を定義する必要があります（SHOULD）。
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を参照）。
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.
この属性は、ドットで区切られたセッションの階層カテゴリを示します。これは、受信者が不要なセッションをカテゴリ別にフィルタリングできるようにするためです。カテゴリの中央レジストリはありません。これはセッションレベルの属性であり、文字セットには依存しません。
a=keywds:<keywords>
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.
cat属性と同様に、これはレシーバーで必要なセッションを識別するのに役立ちます。これにより、受信者はセッションの目的を説明するキーワードに基づいて興味深いセッションを選択できます。キーワードの中央レジストリはありません。これはセッションレベルの属性です。これは文字セット依存の属性です。つまり、その値は、セッション記述に指定されている場合は指定された文字セットで、またはデフォルトでISO 10646 / UTF-8で解釈される必要があります。
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.
これは、セッションの説明を作成するために使用されるツールの名前とバージョン番号を示します。これはセッションレベルの属性であり、文字セットには依存しません。
a=ptime:<packet time>
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.
これは、パケット内のメディアによって表される時間をミリ秒単位で示します。これはおそらくオーディオデータでのみ意味がありますが、意味がある場合は他のメディアタイプでも使用できます。 RTPまたはVATオーディオをデコードするためにptimeを知っている必要はありません。オーディオのエンコード/パケット化の推奨事項として意図されています。これはメディアレベルの属性であり、文字セットに依存していません。
a=maxptime:<maximum packet time>
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.
これにより、各パケットにカプセル化できるメディアの最大量がミリ秒単位の時間で表されます。時間は、パケットに存在するメディアが表す時間の合計として計算される必要があります。フレームベースのコーデックの場合、時間はフレームサイズの整数倍にする必要があります（SHOULD）。この属性はおそらくオーディオデータに対してのみ意味がありますが、意味がある場合は他のメディアタイプで使用できます。これはメディアレベルの属性であり、文字セットに依存していません。この属性はRFC 2327の後に導入されたものであり、更新されていない実装はこの属性を無視することに注意してください。
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
parameters>]
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.
この属性は、RTPペイロードタイプ番号（「m =」行で使用される）から、使用されるペイロード形式を示すエンコーディング名にマップします。また、クロックレートとエンコーディングパラメータに関する情報も提供します。これは、文字セットに依存しないメディアレベルの属性です。
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：」属性を使用して動的に行われるのが一般的です。静的ペイロードタイプの例として、8 kHzでサンプリングされたu-law PCM符号化単一チャネルオーディオを考えます。これはRTPオーディオ/ビデオプロファイルでペイロードタイプ0として完全に定義されているため、「a = rtpmap：」属性は不要であり、UDPポート49232に送信されるそのようなストリームのメディアは次のように指定できます。
m=audio 49232 RTP/AVP 0
m =オーディオ49232 RTP / AVP 0
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:
動的ペイロードタイプの例は、16 kHzでサンプリングされた16ビットの線形エンコードされたステレオオーディオです。このストリームに動的RTP / AVPペイロードタイプ98を使用したい場合は、デコードするために追加情報が必要です。
m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/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
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".
動的ペイロードタイプの使用を指定するRTPプロファイルは、有効なエンコーディング名のセットおよび/またはそのプロファイルをSDPで使用する場合はエンコーディング名を登録する手段を定義する必要があります。 「RTP / AVP」および「RTP / SAVP」プロファイルは、「m =」行で示される最上位のメディアタイプの下で、エンコーディング名にメディアサブタイプを使用します。上記の例では、メディアタイプは「audio / l8」と「audio / 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.
オーディオストリームの場合、<encoding parameters>はオーディオチャネルの数を示します。このパラメーターはオプションであり、追加のパラメーターが必要ない場合は、チャネル数が1の場合は省略できます。
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 to participate in a session. Codec-specific parameters should be added in other attributes (for example, "a=fmtp:").
追加のエンコーディングパラメータは将来的に定義される可能性がありますが、コーデック固有のパラメータは追加されるべきではありません。 「a = rtpmap：」属性に追加されたパラメーターは、セッションに参加する適切なメディアを選択するためにセッションディレクトリに必要なパラメーターのみである必要があります（SHOULD）。コーデック固有のパラメータを他の属性に追加する必要があります（たとえば、「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オーディオ形式には、通常、パケットあたりのサンプル数に関する情報は含まれていません。デフォルト以外の（RTPオーディオ/ビデオプロファイルで定義されている）パケット化が必要な場合は、上記の「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).
これは、該当する場合、ツールを受信専用モードで開始する必要があることを指定します。セッションレベルまたはメディアレベルの属性のいずれかであり、文字セットには依存しません。 recvonlyはメディアにのみ適用され、関連する制御プロトコルには適用されないことに注意してください（たとえば、recvonlyモードの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.
これは、ツールを送受信モードで開始する必要があることを指定します。これは、デフォルトで受信専用モードになっているツールを使用したインタラクティブな会議に必要です。セッションまたはメディアレベルの属性のいずれかであり、文字セットに依存していません。
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」、「inactive」、「sendrecv」のいずれの属性も存在しない場合、「sendrecv」は、会議タイプが「broadcast」または「H332」ではないセッションのデフォルトとして想定される必要があります（SHOULD）。下記参照）。
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.
これは、ツールを送信専用モードで開始する必要があることを指定します。例としては、トラフィックの宛先とトラフィックの送信元に異なるユニキャストアドレスを使用する場合があります。そのような場合、1つのsendonlyと1つのrecvonlyの2つのメディア記述を使用できます。セッションレベルまたはメディアレベルの属性のいずれかですが、通常はメディア属性としてのみ使用されます。文字セットには依存しません。 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 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ベースのシステムは、非アクティブに開始された場合でも、RTCPを送信する必要があることに注意してください。セッションまたはメディアレベルの属性のいずれかであり、文字セットに依存していません。
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.
通常、これはホワイトボードまたはプレゼンテーションツールにのみ使用されます。画面上のワークスペースの向きを指定します。メディアレベルの属性です。許可される値は、「portrait」、「landscape」、および「seascape」（上下逆の風景）です。文字セットには依存しません。
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」です。 「recvonly」は「type：broadcast」セッションのデフォルトである必要があり、「type：meeting」は「sendrecv」を意味する必要があり、「type：moderated」はフロア制御ツールの使用を示し、メディアツールが会議に参加する新しいサイトをミュートします。
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".
属性「type：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.
ヒントとして「type：test」属性を指定することをお勧めします。明示的に要求されない限り、受信者はこのセッションの説明をユーザーに表示しないようにすることができます。
The type attribute is a session-level attribute, and it is not dependent on charset.
type属性はセッションレベルの属性であり、charsetに依存していません。
a=charset:<character set>
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文字セットが使用されます。よりコンパクトな表現が必要な場合は、他の文字セットを使用できます。たとえば、ISO 8859-1は次のSDP属性で指定されます。
a=charset:ISO-8859-1
a = charset：ISO-8859-1
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.
これはセッションレベルの属性であり、文字セットには依存しません。指定する文字セットは、ISO-8859-1など、IANAに登録されている文字セットの1つでなければなりません。文字セット識別子はUS-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>
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.
一般に、複数の言語で構成されるセッションの説明を送信することはお勧めしません。代わりに、セッションを説明する複数の説明を各言語で1つ送信する必要があります。ただし、これはすべてのトランスポートメカニズムで可能ではないため、推奨されていませんが、複数のsdplang属性を使用できます。
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」属性値は、US-ASCIIの単一のRFC 3066言語タグである必要があります[9]。 charset属性には依存しません。 「sdplang」属性は、セッションが、受信者の言語を想定できない地理的な境界を越えるのに十分な範囲である場合、またはセッションがローカルで想定された基準と異なる言語である場合に指定する必要があります。
a=lang:<language tag>
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, 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」属性値は、US-ASCIIの単一のRFC 3066言語タグである必要があります[9]。 charset属性には依存しません。 「lang」属性は、セッションが、受信者の言語を想定できない地理的な境界を越えるのに十分な範囲である場合、またはセッションがローカルで想定された標準とは異なる言語である場合に指定する必要があります。
a=framerate:<frame rate>
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.
これにより、フレーム/秒で最大ビデオフレームレートが得られます。これは、ビデオデータのエンコードに関する推奨事項です。表記 "<integer>。<fraction>"を使用した小数値の10進表記が許可されます。これは、メディアレベルの属性であり、ビデオメディアに対してのみ定義され、文字セットには依存しません。
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:
これは、整数値としてのエンコーディングの品質を示唆しています。ビデオのquality属性の目的は、フレームレートと静止画の品質の間のデフォルト以外のトレードオフを指定することです。ビデオの場合、値は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.
これはメディアレベルの属性であり、文字セットに依存していません。
a=fmtp:<format> <format specific parameters>
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 unchanged to the media tool that will use this format. At most one instance of this attribute is allowed for each format.
この属性により、特定のフォーマットに固有のパラメーターを、SDPが理解する必要がない方法で伝達できます。フォーマットは、メディアに指定されたフォーマットの1つでなければなりません。フォーマット固有のパラメーターは、SDPによって伝達され、このフォーマットを使用するメディアツールに変更されずに与えられる必要があるパラメーターのセットです。フォーマットごとに、この属性のインスタンスを1つだけ使用できます。
It is a media-level attribute, and it is not dependent on charset.
これはメディアレベルの属性であり、文字セットに依存していません。
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は、セッション開始プロトコル[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は、マルチメディアセッションを記述するセッション記述形式です。 SDPメッセージを受信して処理するエンティティは、セッション記述が既知の信頼できるソースから認証されたトランスポートプロトコルによって取得されない限り、信頼できないことに注意してください。多くの異なるトランスポートプロトコルがセッションの説明を配布するために使用される場合があり、認証の性質はトランスポートごとに異なります。一部のトランスポートでは、セキュリティ機能が配備されていないことがよくあります。信頼できる方法でセッションの説明が取得されなかった場合、エンドポイントは注意を払う必要があります。これは、他の攻撃の中でも、受信したメディアセッションが意図したものではない場合や、メディアの送信先が予期したものではない場合があるためです。セッションのパラメータが正しくないか、メディアのセキュリティが侵害されている可能性があります。アプリケーションのセキュリティリスクとユーザー設定を考慮して賢明な決定を下すのはエンドポイント次第であり、セッションを受け入れるかどうかをユーザーに尋ねることもできます。
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 Protocol（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 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.
この仕様では、セッションの説明の受信者に通知して、デフォルトで送信するモードでマルチメディアツールを起動できるようにする属性はありません。状況によっては、そのような属性を定義することが適切な場合があります。これが行われた場合、そのような属性を含むセッション記述を解析するアプリケーションは、それらを無視するか、このセッションに参加するとマルチメディアデータが自動的に送信されることをユーザーに通知する必要があります。不明な属性のデフォルトの動作は、それを無視することです。
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バインディングと一致させるために、セッション記述を変更することがあります。これらの動作は、中間システムが適切なチェックを実行してセッション記述の信頼性を確立し、そのソースの権限がそのような通信セッションを確立できるような方法でセッション記述が伝達されない限り、推奨されません。 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は、SDPが配信されるチャネルがプライベートであり、認証されていることを保証できない場合を除いて、キーマテリアルの伝達に使用してはなりません（MUST NOT）。さらに、「k =」行は、暗号鍵アルゴリズムを示したり交渉したりする方法を提供していません。機密性と整合性のために個別のキーではなく、単一の対称キーのみを提供するため、そのユーティリティは厳しく制限されています。セクション5.12で説明されているように、「k =」行の使用は推奨されません。
One media type registration from RFC 2327 is to be updated, as defined below.
以下に定義するように、RFC 2327からの1つのメディアタイプ登録が更新されます。
To: ietf-types@iana.org
Subject: Registration of media type "application/sdp"
Type name: application
タイプ名：アプリケーション
Subtype name: sdp
サブタイプ名：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ファイルの特定の部分に他の文字セットが存在することを示すために使用できます（RFC 4566のセクション6を参照）。任意のバイナリコンテンツをSDPで直接表すことはできません。
Security considerations: See Section 7 of RFC 4566
セキュリティに関する考慮事項：RFC 4566のセクション7をご覧ください
Interoperability considerations: See RFC 4566
相互運用性に関する考慮事項：RFC 4566を参照してください
Published specification: See RFC 4566
公開された仕様：RFC 4566を参照
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、ビデオ電話会議、ストリーミングメディア、インスタントメッセージングなど。 RFC 4566のセクション3もご覧ください。
Additional information:
追加情報：
Magic number(s): None.
File extension(s): The extension ".sdp" is commonly used.
Macintosh File Type Code(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>
Intended usage: COMMON
使用目的：COMMON
Author/Change controller: Authors of RFC 4566 IETF MMUSIC working group delegated from the IESG
著者/変更管理者：IESGから委任されたRFC 4566 IETF MMUSICワーキンググループの著者
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仕様のBackus-Naur Form（BNF）の用語を使用すると、「media」、「proto」、「fmt」、「att-field」、「bwtype」、「nettype」、および「addrtype」になります。
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].
メディアタイプのセットは小さいことを目的としており、まれな状況を除いて拡張するべきではありません。メディア名にもトップレベルのメディアコンテンツタイプと同じルールを適用する必要があります。可能な場合は、SMEにもMIMEと同じ名前を登録する必要があります。既存のトップレベルメディアコンテンツタイプ以外のメディアの場合、新しいトップレベルコンテンツタイプを登録するために、Standards Track RFCを作成する必要があり、登録は、既存のメディア名が適切でない理由を適切に提供する必要があります（「Standards Action "RFC 2434のポリシー[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]。ただし、それらのセマンティクスは完全には指定されておらず、広く使用されていません。これらのメディアタイプはこの仕様では削除されましたが、RFC 3840 [24]で定義されているSIPユーザーエージェントの有効なメディアタイプ機能は引き続き残っています。これらのメディアタイプが将来的に有用であると考えられる場合、それらの使用を文書化するために、Standards Track RFCを作成する必要があります。それが完了するまで、アプリケーションはこれらのタイプを使用してはならず（SHOULD NOT）、SIP機能宣言でそれらのサポートを宣言しないでください（RFC 3840によって作成されたレジストリに存在する場合でも）。
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」フィールドは、使用されるトランスポートプロトコルを示します。これは、標準化過程のプロトコルRFCを参照する必要があります。このメモは、3つの値を登録します。「RTP / AVP」は、最小制御のオーディオおよびビデオ会議のRTPプロファイル[20]で使用されるRTP [19]への参照です。
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」は、Secure Real-time Transport Protocol [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プロファイルが将来定義される場合、それらの「プロト」名は同じ方法で指定されるべきです（SHOULD）。たとえば、短縮名が「XYZ」であるRTPプロファイルは、「RTP / XYZ」の「proto」フィールドで示されます。
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に登録する必要があります。登録では、プロトコルを説明するRFCを参照する必要があります。そのようなRFCは実験的または情報的であるかもしれませんが、それは標準トラックであることが望ましいです。登録では、「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」名前空間が関連付けられています。フォーマットは、マルチメディアセッションで転送される可能性のあるすべての可能なエンコーディングをカバーしています。
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」名前空間に対して同じルールを指定することをお勧めします。
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）。フォーマットに既存のメディアサブタイプを使用することをお勧めします。メディアサブタイプが存在しない場合は、フォーマットのトランスポートプロトコルを定義する標準トラックRFCを作成または参照することにより、IETFプロセス[31]を通じて適切なものを登録することをお勧めします。
For other protocols, formats MAY be registered according to the rules of the associated "proto" specification.
他のプロトコルについては、フォーマットは関連する「プロトコル」仕様のルールに従って登録されてもよい（MAY）。
Registrations of new formats MUST specify which transport protocols they apply to.
新しいフォーマットの登録では、適用するトランスポートプロトコルを指定する必要があります。
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-field"）は、IANAに登録して文書化する必要があります。これは、同じ名前の属性の競合による顕著な問題があるためです。 SDPの不明な属性は単に無視されますが、プロトコルを断片化する競合する属性は深刻な問題です。
New attribute registrations are accepted according to the "Specification Required" policy of RFC 2434, provided that the specification includes the following information:
仕様に以下の情報が含まれている場合、RFC 2434の「Specification Required」ポリシーに従って、新しい属性の登録が受け入れられます。
o contact name, email address, and telephone number
o 連絡先名、メールアドレス、電話番号
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 属性値が文字セット属性に従うかどうか
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が受け入れる最小値です。広範な使用と相互運用性が期待される属性は、属性をより正確に指定する標準化過程のRFCで文書化する必要があります（SHOULD）。
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.
登録の提出者は、仕様が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-field"値）を登録しました（これらの定義はRFC 2327の定義を更新します）。
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
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は、帯域幅指定子「CT」と「AS」を、このメモのセクション5.8の定義と一緒に登録しました（これらの定義は、RFC 2327の定義を更新します）。
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 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.
非インターネット環境のコンテキストでSDPを使用する必要がある場合は、新しいネットワークタイプ（「nettype」フィールド）をIANAに登録できます。これらは通常IANAの保護ではありませんが、インターネット電話の呼び出しを公衆交換電話網（PSTN）にゲートウェイする場合など、インターネットアプリケーションが非インターネットアプリケーションと相互運用する必要がある場合があります。ネットワークタイプの数は少なく、拡張する必要はほとんどありません。そのネットワークタイプで使用するアドレスタイプを少なくとも1つ登録しないと、新しいネットワークタイプを登録できません。新しいネットワークタイプ登録は、ネットワークタイプとアドレスタイプの詳細を提供し、それらがいつどのように使用されるかを指定する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は、インターネットを表すためにネットワークタイプ「IN」を登録しました。このメモのセクション5.2と5.7に定義されています（これらの定義はRFC 2327の定義を更新します）。
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に定義されているように登録しました（これらの定義はRFC 2327の定義を更新します）。
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の「メディア」、「プロト」、「fmt」、「bwtype」、「nettype」、および「addrtype」フィールドを登録するRFCドキュメントでは、IANAが適切なレジストリに配置できるように、次の情報を作成者が含める必要があります。
o contact name, email address, and telephone number
o 連絡先名、メールアドレス、電話番号
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 名前のタイプ（「media」、「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に照会して確認し、登録を行う前に改訂を要求することができます。
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 ="行は拡張できないため、このテーブルは廃止されました。新規登録は受け付けてはなりません。
This section provides an Augmented BNF grammar for SDP. ABNF is defined in [4].
このセクションでは、SDPの拡張BNF文法について説明します。 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構文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
proto-version = %x76 "=" 1*DIGIT CRLF
;this memo describes version 0
origin-field = %x6f "=" username SP sess-id SP sess-version SP
nettype SP addrtype SP unicast-address CRLF
session-name-field = %x73 "=" text CRLF
information-field = [%x69 "=" text CRLF]
uri-field = [%x75 "=" uri CRLF]
email-fields = *(%x65 "=" email-address CRLF)
phone-fields = *(%x70 "=" phone-number 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
bandwidth-fields = *(%x62 "=" bwtype ":" bandwidth CRLF)
time-fields = 1*( %x74 "=" start-time SP stop-time
*(CRLF repeat-fields) CRLF)
[zone-adjustments CRLF]
repeat-fields = %x72 "=" repeat-interval SP typed-time
1*(SP typed-time)
zone-adjustments = %x7a "=" time SP ["-"] typed-time
*(SP time SP ["-"] typed-time)
key-field = [%x6b "=" key-type CRLF]
attribute-fields = *(%x61 "=" attribute 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
; sub-rules of 'o='
username = non-ws-string
;pretty wide definition, but doesn't
;include space
sess-id = 1*DIGIT
;should be unique for this username/host
sess-version = 1*DIGIT
nettype = token ;typically "IN"
nettype = token;通常は「IN」
addrtype = token ;typically "IP4" or "IP6"
addrtype = token;通常は「IP4」または「IP6」
; sub-rules of 'u=' uri = URI-reference ; see RFC 3986
; 'u ='のサブルールuri = URI-reference; RFC 3986を参照
; 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 ">"
; sub-rules of 'p='
phone-number = phone *SP "(" 1*email-safe ")" /
1*email-safe "<" phone ">" /
phone
phone = ["+"] DIGIT 1*(SP / "-" / DIGIT)
; sub-rules of 'c='
connection-address = multicast-address / unicast-address
; sub-rules of 'b=' bwtype = token
; 「b =」のサブルールbwtype = token
bandwidth = 1*DIGIT
; sub-rules of 't='
start-time = time / "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.
; sub-rules of 'r=' and 'z='
repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit]
typed-time = 1*DIGIT [fixed-len-time-unit]
fixed-len-time-unit = %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:"
base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = 2base64-char "==" / 3base64-char "="
base64-char = ALPHA / DIGIT / "+" / "/"
; sub-rules of 'a='
attribute = (att-field ":" att-value) / att-field
att-field = token
att-value = byte-string
; 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"
port = 1*DIGIT
; generic sub-rules: addressing
unicast-address = IP4-address / IP6-address / FQDN / extn-addr
multicast-address = IP4-multicast / IP6-multicast / 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
m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
("23" DIGIT )
IP6-multicast = hexpart [ "/" integer ] ; IPv6 address starting with FF
IP6-multicast = hexpart ["/" integer]; FFで始まるIPv6アドレス
ttl = (POS-DIGIT *2DIGIT) / "0"
FQDN = 4*(alpha-numeric / "-" / ".")
; fully qualified domain name as specified
; in RFC 1035 (and updates)
IP4-address = b1 3("." decimal-uchar)
IP4-address = b1 3（ "。" Decimal-flying）
b1 = decimal-uchar ; less than "224"
b1 = decimal-uchar; 「224」未満
; The following is consistent with RFC 2373 [30], Appendix B. IP6-address = hexpart [ ":" IP4-address ]
;以下は、RFC 2373 [30]、付録Bに準拠しています。IP6-address = hexpart ["：" IP4-address]
hexpart = hexseq / hexseq "::" [ hexseq ] /
"::" [ hexseq ]
hexseq = hex4 *( ":" hex4)
hex4 = 1*4HEXDIG
; Generic for other address families extn-addr = non-ws-string
;他のアドレスファミリのジェネリックextn-addr = non-ws-string
; 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
byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
;any byte except NUL, CR, or LF
non-ws-string = 1*(VCHAR/%x80-FF)
;string of visible characters
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7E
token = 1*(token-char)
email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
;any byte except NUL, CR, LF, or the quoting
;characters ()<>
integer = POS-DIGIT *DIGIT
整数= POS-DIGIT * DIGIT
; generic sub-rules: primitives
alpha-numeric = ALPHA / DIGIT
POS-DIGIT = %x31-39 ; 1 - 9
decimal-uchar = DIGIT
/ POS-DIGIT DIGIT
/ ("1" 2*(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("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
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.
メモは大幅に再構成され、使用に照らして仕様に多数の明確化が組み込まれています。以下に記されている項目を除いて、メモへの変更は後方互換性の明確化を目的としています。ただし、RFC 2327の不整合と不明確な定義のため、一部の実装では、このバージョンの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文法は大幅に改訂および更新され、多くの誤りが修正され、RFC 3266 IPv6拡張が組み込まれています。文法と仕様テキストの間の既知の不整合が解決されました。
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.
RFC 2119用語は、要件レベルを指定するために全体で使用されるようになりました。特にパラメーター登録に関連するこれらの要件の一部は、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 = inactive」および「a = maxptime」が追加されました。
RFC 2327 mandated that either "e=" or "p=" was required. Both are now optional, to reflect actual usage.
RFC 2327は、「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-」プレフィックス表記のほとんどの使用は許可されておらず、その他の使用は非推奨です。
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マルチパーティマルチメディアセッションコントロール（MMUSIC）ワーキンググループの多くの人々が、このドキュメントにコメントや提案を投稿しています。特に、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、ジョンエルウェル、フレミングアンドレアセン、ジョンピーターソン、スペンサードーキンス。
[1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[1] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、1987年11月。
[2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[2] Mockapetris、P。、「ドメイン名-実装と仕様」、STD 13、RFC 1035、1987年11月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、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」、RFC 4234、2005年10月。
[5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[5] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[6] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[6] Handley、M。およびV. Jacobson、「SDP：Session Description Protocol」、RFC 2327、1998年4月。
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[7] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、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、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[9] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[9] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[10] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6 in Session Description Protocol (SDP)", RFC 3266, June 2002.
[10] Olson、S.、Camarillo、G.、and A. Roach、 "Support for IPv6 in Session Description Protocol（SDP）"、RFC 3266、June 2002。
[11] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[11] Faltstrom、P.、Hoffman、P。、およびA. Costello、「Internationalizing Domain Names in Applications（IDNA）」、RFC 3490、2003年3月。
[12] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.
[12] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 3548、2003年7月。
[13] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992.
[13] Mills、D。、「Network Time Protocol（Version 3）Specification、Implementation」、RFC 1305、1992年3月。
[14] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[14] Handley、M.、Perkins、C。、およびE. Whelan、「Session Announcement Protocol」、RFC 2974、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」、RFC 3261 、2002年6月。
[16] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[16] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「Real Time Streaming Protocol（RTSP）」、RFC 2326、1998年4月。
[17] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[17] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、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] Camarillo、G.、Eriksson、G.、Holler、J。、およびH. Schulzrinne、「Grouping of Media Lines in the Session Description Protocol（SDP）」、RFC 3388、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.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、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プロファイル」、STD 65、RFC 3551、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）帯域幅修飾子」、RFC 3556、2003年7月。
[22] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, October 2003.
[22] Huitema、C。、「セッション記述プロトコル（SDP）のリアルタイム制御プロトコル（RTCP）属性」、RFC 3605、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.
[23] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E。、およびK. Norrman、「Secure Real-time Transport Protocol（SRTP）」、RFC 3711、2004年3月。
[24] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[24] Rosenberg、J.、Schulzrinne、H。、およびP. Kyzivat、「Initiating User Agent Capabilities in the Session Initiation Protocol（SIP）」、RFC 3840、2004年8月。
[25] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, September 2004.
[25] Westerlund、M。、「Session Description Protocol（SDP）のトランスポートに依存しない帯域幅修飾子」、RFC 3890、2004年9月。
[26] International Telecommunication Union, "H.323 extended for loosely coupled conferences", ITU Recommendation H.332, September 1998.
[26] 国際電気通信連合、「疎結合の会議用に拡張されたH.323」、ITU勧告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.、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年
[28] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, July 2006.
[28] Andreasen、F.、Baugher、M。、およびD. Wing、「Session Description Protocol（SDP）Security Descriptions for Media Streams」、RFC 4568、2006年7月。
[29] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[29] Resnick、P。、「Internet Message Format」、RFC 2822、2001年4月。
[30] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[30] Hinden、R. and S. Deering、「IP Version 6 Addressing Architecture」、RFC 2373、1998年7月。
[31] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[31] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
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
Van Jacobson Packet Design 2465 Latham Street Mountain View, CA 94040 USA
Van Jacobson Packet Design 2465 Latham Street Mountain View、CA 94040 USA
EMail: van@packetdesign.com
Colin Perkins University of Glasgow Department of Computing Science 17 Lilybank Gardens Glasgow G12 8QQ UK
コリンパーキンスグラスゴー大学計算科学科17 Lilybank GardensグラスゴーG12 8QQイギリス
EMail: csp@csperkins.org
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（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.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
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は、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
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.
IETF事務局に対して行われたIPR開示のコピー、および使用可能にされるライセンスの保証、または一般ライセンスを取得する試みの結果、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得できるhttp://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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は、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。