[要約] RFC 8866は、SDP（Session Description Protocol）の仕様を定義し、セッション情報の交換を可能にします。このRFCの目的は、異なるシステム間でのメディアセッションの設定と制御を効率的に行うための標準化を提供することです。
Internet Engineering Task Force (IETF) A. Begen
Request for Comments: 8866 Networked Media
Obsoletes: 4566 P. Kyzivat
Category: Standards Track
ISSN: 2070-1721 C. Perkins
University of Glasgow
M. Handley
UCL
January 2021
SDP: Session Description Protocol
SDP：セッション説明プロトコル
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. This document obsoletes RFC 4566.
このメモはセッション記述プロトコル（SDP）を定義します。SDPは、セッション発表、セッション招待、その他のマルチメディアセッション開始の目的のためのマルチメディアセッションを説明するためのものです。この文書はRFC 4566を廃止します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8866.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc8866で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この文書には、2008年11月10日以前に公開されたIETF文書または公開されたIETFの貢献からの資料を含めることができます。この材料のいくつかの著作権を制御する人は、そのような材料の修正を許可する権利を信頼する権利を与えられなかった人物IETF標準の外部プロセス。そのような材料の著作権を制御する人から適切なライセンスを取得せずに、この文書はIETF規格プロセスの外で修正されていない可能性があり、それをフォーマットすること以外はIETF標準プロセスの外ではデリバティブ作品が作成されない可能性があります。RFCとしての出版物、または英語以外の言語に翻訳する。
Table of Contents
目次
1. Introduction
2. Glossary of Terms
3. Examples of SDP Usage
3.1. Session Initiation
3.2. Streaming Media
3.3. Email and the World Wide Web
3.4. Multicast Session Announcement
4. Requirements and Recommendations
4.1. Media and Transport Information
4.2. Timing Information
4.3. Obtaining Further Information about a Session
4.4. Internationalization
5. SDP Specification
5.1. Protocol Version ("v=")
5.2. Origin ("o=")
5.3. Session Name ("s=")
5.4. Session Information ("i=")
5.5. URI ("u=")
5.6. Email Address and Phone Number ("e=" and "p=")
5.7. Connection Information ("c=")
5.8. Bandwidth Information ("b=")
5.9. Time Active ("t=")
5.10. Repeat Times ("r=")
5.11. Time Zone Adjustment ("z=")
5.12. Encryption Keys ("k=")
5.13. Attributes ("a=")
5.14. Media Descriptions ("m=")
6. SDP Attributes
6.1. cat (Category)
6.2. keywds (Keywords)
6.3. tool
6.4. ptime (Packet Time)
6.5. maxptime (Maximum Packet Time)
6.6. rtpmap
6.7. Media Direction Attributes
6.7.1. recvonly (Receive-Only)
6.7.2. sendrecv (Send-Receive)
6.7.3. sendonly (Send-Only)
6.7.4. inactive
6.8. orient (Orientation)
6.9. type (Conference Type)
6.10. charset (Character Set)
6.11. sdplang (SDP Language)
6.12. lang (Language)
6.13. framerate (Frame Rate)
6.14. quality
6.15. fmtp (Format Parameters)
7. Security Considerations
8. IANA Considerations
8.1. The "application/sdp" Media Type
8.2. Registration of SDP Parameters with IANA
8.2.1. Registration Procedure
8.2.2. Media Types (<media>)
8.2.3. Transport Protocols (<proto>)
8.2.4. Attribute Names (<attribute-name>)
8.2.5. Bandwidth Specifiers (<bwtype>)
8.2.6. Network Types (<nettype>)
8.2.7. Address Types (<addrtype>)
8.3. Encryption Key Access Methods (OBSOLETE)
9. SDP Grammar
10. Summary of Changes from RFC 4566
11. References
11.1. Normative References
11.2. Informative References
Acknowledgements
Authors' Addresses
When initiating multimedia teleconferences, voice-over-IP calls, streaming video, or other sessions, there is a requirement to convey media details, transport addresses, and other session description metadata to the participants.
マルチメディアの電話会議、音声オーバーIP呼び出し、ストリーミングビデオ、またはその他のセッションを開始するときは、メディアの詳細、トランスポートアドレス、およびその他のセッション記述メタデータを参加者に伝える必要があります。
SDP provides a standard representation for such information, irrespective of how that information is transported. SDP is purely a format for session description -- it does not incorporate a transport protocol, and it is intended to use different transport protocols as appropriate, including the Session Announcement Protocol (SAP) [RFC2974], Session Initiation Protocol (SIP) [RFC3261], Real-Time Streaming Protocol (RTSP) [RFC7826], electronic mail [RFC5322] using the MIME extensions [RFC2045], and the Hypertext Transport Protocol (HTTP) [RFC7230].
SDPは、その情報がどのように輸送されるかに関係なく、そのような情報の標準表現を提供します。SDPは純粋にセッション記述のフォーマットです。]、リアルタイムストリーミングプロトコル（RTSP）[RFC7826]、MIMEエクステンション[RFC2045]、およびハイパーテキストトランスポートプロトコル（HTTP）[RFC7230]を使用して、RFC7826 [RFC5322]。
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 [RFC4566]. The changes relative to [RFC4566] are outlined in Section 10 of this memo.
このメモが廃止された[RFC4566]。[RFC4566]に対する変更は、このメモの第10章で概説されています。
The following terms are used in this document and have specific meaning within the context of this document.
この文書では、次の用語が使用されており、この文書のコンテキスト内で特定の意味があります。
Session Description: A well-defined format for conveying sufficient information to discover and participate in a multimedia session.
セッションの説明：マルチメディアセッションに発見および参加するのに十分な情報を伝えるための明確な形式。
Media Description: A Media Description contains the information needed for one party to establish an application-layer network protocol connection to another party. It starts with an "m=" line and is terminated by either the next "m=" line or by the end of the session description.
メディアの説明：メディアの説明には、ある当事者に必要な情報が含まれています。それは "m ="行で始まり、次の "m ="行またはセッション記述の終わりまでに終了します。
Session-Level Section: This refers to the parts that are not media descriptions, whereas the session description refers to the whole body that includes the session-level section and the media description(s).
セッションレベルのセクション：これはメディアの説明ではない部分を表しますが、セッションの説明はセッションレベルのセクションとメディア記述を含む全体を参照します。
The terms "multimedia conference" and "multimedia session" are used in this document as defined in [RFC7656]. The terms "session" and "multimedia session" are used interchangeably in this document.
「マルチメディア会議」および「マルチメディアセッション」という用語は、[RFC7656]で定義されているようにこの文書で使用されています。この文書では、「セッション」および「マルチメディアセッション」という用語が互換的に使用されます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
「必須」、「必須」、「必須」、「SHALL」、「必ず」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「推奨する」、「5月」「この文書では、BCP 14 [RFC2119] [RFC8174]に記載されている場合に解釈されるべきであり、ここに示すように、すべての首都に表示されます。
The Session Initiation Protocol (SIP) [RFC3261] 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 [RFC6838]. These session descriptions are commonly formatted using SDP. When used with SIP, the offer/answer model [RFC3264] provides a limited framework for negotiation using SDP.
セッション開始プロトコル（SIP）[RFC3261]は、インターネットマルチメディアカンファレンス、インターネット電話通話、マルチメディア分布などのセッションを作成、変更、および終了するためのアプリケーション層制御プロトコルです。セッションの作成に使用されるSIPメッセージは、参加者が互換性のあるメディアタイプのセットで同意できるセッション記述をキャリーです[RFC6838]。これらのセッションの説明は、SDPを使用して一般的にフォーマットされています。SIPとともに使用すると、オファー/アンサーモデル[RFC3264]はSDPを使用したネゴシエーションのための限定的なフレームワークを提供します。
The Real-Time Streaming Protocol (RTSP) [RFC7826], 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）[RFC7826]は、リアルタイム特性を持つデータの配信を制御するためのアプリケーションレベルプロトコルです。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.
セッションの説明の代替手段には、電子メール、およびワールドワイドウェブ（WWW）が含まれます。電子メールの配信とWWWの両方の配布では、メディアタイプ「Application / SDP」が使用されます。これにより、標準的な方法でWWWクライアントまたはメールリーダーからのセッションへの参加へのアプリケーションの自動起動が可能になります。
Note that descriptions of multicast sessions sent only via email or the WWW do not have the property that the receiver of a session description 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 possibly 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 SAP [RFC2974]. SDP provides the recommended session description format for such session announcements.
このような分散ディレクトリを実装するために使用される1つのプロトコルはSAP [RFC2974]です。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 with Internet protocols, although it is sufficiently general that it can describe multimedia 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 description includes the following:
SDPの説明には次のものが含まれます。
* Session name and purpose
* セッション名と目的
* Time(s) the session is active
* セッションはアクティブです
* The media comprising the session
* セッションを含むメディア
* Information needed to receive those media (addresses, ports, formats, etc.)
* それらのメディアを受信するために必要な情報（アドレス、ポート、フォーマットなど）
As resources necessary to participate in a session may be limited, some additional information may also be desirable:
セッションに参加するのに必要なリソースが制限される可能性があるので、いくつかの追加情報も望ましいかもしれない。
* Information about the bandwidth to be used by the session
* セッションによって使用される帯域幅に関する情報
* Contact information for the person responsible for the session
* セッションの責任者のための連絡先情報
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 nonparticipants 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 description includes the following media information:
SDP記述には、次のメディア情報が含まれています。
* The type of media (video, audio, etc.)
* メディアの種類（ビデオ、オーディオなど）
* The media transport protocol (RTP/UDP/IP, H.320, etc.)
* メディアトランスポートプロトコル（RTP / UDP / IP、H.320など）
* The format of the media (H.261 video, MPEG video, etc.)
* メディアのフォーマット（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マルチキャストセッションの場合、これらは以下を含みます。
* The multicast group address for media
* メディアのマルチキャストグループアドレス
* The transport port for media
* 媒体の輸送ポート
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セッションの場合は、次のことが伝えられます。
* The remote address for media
* メディアのリモートアドレス
* The remote transport port for media
* メディアのリモートトランスポートポート
The semantics of the address and port depend on context. Typically, this SHOULD be the remote address and remote port to which media is to be sent or received. Details may differ based on the network type, address type, protocol, and media specified, and whether the SDP is being distributed as an advertisement or negotiated in an offer/answer [RFC3264] exchange. (E.g., Some address types or protocols may not have a notion of port.) Deviating from typical behavior should be done cautiously since this complicates implementations (including middleboxes that must parse the addresses to open Network Address Translation (NAT) or firewall pinholes).
アドレスとポートのセマンティクスはコンテキストによって異なります。通常、これはメディアを送受信するか受信するリモートアドレスとリモートポートです。詳細は、ネットワークタイプ、アドレスタイプ、プロトコル、およびメディアが指定されていて、SDPが広告として配布されているか、オファー/アンサー[RFC3264] Exchangeで交渉されているかどうかによって異なります。（例えば、いくつかのアドレスタイプまたはプロトコルはポートの概念を持っていない可能性がある。）これは実装を複雑にするので、典型的な動作からの逸脱は、実装を複雑にする必要があります（ネットワークアドレス変換（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は伝えられます。
* An arbitrary list of start and stop times bounding the session
* セッションを囲む開始時間と停止時間の任意のリスト
* For each bound, repeat times such as "every Wednesday at 10am for one hour"
* バインドごとに、「毎週水曜日の午前10時間1時間」などの回復時間
This timing information is globally consistent, irrespective of local time zone or daylight saving time (see Section 5.9).
このタイミング情報は、現地のタイムゾーンまたは夏時間に関係なく、グローバルに一貫性があります（セクション5.9を参照）。
A session description could 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) [RFC3986] for more information about the session. (Note that use of URIs to indicate remote resources is subject to the security considerations from [RFC3986].)
セッションの説明は、セッションに参加するかどうかを決定するために十分な情報を伝えます。SDPは、セッションの詳細については、統一リソース識別子（URI）[RFC3986]の形で追加のポインタを含めることができます。（リモートリソースを示すURIの使用は、[RFC3986]からセキュリティ上の考慮事項に従います。）
The SDP specification recommends the use of the ISO 10646 character set in the UTF-8 encoding [RFC3629] 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.1998] to be used when desired. Internationalization only applies to free-text subfields (session name and background information), and not to SDP as a whole.
SDP仕様では、さまざまな言語を表すことができるように、UTF-8エンコード[RFC3629]でISO 10646文字セットを使用することをお勧めします。ただし、コンパクトな表現を支援するために、SDPは必要に応じて[ISO.8859-1998]などの他の文字セットを使用することもできます。国際化はフリーテキストサブフィールド（セッション名と背景情報）にのみ適用され、SDP全体としてSDPには適用されません。
An SDP description is denoted by the media type "application/sdp" (See Section 8).
SDPの説明は、メディアタイプ「アプリケーション/ SDP」によって表される（セクション8を参照）。
An SDP description is entirely textual. SDP field names and attribute names use only the US-ASCII subset of UTF-8 [RFC3629], but textual fields and attribute values MAY use the full ISO 10646 character set in UTF-8 encoding, or some other character set defined by the "a=charset:" attribute (Section 6.10). Field and attribute values that use the full UTF-8 character set are never directly compared, hence there is no requirement for UTF-8 normalization. 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 descriptions 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 descriptions that could be detected easily and discarded.
SDPの説明は完全にテキストです。 SDPフィールド名と属性名はUTF-8 [RFC3629]のUS-ASCIIサブセットのみを使用しますが、テキストフィールドと属性値は、UTF-8エンコーディングで完全なISO 10646文字セット、またはその他の文字セットを使用することができます。 a = charset： "属性（6.10項）。フルUTF-8文字セットを使用するフィールドと属性値は、直接比較されないため、UTF-8正規化に必要な要件はありません。 ASN.1またはXDRのようなバイナリエンコードとは対照的に、さまざまなトランスポートを使用することを可能にし、柔軟でテキストベースのツールキットを使用して生成および処理するために使用できるようにするために、移植性を向上させるために選択されたテキスト形式が選択されました。セッションの説明しかしながら、SDPは、セッション記述の最大許容サイズが制限されている環境で使用され得るので、符号化は意図的にコンパクトになる。また、記述は、非常に信頼性の低い手段を介してまたは中間キャッシングサーバーによって損傷を受ける可能性があるため、ほとんどのエラーが容易かつ廃棄することができる不正なセッションの説明をもたらす可能性があるため、符号化は厳密な順序とフォーマット規則で設計されました。
An SDP description consists of a number of lines of text of the form:
SDPの説明は、次の形式のテキスト行の行で構成されています。
<type>=<value>
where <type> is exactly one case-significant character and <value> is structured text whose format depends on <type>. In general, <value> is either a number of subfields delimited by a single space character or a free format string, and is case-significant unless a specific field defines otherwise. Whitespace separators are not used on either side of the "=" sign, however, the value can contain a leading whitespace as part of its syntax, i.e., that whitespace is part of the value.
ここで、<type>は正確に1つのケースで重要な文字と<value>は、フォーマットが<type>に依存する構造化テキストです。一般に、<value>は、単一のスペース文字または空き形式の文字列によって区切られた数のサブフィールドのいずれかであり、特定のフィールドを定義しない限り大文字と小文字が区別されます。しかしながら、「=」記号の両側では空白の区切り文字は使用されていないが、その値はその構文の一部として最先端の空白を含むことができ、すなわち空白は値の一部である。
An SDP description MUST conform to the syntax defined in Section 9. The following is an overview of the syntax.
SDPの説明はセクション9で定義されている構文に準拠している必要があります。次に、構文の概要です。
An SDP description consists of a session-level section followed by zero or more media descriptions. The session-level section starts with a "v=" line and continues to the first media description (or the end of the whole description, whichever comes first). Each media description starts with an "m=" line and continues to the next media description or the end of the whole session description, whichever comes first. In general, session-level values are the default for all media unless overridden by an equivalent media-level value.
SDP記述はセッションレベルのセクションとそれに続くゼロ以上のメディアの説明で構成されています。セッションレベルのセクションは "v ="行で始まり、最初のメディアの説明（または説明の終わり、最初に記述の終わり）に続きます。各メディア記述は「M =」行で始まり、次のメディアの説明またはセッション記述の全体の終わりに続きます。一般に、同等のメディアレベルの値によって上書きされない限り、セッションレベルの値はすべてのメディアのデフォルトです。
Some lines in each description are required and some are optional, but when present, they must appear in exactly the order given here. (The fixed order greatly enhances error detection and allows for a simple parser). In the following overview, optional items are marked with a "*".
各説明のいくつかの行は必須であり、オプションであるが、存在する場合は、ここで与えられた順序で正確に現れる必要があります。（固定順序はエラー検出を大幅に向上させ、単純なパーサーを可能にします）。次の概要では、オプションの項目に「*」が付いています。
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 descriptions)
b=* (zero or more bandwidth information lines)
One or more time descriptions:
("t=", "r=" and "z=" lines; see below)
k=* (obsolete)
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)
z=* (optional time zone offset line)
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=* (obsolete)
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 or reject any session description that contains a type letter that it does not understand. The attribute mechanism ("a=", described in Section 5.13) is the primary means for extending SDP and tailoring it to particular applications or media. Some attributes (the ones listed in Section 6) have a defined meaning, but others may be added on a media- or session-specific basis. (Attribute scopes in addition to media-specific and session-specific scopes may also be defined in extensions to this document, e.g., [RFC5576] and [RFC8864].) An SDP parser MUST ignore any attribute it doesn't understand.
タイプの文字のセットは故意に小さく、拡張可能なものではありません.SDPパーサーは、わからないタイプの文字を含むセッション記述を完全に無視または拒否する必要があります。属性メカニズム（セクション5.13で説明されている "A ="）は、SDPを拡張し、それを特定のアプリケーションまたはメディアに調整するための主な手段です。いくつかの属性（セクション6に記載されているもの）は定義された意味を持ちますが、他のものはメディアまたはセッション固有の基準で追加することができます。（メディア固有のスコープおよびセッション固有のスコープに加えて属性スコープは、このドキュメント、例えば[RFC5576]、[RFC8864]に拡張子で定義されている可能性があります。）SDPパーサーは、わからない属性を無視する必要があります。
An SDP 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=") information in the session-level section applies to all the media descriptions of that session unless overridden by connection information in the media description. For instance, in the example below, each audio media description behaves as if it were given a "c=IN IP4 198.51.100.1".
セッションレベルのセクションの接続（ "C ="）情報は、メディア記述の接続情報によってオーバーライドされていない限り、そのセッションのすべてのメディアの説明に適用されます。たとえば、以下の例では、各オーディオメディアの説明は、「C = IP4 198.51.100.1」を与えられたかのように動作します。
An example SDP description is:
例示的なSDPの説明は次のとおりです。
v=0
o=jdoe 3724394400 3724394405 IN IP4 198.51.100.1
s=Call to John Smith
i=SDP Offer #1
u=http://www.jdoe.example.com/home.html
e=Jane Doe <jane@jdoe.example.com>
p=+1 617 555-6011
c=IN IP4 198.51.100.1
t=0 0
m=audio 49170 RTP/AVP 0
m=audio 49180 RTP/AVP 0
m=video 51372 RTP/AVP 99
c=IN IP6 2001:db8::2
a=rtpmap:99 h263-1998/90000
Text-containing fields such as the session-name-field and information-field 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 line, although parsers SHOULD be tolerant and also accept lines 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. When the "a=charset:" attribute is present the session-name-field, information-field, and some attribute fields are interpreted according to the selected character set.
session-name-field-fieldと情報フィールドなどのテキスト含有フィールドは、0x00（NUL）、0x0A（ASCII Newline）、および0x0D（ASCIIキャリッジリターン）の例外を持つオクテットを含めることができるオクテット文字列です。シーケンスCRLF（0x0D0A）はラインを終了するために使用されますが、パーサーは耐許容され、単一の改行文字で終端された行も受け入れます。"a = charset："属性が存在しない場合、これらのオクテット文字列は、UTF-8エンコーディングのISO-10646文字を含むと解釈されなければなりません。"a = charset："属性が存在する場合、session-name-field、情報フィールド、および一部の属性フィールドは、選択した文字セットに従って解釈されます。
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 [RFC1034] and [RFC1035]. Internationalized domain names (IDNs) MUST be represented using the ASCII Compatible Encoding (ACE) form defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or any other encoding (this requirement is for compatibility with [RFC2327] and other early SDP-related standards, which predate the development of internationalized domain names).
セッション記述には、「O =」、「U =」、「E =」、「C =」、「A =」行のドメイン名を含めることができます。SDPで使用されているドメイン名は、[RFC1034]と[RFC1035]に準拠している必要があります。国際化されたドメイン名（IDNS）は、[RFC5890]で定義されているASCII互換エンコーディング（ACE）フォームを使用して表現する必要があり、UTF-8またはその他のエンコードでは直接表現されてはいけません（この要件は[RFC2327]とその他の早期の互換性があります。国際化されたドメイン名の開発を述べるSDP関連の基準。
v=0
v = 0
The "v=" line (version-field) gives the version of the Session Description Protocol. This memo defines version 0. There is no minor version number.
"v ="行（version-field）は、セッション記述プロトコルのバージョンを提供します。このメモはバージョン0を定義します。マイナーバージョン番号はありません。
o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>
The "o=" line (origin-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 =」回線（origin-field）は、セッションの発信者（ユーザーのユーザー名とアドレス）とセッション識別子とバージョン番号を与えます。
<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 a timestamp, in seconds since January 1, 1900 UTC, is recommended to ensure uniqueness.
<sess-id>は、<username>、<sess-id>、<nettype>、<addrtype>、および<unicast-address>、および<unicast-address>、<unicast-address>、<unicast-address>、<unicast-address>、<unicast-address>をフォーマットする数値文字列です。<SESS-ID>の割り当ての方法は、1900年1月1日から1月1日以降のタイムスタンプが一意性を確保するために推奨されます。
<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 description. Again, as with <sess-id> it is RECOMMENDED that a timestamp be used.
<SESSバージョン>このセッションの説明のバージョン番号です。その使用方法はセッション記述に変更が加えられたときに<SESSバージョン>が増加する限り、創造ツール次第です。繰り返しますが、<SESS-ID>と同様に、タイムスタンプを使用することをお勧めします。
<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 an address of the machine from which the session was created. For an address type of "IP4", this is either a fully qualified domain name of the machine or the dotted-decimal representation of an IP version 4 address of the machine. For an address type of "IP6", this is either a fully qualified domain name of the machine or the address of the machine represented as specified in Section 4 of [RFC5952]. For both "IP4" and "IP6", the fully qualified domain name is the form that SHOULD be given unless this is unavailable, in which case a globally unique address MAY be substituted.
<unicast-address>は、セッションが作成されたマシンのアドレスです。アドレスタイプの "IP4"の場合、これはマシンの完全修飾ドメイン名、またはマシンのIPバージョン4アドレスのドット付き10進表現です。アドレスタイプの "IP6"の場合、これは[RFC5952]のセクション4で指定されているマシンの完全修飾ドメイン名またはマシンのアドレスです。"IP4"と "IP6"の両方で、完全修飾ドメイン名は、これが利用できない限り、その場合はグローバルに固有のアドレスを置き換えることができます。
In general, the "o=" line serves as a globally unique identifier for this version of the 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=" line, 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=" line (session-name-field) is the textual session name. There MUST be one and only one "s=" line per session description. The "s=" line MUST NOT be empty. If a session has no meaningful name, then "s= " or "s=-" (i.e., a single space or dash as the session name) is RECOMMENDED. If a session-level "a=charset:" attribute is present, it specifies the character set used in the "s=" field. If a session-level "a=charset:" attribute is not present, the "s=" field MUST contain ISO 10646 characters in UTF-8 encoding.
"s ="行（session-name-field）はテキストセッション名です。セッション記述ごとに1つだけの「S =」行が必要です。"s ="行を空にしてはいけません。セッションに意味のある名前がない場合は、「S =」または「S = - 」（すなわち、セッション名として単一のスペースまたはダッシュ）を推奨します。セッションレベル "a = charset："属性が存在する場合は、 "s ="フィールドで使用される文字セットを指定します。セッションレベル "a = charset："属性が存在しない場合は、UTF-8エンコードでISO 10646文字を含める必要があります。
i=<session information>
The "i=" line (information-field) provides textual information about the session. There can be at most one session-level "i=" line per session description, and at most one "i=" line in each media description. Unless a media-level "i=" line is provided, the session-level "i=" line applies to that media description. If the "a=charset:" attribute is present, it specifies the character set used in the "i=" line. If the "a=charset:" attribute is not present, the "i=" line MUST contain ISO 10646 characters in UTF-8 encoding.
「i =」回線（情報フィールド）は、セッションに関するテキスト情報を提供します。セッション記述ごとに、最大1つのセッションレベル "i ="行、および各メディア記述の最大1つの "i ="行がある可能性があります。メディアレベルの "i ="行が提供されていない限り、セッションレベルの "i ="行はそのメディアの説明に適用されます。"a = charset："属性が存在する場合は、 "i ="行で使用されている文字セットを指定します。"a = charset："属性が存在しない場合、 "i ="行にはISO 10646文字がUTF-8エンコードで含まれている必要があります。
At most one "i=" line can be used for each media description. In media definitions, "i=" lines are primarily intended for labeling media streams. As such, they are most likely to be useful when a single session has more than one distinct media stream of the same media type. An example would be two different whiteboards, one for slides and one for feedback and questions.
各メディアの説明には、ほとんどの「i =」回線を使用できます。メディア定義では、「i =」行は主にメディアストリームのラベリングを目的としています。そのため、単一のセッションに同じメディアタイプの2つ以上の異なるメディアストリームがある場合、それらは最も役立ちます。例は2つの異なるホワイトボード、スライド用のものとフィードバックや質問のためのものです。
The "i=" line 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>
The "u=" line (uri-field) provides a URI (Uniform Resource Identifier) [RFC3986]. The URI should be a pointer to additional human readable information about the session. This line is OPTIONAL. No more than one "u=" line is allowed per session description.
"u ="行（URIフィールド）はURI（Uniform Resource Identifier）[RFC3986]を提供します。URIは、セッションに関する追加の人間が読める可能性のある情報へのポインタであるべきです。この行はオプションです。セッションの説明ごとに複数の「u =」回線が許可されていません。
e=<email-address>
p=<phone-number>
The "e=" line (email-field) and "p=" line (phone-field) specify contact information for the person responsible for the session. This is not necessarily the same person that created the session description.
「E =」回線（電子メールフィールド）と「P =」回線（Phone-Field）セッションを担当する人の連絡先情報を指定します。これは必ずしもセッションの説明を作成したのと同じ人ではありません。
Inclusion of an email address or phone number is OPTIONAL.
電子メールアドレスまたは電話番号を含めることはオプションです。
If an email address or phone number is present, it MUST be specified before the first media description. More than one email or phone line 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 [E164]) 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 [E164]を参照）。スペースとハイフンを使用して、必要に応じて読みやすさを助けるために電話フィールドを分割することができます。例えば：
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 [RFC5322] name quoting convention is also allowed for both email addresses and phone numbers. For example:
代替の[RFC5322]名前の引用則もまた、電子メールアドレスと電話番号の両方に対して許可されています。例えば：
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または他のエンコーディングにある必要があります。
c=<nettype> <addrtype> <connection-address>
The "c=" line (connection-field) contains information necessary to establish a network connection.
「C =」回線（接続フィールド）には、ネットワーク接続を確立するために必要な情報が含まれています。
A session description MUST contain either at least one "c=" line in each media description or a single "c=" line at the session level. It MAY contain a single session-level "c=" line and additional media-level "c=" line(s) per-media-description, in which case the media-level values override the session-level settings for the respective media.
セッション記述には、各メディア記述内の少なくとも1つの "C ="行、またはセッションレベルで単一の "C ="行を含める必要があります。それは単一のセッションレベル "C ="行とメディアの記述ごとに追加のメディアレベル "c ="行を含めることができます。その場合、メディアレベルの値はそれぞれのメディアのセッションレベルの設定をオーバーライドします。。
The first subfield (<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 subfield (<addrtype>) is the address type. This allows SDP to be used for sessions that are not IP based. This memo only defines "IP4" and "IP6", but other values MAY be registered in the future (see Section 8).
2番目のサブフィールド（<addrtype>）はアドレスタイプです。これにより、SDPをIPベースではないセッションに使用できます。このメモは「IP4」と「IP6」を定義していますが、他の値は将来登録されている可能性があります（セクション8を参照）。
The third subfield (<connection-address>) is the connection address. Additional subfields MAY be added after the connection address depending on the value of the <addrtype> subfield.
3番目のサブフィールド（<接続アドレス>）は接続アドレスです。<addrtype>サブフィールドの値に応じて、接続アドレスの後に追加のサブフィールドを追加することができます。
When the <addrtype> is "IP4" or "IP6", the connection address is defined as follows:
<addrtype>が "IP4"または "IP6"の場合、接続アドレスは次のように定義されます。
* 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, data relay, or data sink as determined by additional attribute-fields (Section 5.13). 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.
* セッションがマルチキャストの場合、接続アドレスはIPマルチキャストグループアドレスになります。セッションがマルチキャストではない場合、接続アドレスには、追加の属性フィールド（セクション5.13）によって決定された、予想されるデータソース、データリレー、またはデータシンクのユニキャストIPアドレスが含まれています（セクション5.13）。これは禁止されていないが、マルチキャストアナウンスメントによって通信されるセッション記述においてユニキャストアドレスが与えられることは予想されない。
* Sessions using an "IP4" 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 session 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; applications SHOULD use an administratively scoped address instead.
* 「IP4」マルチキャスト接続アドレスを使用したセッションには、マルチキャストアドレスに加えて存在する時間（TTL）値が存在する時間も必要です。TTLとアドレスは一緒になって、このセッションで送信されたマルチキャストパケットが送信されるスコープを定義します。TTL値は0~255の範囲内でなければなりません。TTLを指定する必要がありますが、マルチキャストトラフィックのスコープへの使用は推奨されません。アプリケーションは代わりに管理スコープアドレスを使用する必要があります。
The TTL for the session is appended to the address using a slash as a separator. An example is:
セッションのTTLは、区切り文字としてスラッシュを使用してアドレスに追加されます。例は次のとおりです。
c=IN IP4 233.252.0.1/127
C = IP4 233.252.0.1/127
"IP6" multicast does not use TTL scoping, and hence the TTL value MUST NOT be present for "IP6" multicast. It is expected that IPv6 scoped addresses will be used to limit the scope of multimedia conferences.
"IP6"マルチキャストはTTLスコープを使用していないため、TTL値は "IP6"マルチキャストのために存在してはいけません。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 233.252.0.1/127/3
would state that addresses 233.252.0.1, 233.252.0.2, and 233.252.0.3 are to be used with a TTL of 127. This is semantically identical to including multiple "c=" lines in a media description:
アドレス233.252.0.1,233.252.0.2、および233.252.0.3をTTL 127で使用することを述べる。これは、メディアの説明内の複数の「C =」行を含む意味的に同じです。
c=IN IP4 233.252.0.1/127
c=IN IP4 233.252.0.2/127
c=IN IP4 233.252.0.3/127
Similarly, an IPv6 example would be:
同様に、IPv6の例は次のとおりです。
c=IN IP6 ff00::db8:0:101/3
which is semantically equivalent to:
これは以下と意味的に同等です。
c=IN IP6 ff00::db8:0:101
c=IN IP6 ff00::db8:0:102
c=IN IP6 ff00::db8:0:103
(remember that the TTL subfield is not present in "IP6" multicast).
（TTLサブフィールドは「IP6」マルチキャストには存在しません）。
Multiple addresses or "c=" lines MAY be specified on a per media description basis only if they provide multicast addresses for different layers in a hierarchical or layered encoding scheme. Multiple addresses or "c=" lines MUST NOT be specified at session level.
複数のアドレスまたは「C =」行は、階層的または階層化された符号化方式で異なるレイヤに対してマルチキャストアドレスを提供する場合にのみ、メディア記述ベースでのみ指定され得る。セッションレベルで複数のアドレスまたは「C =」行を指定しないでください。
The slash notation for multiple addresses described above MUST NOT be used for IP unicast addresses.
上記の複数のアドレスのスラッシュ表記は、IPユニキャストアドレスに使用しないでください。
b=<bwtype>:<bandwidth>
The OPTIONAL "b=" line (bandwidth-field) denotes the proposed bandwidth to be used by the session or media description. The <bwtype> is an alphanumeric modifier that provides the meaning of the <bandwidth> number. Two values are defined in this specification, but other values MAY be registered in the future (see Section 8 and [RFC3556], [RFC3890]):
オプションの「B =」行（帯域幅フィールド）は、セッションまたはメディアの説明によって使用される提案された帯域幅を表す。<bwtype>は、<帯域幅>番号の意味を提供する英数字修飾子です。この仕様では2つの値が定義されていますが、他の値は将来登録されることがあります（セクション8と[RFC3556]、[RFC3890]）。
CT If the bandwidth of 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). Similarly, if the bandwidth of bundled media streams [RFC8843] in an "m=" line is different from the implicit value from the scope, a "b=CT:" line SHOULD be supplied in the media level. The primary purpose of this is to give an approximate idea as to whether two or more sessions (or bundled media streams) can coexist simultaneously. Note that a "b=CT:" line gives a total bandwidth figure for all the media at all endpoints.
CTセッションの帯域幅がスコープから暗黙の帯域幅とは異なる場合は、「B = CT：」行を使用した帯域幅に提案されている上限（「会議の合計」帯域幅）に指定します。同様に、「M =」行のバンドルメディアストリームの帯域幅がスコープからの暗黙的値とは異なる場合は、「B = CT：」行をメディアレベルで指定する必要があります。これの主な目的は、2つ以上のセッション（またはバンドルメディアストリーム）が同時に共存できるかどうかに関しておおよそのアイデアを与えることです。"b = ct："行はすべてのエンドポイントのすべてのメディアの総帯域幅図を与えます。
The Mux Category for "b=CT:" is NORMAL. This is discussed in [RFC8859].
"b = ct："のMUXカテゴリは正常です。これについては[RFC8859]で説明します。
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, the "b=AS:" line gives the RTP "session bandwidth" as defined in Section 6.2 of [RFC3550]. Note that a "b=AS:" line gives a bandwidth figure for a single media at a single endpoint, although there may be many endpoints sending simultaneously.
帯域幅はアプリケーション固有であると解釈されるため（アプリケーションの最大帯域幅の概念になります）。通常、これは該当する場合は、アプリケーションの「最大帯域幅」コントロールに設定されているものと一致します。RTPベースのアプリケーションの場合、[B = AS： "行は[RFC3550]のセクション6.2で定義されているRTP"セッション帯域幅 "を示しています。なお、単一のエンドポイントでは、単一のエンドポイントで「B = AS：」行の帯域幅図を示しています。
The Mux Category for "b=AS:" is SUM. This is discussed in [RFC8859].
"b = AS："のMUXカテゴリは合計です。これについては[RFC8859]で説明します。
[RFC4566] defined an "X-" prefix for <bwtype> names. This was intended for experimental purposes only. For example:
[RFC4566] <bwtype>名の "x-"プレフィックスを定義しました。これは実験目的のみを目的としていました。例えば：
b=X-YZ:128
B = X-YZ：128
Use of the "X-" prefix is NOT RECOMMENDED. Instead new (non "X-" prefix) <bwtype> names SHOULD be defined, and then MUST be registered with IANA in the standard namespace. SDP parsers MUST ignore bandwidth-fields with unknown <bwtype> names. The <bwtype> names MUST be alphanumeric and, although no length limit is given, it is recommended that they be short.
「X-」プレフィックスを使用することはお勧めできません。代わりに、新しい（X- "プレフィックス以外の）<BWType>名を定義し、標準ネームスペースでIANAに登録する必要があります。SDPパーサーは、不明な<BWTYPE>名を持つ帯域幅フィールドを無視する必要があります。<bwtype>名は英数字でなければならず、長さの制限は与えられていませんが、それらが短くなることをお勧めします。
The <bandwidth> is interpreted as kilobits per second by default (including the transport and network-layer, but not the link-layer, overhead). The definition of a new <bwtype> modifier MAY specify that the bandwidth is to be interpreted in some alternative unit (the "CT" and "AS" modifiers defined in this memo use the default units).
<帯域幅>は、デフォルトで1秒あたりのキロビットとして解釈されます（トランスポート層とネットワーク層を含むが、リンクレイヤ、オーバーヘッドではありません）。新しい<bwtype>修飾子の定義は、このメモで定義されている変更内の変更点（ "CT"および ""として、帯域幅を解釈することを指定することができます。
t=<start-time> <stop-time>
A "t=" line (time-field) begins a time description that specifies the start and stop times for a session. Multiple time descriptions MAY be used if a session is active at multiple irregularly spaced times; each additional time description specifies additional periods of time for which the session will be active. If the session is active at regular repeat times, a repeat description, begun by an "r=" line (see Section 5.10) can be included following the time-field -- in which case the time-field specifies the start and stop times of the entire repeat sequence.
「t =」回線（time-field）は、セッションの開始時間と停止時間を指定する時間記述を開始します。セッションが複数の不規則に間隔を置いて配置された時間でアクティブである場合、複数の時間記述を使用することができます。追加の各時間記述は、セッションがアクティブになる追加の期間を指定します。セッションが定期的な繰り返し時間でアクティブである場合は、「R =」回線で始まった繰り返し説明（セクション5.10を参照）を入力することができます。この場合、time-fieldは開始時間と停止時間を指定します。繰り返しシーケンス全体の
The following example specifies two active intervals:
次の例では、2つのアクティブな間隔を指定します。
t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC
t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC
The first and second subfields of the time-field give the start and stop times, respectively, for the session. These are the decimal representation of time values in seconds since January 1, 1900 UTC. To convert these values to Unix time (UTC), subtract decimal 2208988800.
time-fieldの最初と2番目のサブフィールドは、セッションの開始時間と停止時間をそれぞれ与えます。これらは、1900年1月1日から数秒の時間値の10進表現です。これらの値をUnix Time（UTC）に変換するには、10進数2208988800を減算します。
Some time representations will wrap in the year 2036. Because SDP uses an arbitrary length decimal representation, it does not have this issue. Implementations of SDP need to be prepared to handle these larger values.
SDPは任意の長さの10進表現を使用するため、この問題はありませんので、いくつかの時間表現が折り返されます。SDPの実装はこれらの大きい値を処理するために準備する必要があります。
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 behavior other than this is required, a <stop-time> SHOULD be given and modified as appropriate when new information becomes available about when the session should really end.
ユーザにタイムアウトしていない無制限のセッションを表示するときに、無制限のセッションは、現在時刻またはセッション開始時刻からの半分までのみアクティブになるだけであれば、そのまま有効の仮定を行うことができる。これ以外の動作が必要な場合は、セッションが実際に終了する必要がある場合に新しい情報が利用可能になったときに適切に<停止時間>を指定および変更する必要があります。
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>
An"r=" line (repeat-field) specifies repeat times for a session. If needed to express complex schedules, multiple repeat-fields may be included. 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=" line would be the 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=" line stop time would be the representation of the end of the last session three months later. By default, all subfields are in seconds, so the "r=" and "t=" lines might be the following:
"R ="行（repeat-field）は、セッションの繰り返し時間を指定します。複雑なスケジュールを表現するために必要な場合、複数の繰り返しフィールドが含まれている可能性があります。たとえば、月曜日の午前10時に午前11時に起動している場合、毎週3月の毎週3月の午前11時にアクティブになった場合、対応する "T ="行の<start-time>は、月曜日の最初の「T =」行の表現になります。、<繰り返し間隔>は1週間、<能動期間>は1時間になり、オフセットはゼロ、25時間です。対応する「t =」ライン停止時間は、3か月後の最後のセッションの終了の表現になります。デフォルトでは、すべてのサブフィールドが秒単位であるため、 "R ="行と "t ="行は次のようになります。
t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC
; Tues 20-Mar-2018 12:00 UTC
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours
To make the 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:
説明をよりコンパクトにするために、時刻、時間、または分の単位でも与えられます。これらの構文は、直後に1つの大文字と小文字の区別文字が続く数値です。フラクショナルユニットは許可されていません - 代わりに小さい単位を使用する必要があります。以下の単位指定文字が許可されています。
+---+------------------------------------+
| d | days (86400 seconds) |
+---+------------------------------------+
| h | hours (3600 seconds) |
+---+------------------------------------+
| m | minutes (60 seconds) |
+---+------------------------------------+
| s | seconds (allowed for completeness) |
+---+------------------------------------+
Table 1: Time Unit Specification Characters
表1：タイムユニット指定文字
Thus, the above repeat-field could also have been written:
したがって、上記の繰り返しフィールドも書き込まれている可能性があります。
r=7d 1h 0 25h
R = 7D 1H 0 25H
Monthly and yearly repeats cannot be directly specified with a single SDP repeat time; instead, separate time-descriptions should be used to explicitly list the session times.
毎月の繰り返しは、単一のSDP繰り返し時間で直接指定することはできません。代わりに、別々の時間記述を使用してセッション時間を明示的にリストする必要があります。
z=<adjustment time> <offset> <adjustment time> <offset> ....
A "z=" line (zone-field) is an optional modifier to the repeat-fields it immediately follows. It does not apply to any other fields.
「Z =」回線（ZONE-FIELD）は、直後の繰り返しフィールドへのオプションの修飾子です。他の分野には適用されません。
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 time (represented as seconds since January 1, 1900 UTC) that a time zone adjustment happens and the offset from the time when the session was first scheduled. The "z=" line allows the sender to specify a list of these adjustment times and offsets from the base time.
したがって、冬と夏に同じ時間にあるセッションをスケジュールするためには、そのタイムゾーンAセッションがスケジュールされていることによって明白に指定することが可能でなければなりません。このタスクを受信機に簡単にするために、送信者は、タイムゾーン調整が発生し、セッションが最初にスケジュールされた時からのオフセットを送信者に指定することができます。"z ="行を使用すると、送信者はこれらの調整時間とオフセットのリストを基準時間から指定できます。
An example might be the following:
例は次のとおりです。
t=3724394400 3754123200 ; Mon 8-Jan-2018 10:00 UTC
; Tues 18-Dec-2018 12:00 UTC
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours
z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC,
; offset 1 hour,
; Sun 28-Oct-2018 2:00 UTC,
; no offset
This specifies that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, the onset of British Summer Time) the time base by which the session's repeat times are calculated is shifted back by 1 hour, and that at time 3749680800 (Sun 28-Oct-2018 2:00 UTC, the end of British Summer Time) the session's original time base is restored. Adjustments are always relative to the specified start time -- they are not cumulative.
これは、時刻3730928400（Sun 25-Mar-2018年1:00 UTC、イギリスの夏時間の開始）を指定して、セッションの繰り返し時間が計算されるタイムベースは1時間でシフトバックされ、その時点で3749680800（Sun）28 - 2018年10月28日2:00 UTC、イギリスの夏時間の終わり）セッションの元のタイムベースが復元されます。調整は常に指定された開始時刻を基準にしています - 累積的ではありません。
If a session is likely to last several years, it is expected that the session description will be modified periodically rather than transmit several years' worth of adjustments in one session description.
セッションが数年続く可能性がある場合は、1つのセッションの説明で数年の調整を送信するのではなく、セッションの説明は定期的に修正されることが予想されます。
k=<method>
k=<method>:<encryption key>
The "k=" line (key-field) is obsolete and MUST NOT be used. It is included in this document for legacy reasons. One MUST NOT include a "k=" line in an SDP, and MUST discard it if it is received in an SDP.
「k =」回線（キーフィールド）は廃止され、使用してはいけません。レガシーの理由からこの文書に含まれています。SDPに "k ="行を含めてはならず、SDPで受信された場合は捨ててください。
a=<attribute-name>
a=<attribute-name>:<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. (Attribute scopes in addition to media-level and session-level scopes may also be defined in extensions to this document, e.g., [RFC5576] and [RFC8864].)
属性はSDPを拡張するための主な手段です。属性は、セッションレベルの属性、メディアレベルの属性、またはその両方として使用されるように定義されます。（メディアレベルおよびセッションレベルのスコープに加えて属性スコープは、このドキュメント、例えば[RFC5576]および[RFC8864]に拡張子で定義されている可能性があります。）
A media description may contain any number of "a=" lines (attribute-fields) that are media description specific. These are referred to as media-level attributes and add information about the media description. Attribute-fields can also be added before the first media description; these session-level attributes convey additional information that applies to the session as a whole rather than to individual media descriptions.
メディア記述には、メディア記述固有の任意の数の「A =」行（属性フィールド）が含まれている場合があります。これらはメディアレベルの属性と呼ばれ、メディアの説明に関する情報を追加します。属性フィールドは、最初のメディアの説明の前に追加することもできます。これらのセッションレベルの属性は、個々のメディアの説明よりもむしろセッションに適用される追加情報を伝えます。
Attribute-fields may be of two forms:
属性フィールドは2つの形式である可能性があります。
* A property attribute is simply of the form "a=<attribute-name>". 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".
* プロパティ属性は単に "a = <attribute-name>"の形式です。これらはバイナリ属性であり、属性の存在は属性がセッションのプロパティであることを伝えます。例は「a = Recvonly」である可能性があります。
* A value attribute is of the form "a=<attribute-name>:<attribute-value>". For example, a whiteboard could have the value attribute "a=orient:landscape".
* 値属性は、 "a = <attribute-name>：<属性値>"の形式です。たとえば、ホワイトボードでは、値属性 "a = outite：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 "a=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）を除く任意のオクテット値を使用できます。デフォルトでは、属性値は、UTF-8エンコーディングを使用してISO-10646文字セットのように解釈されます。他のテキストフィールドとは異なり、属性値は通常 "a = 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を参照）。理解されていない属性を受信した場合、それは受信機によって無視されなければなりません。
m=<media> <port> <proto> <fmt> ...
M = <メディア> <ポート> <Proto> <FMT> ...
A session description may contain a number of media descriptions. Each media description starts with an "m=" line (media-field) and is terminated by either the next "m=" line or by the end of the session description. A media-field has several subfields:
セッション記述には、いくつかのメディアの説明が含まれている可能性があります。各メディア記述は「M =」回線（Media-Field）で始まり、次の「M =」回線またはセッション記述の終わりまでに終了します。メディアフィールドにはいくつかのサブフィールドがあります。
<media> is the media type. This document defines the values "audio", "video", "text", "application", and "message". This list is extended by other memos and may be further extended by additional memos registering media types in the future (see Section 8). For example, [RFC6466] defined the "image" media type.
<media>はメディアタイプです。この文書は、「オーディオ」、「ビデオ」、「テキスト」、「アプリケーション」、および「メッセージ」という値を定義します。このリストは他のメモによって拡張され、将来的にはメディアタイプを追加のメモ登録することによってさらに拡張されてもよい（セクション8を参照）。たとえば、[RFC6466]は「image」メディアタイプを定義しました。
<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=" line, and on the transport protocol defined in the <proto> subfield of the media-field. Other ports used by the media application (such as the RTP Control Protocol (RTCP) port [RFC3550]) MAY be derived algorithmically from the base media port or MAY be specified in a separate attribute (for example, the "a=rtcp:" attribute as defined in [RFC3605]).
<port>は、メディアストリームが送信されるトランスポートポートです。トランスポートポートの意味は、関連する "C ="行、およびメディアフィールドの<proto>サブフィールドに定義されているトランスポートプロトコルで使用されているネットワークによって異なります。メディアアプリケーション（RTP制御プロトコル（RTCP）ポート[RFC3550]など）によって使用される他のポートは、ベースメディアポートからアルゴリズム的に導出されてもよく、または別の属性で指定されてもよい（たとえば、 "a = rtcp："[RFC3605]で定義されている属性）。
If noncontiguous 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:" attribute 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："属性を使用する必要があります。<port>に存在し、 "a = rtcp："属性が存在する<port>に存在するように要求されているアプリケーションは、RTPポートから1を減算しないでください。つまり、<で示されているポートにRTPを送信する必要があります。「a = rtcp：」属性に示されているポートにrtcpを送信します。
For applications where hierarchically encoded streams are being sent to a unicast address, it may be necessary to specify multiple transport ports. This is done using a similar notation to that used for IP multicast addresses in the "c=" line:
階層的に符号化されたストリームがユニキャストアドレスに送信されているアプリケーションの場合、複数のトランスポートポートを指定する必要があるかもしれません。これは、 "C ="行のIPマルチキャストアドレスに使用されるものと同様の表記を使用して行われます。
m=<media> <port>/<number of ports> <proto> <fmt> ...
M = <メディア> <ポート> / <ポート数> <PROTO> <FMT> ...
In such a case, the ports used depend on the transport protocol. For RTP, the default is that only the even-numbered ports are used for data with the corresponding one-higher odd ports used for the RTCP belonging to the RTP session, and the <number of ports> denoting the number of RTP sessions. For example:
そのような場合、使用されるポートはトランスポートプロトコルによって異なります。RTPの場合、デフォルトでは、RTPセッションに属するRTCPに使用される対応する1より高い奇数ポート、および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 the description of <fmt> below).
ポート49170と49171は1つのRTP / RTCPペアを形成し、49172と49173は2番目のRTP / RTCPペアを形成します。RTP / AVPはトランスポートプロトコルで、31はフォーマットです（下記の<fmt>の説明を参照）。
This document does not include a mechanism for declaring hierarchically encoded streams using noncontiguous ports. (There is currently no attribute defined that can accomplish this. The "a=rtcp:" attribute defined in [RFC3605] does not handle hierarchical encoding.) If a need arises to declare noncontiguous ports then it will be necessary to define a new attribute to do so.
この文書には、連続していないポートを使用して階層的にエンコードされたストリームを宣言するためのメカニズムは含まれていません。（これを実現できる属性は定義されていません。[RFC3605]で定義されている "a = rtcp："属性は階層型エンコーディングを処理しません。）必要がないポートを宣言する必要がある場合は、新しい属性を定義する必要があります。そうするために。
If multiple addresses are specified in the "c=" line and multiple ports are specified in the "m=" line, a one-to-one mapping from port to the corresponding address is implied. For example:
"C ="行で複数のアドレスが指定され、 "m ="行で複数のポートが指定されている場合、ポートから対応するアドレスへの1対1のマッピングが暗示されます。例えば：
m=video 49170/2 RTP/AVP 31
c=IN IP4 233.252.0.1/127/2
would imply that address 233.252.0.1 is used with ports 49170 and 49171, and address 233.252.0.2 is used with ports 49172 and 49173.
アドレス233.252.0.1がポート49170および49171で使用され、アドレス233.252.0.2はポート49172および49173で使用されます。
The mapping is similar if multiple addresses are specified using multiple "c=" lines. For example:
マッピングは、複数の "C ="行を使用して複数のアドレスが指定されている場合も同様です。例えば：
m=video 49170/2 RTP/AVP 31
c=IN IP6 ff00::db8:0:101
c=IN IP6 ff00::db8:0:102
would imply that address ff00::db8:0:101 is used with ports 49170 and 49171, and address ff00::db8:0:102 is used with ports 49172 and 49173.
そのアドレスFF00 :: DB8：0：101は、ポート49170および49171で使用され、アドレスFF00 :: DB8：0：102はポート49172および49173で使用されます。
This document gives no meaning to assigning the same media address to multiple media descriptions. Doing so does not implicitly group those media descriptions in any way. An explicit grouping framework (for example, [RFC5888]) should instead be used to express the intended semantics. For instance, see [RFC8843].
このドキュメントでは、同じメディアアドレスを複数のメディアの説明に割り当てることを意味しません。そうすることで、それらのメディアの説明を暗黙的にまとめることはできません。明示的なグループ化フレームワーク（たとえば、[RFC5888]）は、代わりに意図された意味を表現するために使用されるべきです。たとえば、[RFC8843]を参照してください。
<proto> is the transport protocol. The meaning of the transport protocol is dependent on the address type subfield in the relevant "c=" line. Thus a "c=" line with an address type of "IP4" indicates that the transport protocol runs over IPv4. The following transport protocols are defined, but may be extended through registration of new protocols with IANA (see Section 8):
<Proto>はトランスポートプロトコルです。トランスポートプロトコルの意味は、関連する "C ="行のアドレス型サブフィールドに依存します。したがって、アドレスタイプの「IP4」を持つ "C ="行は、トランスポートプロトコルがIPv4を介して実行されることを示します。次のトランスポートプロトコルは定義されていますが、IANAを使用した新しいプロトコルの登録を通じて拡張される可能性があります（セクション8を参照）。
* udp: denotes that the data is transported directly in UDP with no additional framing.
* UDP：データが追加のフレーミングなしでUDPで直接転送されることを示します。
* RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551] running over UDP.
* RTP / AVP：rtp [rfc3550]は、最小限のコントロールで、UDPを介して実行されている[RFC3551]のRTPプロファイルの下で使用されるRTP [RFC3550]を示します。
* RTP/SAVP: denotes the Secure Real-time Transport Protocol [RFC3711] running over UDP.
* RTP / SAVP：UDPを介して実行されているセキュアリアルタイムトランスポートプロトコル[RFC3711]を示します。
* RTP/SAVPF: denotes SRTP with the Extended SRTP Profile for RTCP-Based Feedback [RFC5124] running over UDP.
* RTP / SAVPF：UDPを介して実行されているRTCPベースのフィードバック[RFC5124]の拡張SRTPプロファイルを持つSRTPを表します。
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 (MBone's popular multimedia audio tool) 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.
メディアフォーマットに加えてトランスポートプロトコルを指定する主な理由は、ネットワークプロトコルが同じであっても同じ標準メディアフォーマットが異なるトランスポートプロトコルを介して伝送される可能性があることです。履歴的な例はVAT（MBoneの一般的なマルチメディアオーディオツール）です。パルスコード変調（PCM）オーディオおよびRTP PCMオーディオ。もう1つはTCP / RTP PCMオーディオである可能性があります。さらに、トランスポートプロトコル固有であるがフォーマットに依存しないリレーと監視ツールが可能です。
<fmt> is a media format description. The fourth and any subsequent subfields describe the format of the media. The interpretation of the media format depends on the value of the <proto> subfield.
<FMT>はメディアフォーマットの説明です。4番目と後続のサブフィールドは、メディアのフォーマットを記述します。メディアフォーマットの解釈は、<Proto>サブフィールドの値によって異なります。
If the <proto> subfield is "RTP/AVP" or "RTP/SAVP", the <fmt> subfields 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, and these payload formats are listed in order of preference, with the first format listed being preferred. When multiple payload formats are listed, the first acceptable payload format from the beginning of the list SHOULD be used for the session. For dynamic payload type assignments, the "a=rtpmap:" attribute (see Section 6.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.15).
<Proto> Subfieldが "RTP / AVP"または "RTP / Savp"の場合、<FMT>サブフィールドにはRTPペイロードタイプ番号が含まれています。ペイロードタイプ番号のリストが与えられると、これはこれらすべてのペイロードフォーマットがセッションで使用される可能性があり、これらのペイロードフォーマットは優先順にリストされており、最初のフォーマットは推奨されています。複数のペイロードフォーマットがリストされている場合は、リストの先頭からの最初の許容ペイロード形式をセッションに使用する必要があります。ダイナミックペイロードタイプの割り当ての場合、 "A = rtpmap："属性（6.6項を参照）を使用して、RTPペイロードタイプ番号からペイロードフォーマットを識別するメディアエンコード名にマッピングする必要があります。"a = fmtp："属性を使用してフォーマットパラメータを指定できます（セクション6.15を参照）。
If the <proto> subfield is "udp", the <fmt> subfields 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> Subfieldが "UDP"の場合、<FMT>サブフィールドは、「オーディオ」、「ビデオ」、「テキスト」、「アプリケーション」、または「メッセージ」最上位メディアの下の形式を記述するメディアタイプを参照する必要があります。タイプ。メディアタイプの登録は、UDPトランスポートで使用するためのパケットフォーマットを定義する必要があります。
For media using other transport protocols, the <fmt> subfield is protocol specific. Rules for interpretation of the <fmt> subfield MUST be defined when registering new protocols (see Section 8.2.2).
他のトランスポートプロトコルを使用しているメディアの場合、<FMT>サブフィールドはプロトコル固有です。<FMT>サブフィールドの解釈の規則は、新しいプロトコルを登録するときに定義する必要があります（セクション8.2.2を参照）。
Section 3 of [RFC4855] states that the payload format (encoding) names defined in the RTP profile are commonly shown in upper case, while media subtype names are commonly shown in lower case. It also states that both of these names are case-insensitive in both places, similar to parameter names which are case-insensitive both in media type strings and in the default mapping to the SDP "a=fmtp:" attribute.
[RFC4855]のセクション3は、RTPプロファイルで定義されているペイロードフォーマット（エンコード）名が大文字で一般的に表示され、メディアサブタイプ名は一般的に小文字で表示されます。また、これらの名前の両方が大文字と小文字が区別されないと、メディアタイプの文字列とSDP "a = fmtp："属性の両方で大文字と小文字が区別されます。
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. Syntax is provided using ABNF [RFC7405] with some of the rules defined further in Section 9.
以下の属性が定義されています。アプリケーション作成者は必要なときに新しい属性を追加する可能性があるため、このリストは網羅的なものではありません。新しい属性の登録手順はセクション8.2.4で定義されています。構文は、セクション9でさらに定義された規則のいくつかでABNF [RFC7405]を使用して提供されます。
Name: cat
名前：猫
Value: cat-value
価値：猫価値
Usage Level: session
使用レベル：セッション
Charset Dependent: no
文字セットに依存する：いいえ
Syntax:
構文：
cat-value = category category = non-ws-string
cat-value =カテゴリカテゴリ=非WS-String
Example:
例：
a=cat:foo.bar
A =猫：foo.bar.
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. This attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored if received.
この属性はセッションのドット区切りの階層カテゴリを与えます。これは、受信側がカテゴリ別に不要なセッションをフィルタリングできるようにすることです。カテゴリの中心的なレジストリはありません。この属性は廃止され、使用しないでください。受信した場合は無視する必要があります。
Name: keywds
名前：keywds.
Value: keywds-value
値：keywds-value.
Usage Level: session
使用レベル：セッション
Charset Dependent: yes
文字セットに依存する：はい
Syntax:
構文：
keywds-value = keywords keywords = text
keywds-value =キーワードキーワード= text.
Example:
例：
a=keywds:SDP session description protocol
A = KeyWDS：SDPセッション説明プロトコル
Like the "a=cat:" attribute, this was intended to assist identifying wanted sessions at the receiver, and to allow a receiver to select interesting sessions based on keywords describing the purpose of the session; however, there is no central registry of keywords. 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. This attribute is obsolete and SHOULD NOT be used. It SHOULD be ignored if received.
"a = cat："属性のように、これは受信機での望みのセッションの識別を支援し、受信側がセッションの目的を説明するキーワードに基づいて興味深いセッションを選択できるようにすることを目的としました。ただし、キーワードの中心的なレジストリはありません。その値は、指定されている場合は、セッション記述に指定された文字セット内で、またはISO 10646 / UTF-8ではデフォルトで解釈されるべきです。この属性は廃止され、使用しないでください。受信した場合は無視する必要があります。
Name: tool
名前：ツール
Value: tool-value
値：ツール値
Usage Level: session
使用レベル：セッション
Charset Dependent: no
文字セットに依存する：いいえ
Syntax:
構文：
tool-value = tool-name-and-version tool-name-and-version = text
tool-value = tool-name-and-version tool-name-and-version =テキスト
Example:
例：
a=tool:foobar V3.2
A =ツール：foobar v3.2
This gives the name and version number of the tool used to create the session description.
これにより、セッション記述の作成に使用されるツールの名前とバージョン番号が得られます。
Name: ptime
名前：Ptime.
Value: ptime-value
値：ptime-value.
Usage Level: media
使用レベル：メディア
Charset Dependent: no
文字セットに依存する：いいえ
Syntax:
構文：
ptime-value = non-zero-int-or-real
Example:
例：
a=ptime:20
a = ptime：20
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 "a=ptime:" to decode RTP or vat audio, and it is intended as a recommendation for the encoding/packetization of audio.
これにより、パケット内のメディアによって表されるミリ秒単位の時間が与えられます。これはおそらく音声データにのみ意味がありますが、それが理にかなっている場合は他のメディアタイプと一緒に使用されることがあります。RTPまたはVATオーディオをデコードするために "A = PTIME："を知る必要はありません。オーディオのエンコード/パケット化の推奨事項として意図されています。
Name: maxptime
名前：Maxptime.
Value: maxptime-value
値：maxptime-value.
Usage Level: media
使用レベル：メディア
Charset Dependent: no
文字セットに依存する：いいえ
Syntax:
構文：
maxptime-value = non-zero-int-or-real
Example:
例：
a=maxptime:20
A = Maxptime：20
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. Note that this attribute was introduced after [RFC2327], and implementations that have not been updated will ignore this attribute.
これにより、各パケットにカプセル化できるメディアの最大量をミリ秒単位で表します。時間は、パケット内に存在するメディアが表す時間の合計として計算されます。フレームベースのコーデックの場合、時間はフレームサイズの整数倍になる必要があります。この属性は、おそらくオーディオデータにとってのみ意味がありますが、それが理にかなっている場合は他のメディアタイプと一緒に使用されることがあります。この属性は[RFC2327]の後に導入され、更新されていない実装はこの属性を無視します。
Name: rtpmap
名前：rtpmap.
Value: rtpmap-value
値：rtpmap-value.
Usage Level: media
使用レベル：メディア
Charset Dependent: no
文字セットに依存する：いいえ
Syntax:
構文：
rtpmap-value = payload-type SP encoding-name "/" clock-rate [ "/" encoding-params ] payload-type = zero-based-integer encoding-name = token clock-rate = integer encoding-params = channels channels = integer
rtpmap-value = payload-type sp encoding-name "/" clock-rate ["/" encoding-params] payload-type =ゼロベースinteger encoding-name =トークンクロックレート= integer encoding-params =チャンネルチャネル=整数
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. Note that the payload type number is indicated in a 7-bit field, limiting the values to inclusively between 0 and 127.
この属性は、使用されるペイロードフォーマットを示す符号化名に、RTPペイロードタイプ番号（「M =」行で使用されている）からマッピングされます。クロックレートとエンコードパラメータに関する情報も提供します。ペイロードタイプ番号は7ビットフィールドに示されており、値を0から127の間で包括的に制限することに注意してください。
Although an RTP profile can 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 encoded single-channel audio sampled at 8 kHz. This is completely defined in the RTP audio/video profile as payload type 0, so there is no need for an "a=rtpmap:" attribute, and the media for such a stream sent to UDP port 49232 can be specified as:
RTPプロファイルはペイロードタイプ番号の静的な割り当てをペイロード形式にすることができますが、その割り当てには「A = RTPMAP：」属性を使用して動的に実行することが一般的です。静的ペイロードタイプの例として、u-law PCMエンコードされたシングルチャンネルオーディオは8 kHzでサンプリングされました。これは、ペイロードタイプ0としてRTPオーディオ/ビデオプロファイルで完全に定義されているので、「a = rtpmap：」属性を必要とせず、UDPポート49232に送信されたそのようなストリームのメディアは次のように指定できます。
m=audio 49232 RTP/AVP 0
M = AUDIO 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ビットリニアエンコードステレオオーディオです。このストリームにDynamic RTP / AVPペイロードタイプ98を使用したい場合は、デコードするために追加情報が必要です。
m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2
Up to one "a=rtpmap:" attribute can be defined for each media format specified. Thus, we might have the following:
指定された各メディアフォーマットに対して、最大1つの「a = 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-params 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-paramsはオーディオチャンネルの数を示します。このパラメータはオプションであり、追加のパラメータが必要とされないという条件で、チャンネル数が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："属性に追加されたパラメータは、セッションディレクトリに必要なものにのみ、セッションに適切なメディアを選択するためのものです。コーデック固有のパラメータは他の属性に追加する必要があります（たとえば、 "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 [RFC3551]) packetization is required, the "a=ptime:" attribute is used as given in Section 6.4.
注：RTPオーディオフォーマットは通常、パケットごとのサンプル数に関する情報を含まない。デフォルト以外の（RTPオーディオ/ビデオプロファイル[RFC3551]）パケット化が必要な場合は、「A = PTIME：」属性がセクション6.4で示すように使用されます。
At most one occurrence of "a=recvonly", "a=sendrecv", "a=sendonly", or "a=inactive" MAY appear at session level, and at most one MAY appear in each media description.
「A = Recvonly」、「A = SendRecv」、「A = SendOnly」、または「A = Inactive」、または「A = Inactive」が発生すると、セッションレベルで表示されることがあり、最大で各メディアの説明に表示されることがあります。
If any one of these appears in a media description, then it applies for that media description. If none appears in a media description, then the one from session level, if any, applies to that media description.
これらのいずれかがメディアの説明に表示されている場合は、そのメディアの説明に適用されます。メディアの説明にnoneが表示されていない場合は、セッションレベルからの1つがあれば、そのメディアの説明に適用されます。
If none of the media direction attributes is present at either session level or media level, "a=sendrecv" SHOULD be assumed as the default.
セッションレベルまたはメディアレベルのいずれかのメディア方向属性が存在しない場合は、デフォルトとして「A = SendRecv」を想定してください。
Within the following SDP example, the "a=sendrecv" attribute applies to the first audio media and the "a=inactive" attribute applies to the others.
次のSDPの例では、 "A = sendRecv"属性が最初のオーディオメディアに適用され、 "a =非アクティブ"属性が他のものに適用されます。
v=0
o=jdoe 3724395000 3724395001 IN IP6 2001:db8::1
s=-
c=IN IP6 2001:db8::1
t=0 0
a=inactive
m=audio 49170 RTP/AVP 0
a=sendrecv
m=audio 49180 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000
Name: recvonly
名前：Revonly.
Value:
値：
Usage Level: session, media
使用レベル：セッション、メディア
Charset Dependent: no
文字セットに依存する：いいえ
Example:
例：
a=recvonly
A = Revonly
This specifies that the tools should be started in receive-only mode where applicable. Note that receive-only mode applies to the media only, not to any associated control protocol. An RTP-based system in receive-only mode MUST still send RTCP packets as described in [RFC3550], Section 6.
これは、該当する場合は受信専用モードでツールを起動する必要があることを指定します。受信専用モードは、関連付けられている制御プロトコルではなく、メディアのみに適用されます。[RFC3550]、セクション6に記載されているように、受信専用モードのRTPベースのシステムがRTCPパケットを送信する必要があります。
Name: sendrecv
名前：SendRecv.
Value:
値：
Usage Level: session, media
使用レベル：セッション、メディア
Charset Dependent: no
文字セットに依存する：いいえ
Example:
例：
a=sendrecv
a = sendrecv
This specifies that the tools should be started in send and receive mode. This is necessary for interactive multimedia conferences with tools that default to receive-only mode.
これは、送信モードでツールを起動する必要があることを指定します。これは、デフォルトの受信専用モードになるツールを使用したインタラクティブマルチメディアカンファレンスに必要です。
Name: sendonly
名前：SendOnly
Value:
値：
Usage Level: session, media
使用レベル：セッション、メディア
Charset Dependent: no
文字セットに依存する：いいえ
Example:
例：
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 in send-only mode and one in receive-vonly mode. Note that send-only mode applies only to the media, and any associated control protocol (e.g., RTCP) SHOULD still be received and processed as normal.
これは、送信専用モードでツールを起動するように指定します。例として、トラフィックソースよりもトラフィック先に異なるユニキャストアドレスを使用する場合があります。そのような場合、2つのメディア記述が使用されていてもよく、送信専用モードでは1つ、1つは受信 - vonlyモードである。送信専用モードはメディアにのみ適用され、任意の関連制御プロトコル（例えば、RTCP）を通常どおりに受信して処理する必要があります。
Name: inactive
名前：非アクティブ
Value:
値：
Usage Level: session, media
使用レベル：セッション、メディア
Charset Dependent: no
文字セットに依存する：いいえ
Example:
例：
a=inactive
a =非アクティブ
This specifies that the tools should be started in inactive mode. This is necessary for interactive multimedia conferences where users can put other users on hold. No media is sent over an inactive media stream. Note that an RTP-based system MUST still send RTCP (if RTCP is used), even if started in inactive mode.
これは、ツールを非アクティブモードで起動するように指定します。これは、ユーザーが他のユーザーを保留にすることができる対話型マルチメディア会議に必要です。非アクティブメディアストリームを介してメディアは送信されません。非アクティブモードで開始されていても、RTPベースのシステムはRTCP（RTCPが使用されている場合）を送信する必要があります。
Name: orient
名前：オリエント
Value: orient-value
値：オリエント値
Usage Level: media
使用レベル：メディア
Charset Dependent: no
文字セットに依存する：いいえ
Syntax:
構文：
orient-value = portrait / landscape / seascape
portrait = %s"portrait"
landscape = %s"landscape"
seascape = %s"seascape"
; NOTE: These names are case-sensitive.
Example:
例：
a=orient:portrait
a =オリエント：肖像画
Normally this is only used for a whiteboard or presentation tool. It specifies the orientation of the workspace on the screen. Permitted values are "portrait", "landscape", and "seascape" (upside-down landscape).
通常これはホワイトボードまたはプレゼンテーションツールにのみ使用されます。画面上のワークスペースの向きを指定します。許可された価値は、「縦」、「風景」、および「海の景観」（逆さまの風景）です。
Name: type
名前：タイプ
Value: type-value
値：type-value.
Usage Level: session
使用レベル：セッション
Charset Dependent: no
文字セットに依存する：いいえ
Syntax:
構文：
type-value = conference-type
conference-type = broadcast / meeting / moderated / test /
H332
broadcast = %s"broadcast"
meeting = %s"meeting"
moderated = %s"moderated"
test = %s"test"
H332 = %s"H332"
; NOTE: These names are case-sensitive.
Example:
例：
a=type:moderated
a = type：緩和されました
This specifies the type of the multimedia conference. Allowed values are "broadcast", "meeting", "moderated", "test", and "H332". These values have implications for other options that are likely to be appropriate:
これはマルチメディア会議の種類を指定します。許容値は「ブロードキャスト」、「会議」、「モデレート」、「テスト」、「H332」です。これらの値は、適切である可能性が高い他のオプションに影響を及ぼします。
* When "a=type:broadcast" is specified, "a=recvonly" is probably appropriate for those connecting.
* "a = type：broadcast"が指定されている場合、 "A = Recvonly"はおそらく接続に適しています。
* When "a=type:meeting" is specified, "a=sendrecv" is likely to be appropriate.
* "a = type：meeting"が指定されている場合は、 "a = sendrecv"が適切である可能性があります。
* "a=type:moderated" suggests the use of a floor control tool and that the media tools be started so as to mute new sites joining the multimedia conference.
* "A = Type：モデレート"は、フロアコントロールツールの使用を提案し、メディアツールはマルチメディア会議に参加する新しいサイトをミュートするように開始されます。
* Specifying "a=type:H332" indicates that this loosely coupled session is part of an H.332 session as defined in the ITU H.332 specification [ITU.H332.1998]. Media tools should be started using "a=recvonly".
* "a = type：h332"の指定は、この疎結合セッションがITU H.332仕様で定義されているH.332セッションの一部であることを示します[ITU.H332.1998]。メディアツールは "A = Recvonly"を使って起動する必要があります。
* Specifying "a=type:test" is suggested as a hint that, unless explicitly requested otherwise, receivers can safely avoid displaying this session description to users.
* 「a = type：test」を指定することは、特に要求されていない限り、受信側がこのセッション記述をユーザに表示させないようにすることができるというヒントとして提案されています。
Name: charset
名前：文字セット
Value: charset-value
値：charset-value.
Usage Level: session
使用レベル：セッション
Charset Dependent: no
文字セットに依存する：いいえ
Syntax:
構文：
charset-value = <defined in [RFC2978]>
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
The charset specified MUST be one of those registered in the IANA Character Sets registry (http://www.iana.org/assignments/character-sets), such as ISO-8859-1. The character set identifier is a string that MUST be compared against identifiers from the "Name" or "Preferred MIME Name" field of the registry using a case-insensitive comparison. If the identifier is not recognized or not supported, all strings that are affected by it SHOULD be regarded as octet strings.
指定された文字セットは、IANA文字セットに登録されているものの1つでなければなりません。文字セットIDは、大文字と小文字を区別しないように、レジストリの「名前」または「優先するMIME名」フィールドから識別子と比較する必要がある文字列です。識別子が認識されていないかサポートされていない場合、その影響を受けるすべての文字列はオクテット文字列と見なされる必要があります。
Charset-dependent fields MUST contain only sequences of bytes that are valid according to the definition of the selected character set. Furthermore, charset-dependent fields MUST NOT contain the bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR).
CharSet依存フィールドには、選択した文字セットの定義に従って有効なバイトのシーケンスのみを含める必要があります。さらに、文字セット依存フィールドには、バイト0x00（NUL）、0x0A（LF）、および0x0D（CR）を含めてはいけません。
Name: sdplang
名前：sdplang
Value: sdplang-value
値：sdplang-value.
Usage Level: session, media
使用レベル：セッション、メディア
Charset Dependent: no
文字セットに依存する：いいえ
Syntax:
構文：
sdplang-value = Language-Tag ; Language-Tag defined in RFC 5646
sdplang-value = language-tag;RFC 5646で定義されている言語タグ
Example:
例：
a=sdplang:fr
a = sdplang：fr
Multiple "a=sdplang:" attributes can be provided either at session or media level if the session description or media use multiple languages.
セッション記述またはメディアが複数の言語を使用する場合は、セッションまたはメディアレベルで複数の "A = SDPLANG："属性を指定できます。
As a session-level attribute, it specifies the language for the session description (not the language of the media). As a media-level attribute, it specifies the language for any media-level SDP information-field associated with that media (again not the language of the media), overriding any "a=sdplang:" attributes specified at session level.
セッションレベル属性として、セッション記述の言語（メディアの言語ではありません）を指定します。メディアレベル属性として、そのメディアに関連付けられているメディアレベルのSDP情報フィールド（メディアの言語ではなく）の言語を指定し、セッションレベルで指定された「A = SDPLANG：」属性をオーバーライドします。
In general, sending session descriptions consisting of multiple languages is discouraged. Instead, multiple session descriptions SHOULD be sent describing the session, one in each language. However, this is not possible with all transport mechanisms, and so multiple "a=sdplang:" attributes are allowed although NOT RECOMMENDED.
一般に、複数の言語からなるセッション記述の送信は推奨されていません。代わりに、複数のセッションの説明をセッションを記述するように送信する必要があります。ただし、これはすべてのトランスポートメカニズムでは不可能です。
The "a=sdplang:" attribute value must be a single language tag [RFC5646]. An "a=sdplang:" attribute SHOULD be specified when a session is distributed with 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.
"a = sdplang："属性値は単一言語タグ[RFC5646]でなければなりません。「a = sdplang：」属性を指定すると、受信者の言語を想定することができない、またはセッションがローカルで想定されたノルムから異なる言語にある場合に、セッションが十分な範囲で分散される場合、またはセッションを指定する必要があります。
Name: lang
名前：Lang
Value: lang-value
値：lang-value.
Usage Level: session, media
使用レベル：セッション、メディア
Charset Dependent: no
文字セットに依存する：いいえ
Syntax:
構文：
lang-value = Language-Tag ; Language-Tag defined in RFC 5646
lang-value = language-tag;RFC 5646で定義されている言語タグ
Example:
例：
a=lang:de
a = lang：デ
Multiple "a=lang:" attributes can be provided either at session or media level if the session or media has capabilities in more than one language, in which case the order of the attributes indicates the order of preference of the various languages in the session or media, from most preferred to least preferred.
セッションまたはメディアに複数の言語で機能がある場合、複数の "A = LANG："属性をセッションまたはメディアレベルで提供できます。その場合、属性の順序はセッション内のさまざまな言語の順位の順序を示します。またはメディア、最も好ましくは好ましくは好ましい。
As a session-level attribute, "a=lang:" specifies a language capability for the session being described. As a media-level attribute, it specifies a language capability for that media, overriding any session-level language(s) specified.
セッションレベル属性として、 "a = lang："は記述されているセッションの言語機能を指定します。メディアレベルの属性として、それはそのメディアの言語機能を指定し、指定されたセッションレベル言語をオーバーライドします。
The "a=lang:" attribute value must be a single [RFC5646] language tag. An "a=lang:" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language of participants cannot be assumed, or where the session has capabilities in languages different from the locally assumed norm.
"A = LANG："属性値は単一の[RFC5646]言語タグでなければなりません。「A = LANG：」属性は、参加者の言語が想定できない地理的境界を横切るのに十分な範囲がある場合、またはセッションがローカルで想定された標準とは異なる言語の機能がある場合に指定する必要があります。
The "a=lang:" attribute is supposed to be used for setting the initial language(s) used in the session. Events during the session may influence which language(s) are used, and the participants are not strictly bound to only use the declared languages.
「a = lang：」属性は、セッションで使用されている初期言語の設定に使用されることになっています。セッション中のイベントはどの言語が使用されているかに影響を与え、参加者は宣言された言語のみを使用するためだけに厳密にバインドされていません。
Most real-time use cases start with just one language used, while other cases involve a range of languages, e.g., an interpreted or subtitled session. When more than one "a=lang:" attribute is specified, the "a=lang:" attribute itself does not provide any information about multiple languages being intended to be used during the session, or if the intention is to only select one of the languages. If needed, a new attribute can be defined and used to indicate such intentions. Without such semantics, it is assumed that for a negotiated session one of the declared languages will be selected and used.
ほとんどのリアルタイムのユースケースは、使用されている1つの言語だけで始まりますが、他のケースはさまざまな言語、例えば解釈または字幕付きセッションを含みます。複数の「a = lang：」属性が指定されている場合、 "A = LANG："属性自体はセッション中に使用されることを意図している複数の言語に関する情報を提供しません。またはその意図が選択されている場合言語。必要に応じて、新しい属性を定義してそのような意図を示すために使用できます。そのような意味ではなく、ネゴシエートされたセッションの場合、宣言された言語の1つが選択され使用されると仮定されます。
Name: framerate
名前：フレームレート
Value: framerate-value
値：Framerate-Value.
Usage Level: media
使用レベル：メディア
Charset Dependent: no
文字セットに依存する：いいえ
Syntax:
構文：
framerate-value = non-zero-int-or-real
Example:
例：
a=framerate:60
A =フレームレート：60
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 are allowed. It is defined only for video media.
これにより、フレーム/秒の最大ビデオフレームレートが得られます。ビデオデータの符号化の推奨として意図されています。分数値の10進表現が許可されています。ビデオメディアのみに定義されています。
Name: quality
名前：品質
Value: quality-value
価値：品質価値
Usage Level: media
使用レベル：メディア
Charset Dependent: no
文字セットに依存する：いいえ
Syntax:
構文：
quality-value = zero-based-integer
Example:
例：
a=quality:10
A =品質：10
This gives a suggestion for the quality of the encoding as an integer value. The intention of the quality attribute for video is to specify a non-default trade-off between frame-rate and still-image quality. For video, the value is in the range 0 to 10, with the following suggested meaning:
これにより、符号化の品質を整数値として提案します。ビデオの品質属性の意図は、フレームレートと静止画の品質の間でデフォルト以外のトレードオフを指定することです。ビデオの場合、値は0から10の範囲です。次のような意味です。
+----+----------------------------------------+
| 10 | the best still-image quality the |
| | compression scheme can give. |
+----+----------------------------------------+
| 5 | the default behavior given no quality |
| | suggestion. |
+----+----------------------------------------+
| 0 | the worst still-image quality the |
| | codec designer thinks is still usable. |
+----+----------------------------------------+
Table 2: Encoding Quality Values
表2：符号化品質値
Name: fmtp
名前：FMTP
Value: fmtp-value
値：fmtp-value.
Usage Level: media
使用レベル：メディア
Charset Dependent: no
文字セットに依存する：いいえ
Syntax:
構文：
fmtp-value = fmt SP format-specific-params
format-specific-params = byte-string
; Notes:
; - The format parameters are media type parameters and
; need to reflect their syntax.
Example:
例：
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
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, semicolon separated, 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によって伝えられ、このフォーマットを使用するメディアツールに変更されるのに必要なパラメータの任意のセットです。この属性のほとんどのインスタンスは各フォーマットに対して許可されています。
The "a=fmtp:" attribute may be used to specify parameters for any protocol and format that defines use of such parameters.
「a = fmtp：」属性は、そのようなパラメータの使用を定義する任意のプロトコルおよびフォーマットのパラメータを指定するために使用され得る。
SDP is frequently used with the Session Initiation Protocol [RFC3261] using the offer/answer model [RFC3264] to agree on parameters for unicast sessions. When used in this manner, the security considerations of those protocols apply.
SDPは、オファー/アンサーモデル[RFC3264]を使用して、セッション開始プロトコル[RFC3261]で頻繁に使用され、ユニキャストセッションのパラメータに同意します。このように使用すると、それらのプロトコルのセキュリティ上の考慮事項が適用されます。
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 and integrity-protected transport protocol from a known and trusted source. Many different transport protocols may be used to distribute session descriptions, and the nature of the authentication and integrity protection 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 to where the media is sent 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 - the endpoint may decide to ask the user whether or not to accept the session.
SDPは、マルチメディアセッションを説明するセッション記述形式です。 SDPメッセージを受信し実行するエンティティは、既知の信頼できるソースから認証された整合性保護されたトランスポートプロトコルによって取得されていない限り、セッションの説明を信頼できないことに注意する必要があります。セッションの説明を分散させるためにさまざまなトランスポートプロトコルを使用することができ、認証および完全性保護の性質はトランスポートごとに異なります。一部のトランスポートでは、セキュリティ機能は展開されていません。セッション記述が信頼できる方法で取得されていない場合、エンドポイントは、他の攻撃の中で受信されたメディアセッションが意図されていない可能性があるため、メディアが送信されている宛先が予想されることがない可能性があるため、エンドポイントを実行する必要があります。 、セッションのパラメータのいずれかが間違っている可能性があるか、メディアセキュリティが危険にさらされる可能性があります。アプリケーションのセキュリティリスクとユーザー設定を考慮して、賢明な決定を下すためのエンドポイント次第です - エンドポイントは、セッションを受け入れるかどうかをユーザーに尋ねることにします。
On receiving a session description over an unauthenticated transport mechanism or from an untrusted party, software parsing the session description should take a few precautions. Similar concerns apply if integrity protection is not in place. 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-authorized 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. Software processing URLs contained in session descriptions should also heed the security considerations identified in [RFC3986].
認証されていないトランスポートメカニズムまたは信頼できないパーティーを介してセッション記述を受信すると、セッションの説明を解析するソフトウェアはいくつかの注意を払う必要があります。整合性保護が整っていない場合も同様の懸念が適用されます。セッションの説明には、受信側システムでソフトウェアを起動するために必要な情報が含まれています。セッション記述を解析するソフトウェアは、マルチメディアセッションに参加するために適切なソフトウェアとして特に構成されている点を除いて、他のソフトウェアを起動できなかった。それは通常、セッション記述の解析には、ユーザーのシステムで、ユーザーのシステムで、最初にそのようなソフトウェアが開始されてユーザーの同意を与えることができることをユーザーのシステムでは、セッションの説明を開始するために不適切と見なされます。したがって、セッションアナウンス、電子メール、セッション招待状、またはWWWページによって到着するセッション記述は、ユーザーが明示的にそのような行動を事前に許可されていない限り、ユーザーを対話型マルチメディアセッションに配信してはなりません。セッションがインタラクティブかどうかを判断するのは必ずしも簡単ではないので、わからないアプリケーションはセッションを対話的にするはずです。セッションの説明に含まれるソフトウェア処理URLは、[RFC3986]で識別されたセキュリティ上の考慮事項も注目されるべきです。
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 behavior for an unknown attribute is to ignore it.
本明細書では、セッション記述の受信者がデフォルトで送信するモードでマルチメディアツールを起動するように通知することができる属性はない。状況によっては、そのような属性を定義することが適切かもしれません。これが完了すると、そのような属性を含むセッション記述を解析するアプリケーションは、それらを無視するか、このセッションを結合することでマルチメディアデータの自動送信になることをユーザーに通知する必要があります。不明な属性のデフォルトの動作は無視することです。
In certain environments, it has become common for intermediary systems to intercept and analyze session descriptions contained within other signaling 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 behaviors 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). The use of some procedures and SDP extensions (e.g., Interactive Connectivity Establishment (ICE) [RFC8445] and ICE-SIP-SDP [RFC8839]) may avoid the need for intermediaries to modify SDP.
特定の環境では、中間システムが他のシグナリングプロトコル内に含まれるセッション記述を傍受し分析するのが一般的になっています。これは、メディアストリームを通過させること、またはトラフィックを選択的にマーク、優先順位を付けることを可能にするために、ファイアウォールの開放穴を含むがこれらに限定されない目的のために行われる。場合によっては、そのような仲介システムは、例えばセッション記述の内容を動的に作成されたNATバインディングと一致させるために、セッション記述を修正することができる。これらの動作は、セッション記述の正確性を確立し、そのような通信セッションを確立するためのそのソースの権限を確立することを可能にするような方法でセッションの説明が伝えられない限り、これらの動作は推奨されない。 SDPそれ自体では、これらのチェックを可能にするのに十分な情報は含まれていません。それらはカプセル化プロトコル（例えば、SIPまたはRTSP）に依存します。いくつかの手順およびSDP拡張（例えば、対話型接続確立（氷）[RFC8445]およびICE-SIP-SDP [RFC8839]）の使用は、SDPを変更する必要性を回避することができる。
SDP MUST NOT be used to convey keying material (e.g., using the "a=crypto:" attribute [RFC4568]) unless it can be guaranteed that the channel over which the SDP is delivered is both private and authenticated.
SDPが配信されているチャネルがプライベートで認証されているチャネルが保証されていない限り、SDPを使用してはいけません（例えば、 "A = crypto："属性[RFC4568]）、SDPを使用しないでください。
One media type registration from [RFC4566] has been updated, as defined below.
以下に定義されているように、[RFC4566]からの1つのメディアタイプ登録が更新されました。
Type name: application
タイプ名：アプリケーション
Subtype name: sdp
サブタイプ名：SDP.
Required parameters: None.
必要なパラメータ：なし。
Optional parameters: None.
オプションのパラメータ：なし。
Encoding considerations: 8-bit text. 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 8866). Arbitrary binary content cannot be directly represented in SDP.
エンコードに関する考慮事項：8ビットテキスト。SDPファイルは、主にUTF-8形式のテキストです。"a = charset："属性を使用して、SDPファイルの特定の部分で他の文字セットの存在を通知することができます（RFC 8866のセクション6を参照）。任意のバイナリコンテンツを直接SDPで表現することはできません。
Security considerations: See Section 7 of RFC 8866.
セキュリティ上の考慮事項：RFC 8866のセクション7を参照してください。
Interoperability considerations: See RFC 8866.
相互運用性の考慮事項：RFC 8866を参照してください。
Published specification: See RFC 8866.
公開仕様：RFC 8866を参照してください。
Applications which use this media type: Voice over IP, video teleconferencing, streaming media, instant messaging, among others. See also Section 3 of RFC 8866.
このメディアタイプを使用するアプリケーション：Voice over IP、ビデオテレビ会議、ストリーミングメディア、インスタントメッセージング。RFC 8866のセクション3も参照してください。
Fragment identifier considerations: None
フラグメント識別子の考慮事項：なし
Additional information:
追加情報：
Deprecated alias names for this type: N/A
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: IETF MMUSIC working group <mmusic@ietf.org>
追加情報については、お問い合わせ先：IETF MMUSICワーキンググループ<mmusic@ietf.org>
Intended usage: COMMON
意図された使用法：一般的な
Restrictions on usage: None
使用制限：なし
Author/Change controller: Authors of RFC 8866 IETF MMUSIC working group delegated from the IESG
作者/変更コントローラー：RFC 8866 IETF MMUSIC WORKIC WORKICグループの作成者
This document specifies IANA parameter registries for six named SDP subfields. Using the terminology in the SDP specification Augmented Backus-Naur Form (ABNF), they are <media>, <proto>, <attribute-name>, <bwtype>, <nettype>, and <addrtype>.
このドキュメントは、6つのSDPサブフィールドの6つのIANAパラメータレジストリを指定します。SDP仕様拡張Backus-Naur形式（ABNF）の用語を使用して、それらは<Media>、<Proto>、<attribute-name>、<bwtype>、<nettype>、および<addrtype>です。
This document also replaces and updates the definitions of all those parameters previously defined by [RFC4566].
このドキュメントはまた、[RFC4566]によって以前に定義されたすべてのパラメータの定義を置き換えて更新します。
IANA has changed all references to RFC 4566 in these registries to instead refer to this document.
これらのレジストリのRFC 4566へのすべての参照を代わりにこの文書を参照してください。
The contact name and email address for all parameters registered in this document is:
このドキュメントに登録されているすべてのパラメータの連絡先名と電子メールアドレスは次のとおりです。
The IETF MMUSIC working group <mmusic@ietf.org> or its successor as designated by the IESG.
IESGによって指定されたIETF MMUSICワーキンググループ<mmusic@ietf.org>またはその後継者。
All of these registries have a common format:
これらすべてのレジストリには共通のフォーマットがあります。
+======+==========+================+===========+
| Type | SDP Name | [other fields] | Reference |
+======+==========+================+===========+
Table 3: Common Format for SDP Registries
表3：SDPレジストリの共通フォーマット
A specification document that defines values for SDP <media>, <proto>, <attribute-name>, <bwtype>, <nettype>, and <addrtype> parameters MUST include the following information:
SDP <Media>、<Proto>、<attribute-name-name-name-name-name>、<bwtype>、<nettype>、および<addrtype>パラメータの値を定義する仕様書は、次の情報を含める必要があります。
* Contact name
* 連絡先
* Contact email address
* 連絡先メールアドレス
* Name being defined (as it will appear in SDP)
* 定義されている名前（SDPに表示されます）
* Type of name (<media>, <proto>, <attribute-name>, <bwtype>, <nettype>, or <addrtype>)
* 名前の種類（<メディア>、<PROTO>、<attribute-name>、<bwtype>、<netType>、<addrtype>）
* A description of the purpose of the defined name
* 定義された名前の目的の説明
* A stable reference to the document containing this information and the definition of the value. (This will typically be an RFC number.)
* この情報を含む文書と値の定義を厳守します。（これは通常RFC番号です。）
The subsections below specify what other information (if any) must be specified for particular parameters, and what other fields are to be included in the registry.
以下のサブセクションでは、特定のパラメータについて他の情報（存在する場合）を指定する必要があるのか、およびその他のフィールドをレジストリに含める必要があるものを指定します。
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 well as for top-level media types, and where possible the same name should be registered for SDP as for MIME. For media other than existing top-level media types, a Standards Track RFC MUST be produced for a new top-level media type to be registered, and the registration MUST provide good justification why no existing media name is appropriate (the "Standards Action" policy of [RFC8126]).
一連のメディアタイプは小さくなるように意図されており、まれな状況下では拡張されるべきではありません。同じ規則は、メディア名と最上位のメディアタイプに対しても適用されるべきであり、可能であれば同じ名前をMIMEに関してSDPに登録する必要があります。既存の最上位メディアタイプ以外のメディアの場合、標準トラックRFCは登録されるべき新しい最上位メディアタイプに対して作成されなければならず、登録は既存のメディア名が適切でない理由（「標準アクション」である理由で登録を提供する必要があります。[RFC8126]のポリシー）。
This memo registers the media types "audio", "video", "text", "application", and "message".
このメモは、メディアタイプ「オーディオ」、「ビデオ」、「テキスト」、「アプリケーション」、「メッセージ」を登録します。
Note: The media types "control" and "data" were listed as valid in an early version of this specification [RFC2327]; 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 [RFC3840]. 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 [RFC3840]). Also note that [RFC6466] defined the "image" media type.
注：「コントロール」および「データ」は、この仕様の初期バージョンで有効なものとしてリストされています[RFC2327]。しかし、彼らの意味論は完全には指定されていませんでした、そしてそれらは広く使われていません。これらのメディアタイプはこの仕様で削除されていますが、[RFC3840]で定義されているSIPユーザーエージェントの有効なメディアタイプ機能のままです。これらのメディアタイプが将来有用であると見なされる場合、標準トラックRFCはそれらの使用を文書化するために作成されなければなりません。それが完了するまで、アプリケーションはこれらのタイプを使用しないでください。[RFC6466]は「イメージ」メディアタイプを定義しています。
The <proto> subfield describes the transport protocol used. The registration procedure for this registry is "RFC Required".
<Proto>サブフィールドは、使用されるトランスポートプロトコルを表します。このレジストリの登録手順は "RFC必須"です。
This document registers two values:
このドキュメントは2つの値を登録します。
* "RTP/AVP" is a reference to [RFC3550] used under the RTP Profile for Audio and Video Conferences with Minimal Control [RFC3551] running over UDP/IP.
* "RTP / AVP"は、最小限のコントロール[RFC3551]を介してUDP / IPを介して実行されているオーディオおよびビデオ会議のRTPプロファイルで使用される[RFC3550]への参照です。
* "udp" indicates direct use of UDP.
* "UDP"はUDPの直接使用を示します。
New transport protocols MAY be defined, and MUST 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. The RFC defining a new protocol MUST define the rules by which the <fmt> (see below) namespace is managed.
新しいトランスポートプロトコルを定義することができ、IANAに登録する必要があります。登録はプロトコルを記述するRFCを参照する必要があります。そのようなRFCは実験的または情報であり得るが、それは標準的な軌跡であることが好ましい。新しいプロトコルを定義するRFCは、<fmt>（下記参照）名前空間が管理される規則を定義する必要があります。
<proto> names starting with "RTP/" MUST only be used for defining transport protocols that are profiles of RTP. For example, a profile whose short name is "XYZ" would be denoted by a <proto> subfield of "RTP/XYZ".
<Proto> "RTP /"で始まる名前は、RTPのプロファイルであるトランスポートプロトコルを定義するためにのみ使用する必要があります。たとえば、短い名前が "XYZ"のプロファイルは "RTP / XYZ"の<Proto>サブフィールドで表されます。
Each transport protocol, defined by the <proto> subfield, has an associated <fmt> namespace that describes the media formats that may be conveyed by that protocol. Formats cover all the possible encodings that could be transported in a multimedia session.
<Proto> Subfieldによって定義された各トランスポートプロトコルは、そのプロトコルによって伝達され得るメディアフォーマットを記述する関連<FMT>ネームスペースを有する。フォーマットは、マルチメディアセッションで転送可能なすべての可能なエンコーディングをカバーします。
RTP payload formats under the "RTP/AVP" and other "RTP/*" 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 "a=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 / *"プロファイルの下のRTPペイロードフォーマットは、ペイロードタイプ番号を<fmt>値として使用する必要があります。ペイロードタイプ番号がこのセッション記述によって動的に割り当てられている場合、ペイロード形式のメディアタイプ登録で定義されているフォーマット名とパラメータを指定するには、追加の "A = rtpmap："属性を含める必要があります。SDPトランスポートプロトコルとして登録されている（RTPと組み合わせて）登録されている他のRTPプロファイルは、<FMT>ネームスペースの同じ規則を指定することをお勧めします。
For the "udp" protocol, the allowed <fmt> values are media subtypes from the IANA Media Types registry. The media type and subtype combination <media>/<fmt> specifies the format of the body of UDP packets. Use of an existing media subtype for the format is encouraged. If no suitable media subtype exists, it is RECOMMENDED that a new one be registered through the IETF process [RFC6838] by production of, or reference to, a Standards Track RFC that defines the format.
"UDP"プロトコルの場合、許可された<fmt>値はIANAメディアタイプレジストリからのメディアサブタイプです。メディアタイプとサブタイプの組み合わせ<media> / <fmt>は、UDPパケットの本文のフォーマットを指定します。フォーマットの既存のメディアサブタイプの使用は奨励されています。適切なメディアサブタイプが存在しない場合は、フォーマットを定義する標準トラックRFCの作成または参照によって、IETFプロセス[RFC6838]を介して新しいものを登録することをお勧めします。
For other protocols, formats MAY be registered according to the rules of the associated <proto> specification.
他のプロトコルでは、関連付けられている<Proto>仕様の規則に従ってフォーマットが登録されてもよい。
Registrations of new formats MUST specify which transport protocols they apply to.
新しいフォーマットの登録は、どのトランスポートプロトコルを適用するかを指定する必要があります。
Attribute-field names (<attribute-name>) MUST be registered with IANA and documented to avoid any issues due to conflicting attribute definitions under the same name. (While unknown attributes in SDP are simply ignored, conflicting ones that fragment the protocol are a serious problem.)
属性フィールド名（<attribute-name>）はIANAに登録され、同じ名前の属性定義の競合のために問題を回避するように文書化されています。（SDPの不明な属性は単に無視されますが、プロトコルをフラグメント化する矛盾するものは深刻な問題です。）
The format of the <attribute-name> registry is:
<attribute-name>レジストリの形式は次のとおりです。
+======+==========+=============+==============+===========+
| Type | SDP Name | Usage Level | Mux Category | Reference |
+======+==========+=============+==============+===========+
Table 4: Format of the <attribute-name> Registry
For example, the attribute "a=lang:", which is defined for both session and media level, will be listed in the new registry as follows:
たとえば、セッションレベルとメディアレベルの両方に定義されている属性 "a = lang："は次のように新しいレジストリにリストされます。
+===========+==========+================+==============+===========+
| Type | SDP Name | Usage Level | Mux Category | Reference |
+===========+==========+================+==============+===========+
| attribute | lang | session, media | TRANSPORT | [RFC8866] |
| | | | | [RFC8859] |
+-----------+----------+----------------+--------------+-----------+
Table 5: <attribute-name> Registry Example
This one <attribute-name> registry combines all of the previous usage-level-specific "att-field" registries, including updates made by [RFC8859], and renames the "att-field" registry to the "attribute-name (formerly "att-field")" registry. IANA has completed the necessary reformatting.
この1つの<attribute-name>レジストリは、[RFC8859]によって作成された更新プログラムを含む、以前のすべての使用量固有の「ATT-FIELD」レジストリを組み合わせ、「att-field」レジストリを "属性名（以前）に変更します。"Att-Field"） "レジストリ。IANAは必要な再フォーマットを完了しました。
Section 6 of this document replaces the initial set of attribute definitions made by [RFC4566]. IANA has updated the registry accordingly.
この文書の第6章は、[RFC4566]によって行われた属性定義の初期セットを置き換えます。それに応じてレジストリを更新しました。
Documents can define new attributes and can also extend the definitions of previously defined attributes.
文書は新しい属性を定義することができ、以前に定義された属性の定義を拡張することもできます。
New attribute registrations are accepted according to the "Specification Required" policy of [RFC8126], provided that the specification includes the following information:
この仕様には、次の情報が含まれていれば、[RFC8126]の「指定必須」ポリシーに従って新しい属性登録が受け付けられます。
* Contact name
* 連絡先
* Contact email address
* 連絡先メールアドレス
* Attribute name: the name of the attribute that will appear in SDP. This MUST conform to the definition of <attribute-name>.
* 属性名：SDPに表示される属性の名前。これは<attribute-name>の定義に準拠している必要があります。
* Attribute syntax: for a value attribute (see Section 5.13), an ABNF definition of the attribute value <attribute-value> syntax (see Section 9) MUST be provided. The syntax MUST follow the rule form per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL define the allowable values that the attribute might take. It MAY also define an extension method for the addition of future values. For a property attribute, the ABNF definition is omitted as the property attribute takes no values.
* 属性構文：VALUE属性（セクション5.13を参照）は、属性値<属性値>構文（セクション9を参照）のABNF定義を提供する必要があります。構文は、[RFC5234]および[RFC7405]のセクション2.2の規則形式に従う必要があります。これは、属性がかかる可能性がある許容値を定義します。将来の値を追加するための拡張方法を定義することもできます。プロパティ属性の場合、PROPERTY属性が値を取らないため、ABNF定義は省略されます。
* Attribute semantics: for a value attribute, a semantic description of the values that the attribute might take MUST be provided. The usage of a property attribute is described under Purpose below.
* 属性セマンティクス：value属性の場合、属性がかかる可能性がある値の意味の説明を提供する必要があります。プロパティ属性の使用方法は、以下の目的で説明されています。
* Attribute value: the name of an ABNF syntax rule defining the syntax of the value. Absence of a rule name indicates that the attribute takes no values. Enclosing the rule name in "[" and "]" indicates that a value is optional.
* 属性値：値の構文を定義するABNF構文ルールの名前。ルール名がないことは、属性が値を取らないことを示します。ルール名を "["と "]]で囲むことは、値がオプションであることを示します。
* Usage level: the usage level(s) of the attribute. This MUST be one or more of the following: session, media, source, dcsa, and dcsa(subprotocol). For a definition of source-level attributes, see [RFC5576]. For a definition of dcsa attributes see [RFC8864].
* 使用量レベル：属性の使用量レベル。これは、セッション、メディア、ソース、DCSA、およびDCSA（サブプロトコル）のうちの1つ以上でなければなりません。ソースレベルの属性の定義については、[RFC5576]を参照してください。DCSA属性の定義については、[RFC8864]を参照してください。
* Charset dependent: this MUST be "Yes" or "No" depending on whether the attribute value is subject to the "a=charset:" attribute.
* 文字セットに依存する：属性値が "a = charset："属性のどちらに従うかどうかに応じて "yes"または "no"でなければなりません。
* Purpose: an explanation of the purpose and usage of the attribute.
* 目的：属性の目的と使用方法の説明。
* O/A procedures: offer/answer procedures as explained in [RFC3264].
* O / A手順：[RFC3264]で説明したオファー/アンサー・プロシージャー。
* Mux Category: this MUST indicate one of the following categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT, INHERIT, IDENTICAL-PER-PT, SPECIAL, or TBD as defined by [RFC8859].
* MUXカテゴリ：これは、通常、推奨、同一、合計、トランスポート、継承、同一、PT、特殊、または[RFC8859]で定義されているようなTBDのいずれかを示している必要があります。
* Reference: a reference to the specification defining the attribute.
* 参照：属性を定義する仕様への参照。
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で文書化されるべきです。
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属性の精神にあることを確認する必要があります。これは、属性がオペレーティングシステムについての暗黙の仮定をしないという意味でプラットフォームであり、抑制される可能性のある方法で特定のソフトウェアをネームにしないという意味でプラットフォームであることを確認する必要があります。相互運用性
Submitters of registrations should also carefully choose the attribute usage level. They should not choose only "session" when the attribute can have different values when media is disaggregated, i.e., when each "m=" section has its own IP address on a different endpoint. In that case, the attribute type chosen should be "session, media" or "media" (depending on desired semantics). The default rule is that for all new SDP attributes that can occur both in session and media level, the media level overrides the session level. When this is not the case for a new SDP attribute, it MUST be explicitly stated.
登録の送信者も属性の使用量レベルを慎重に選択する必要があります。メディアが分解されたとき、すなわち各 "M ="セクションが異なるエンドポイントに独自のIPアドレスを持っているときに、属性が異なる値を持つことができる場合、それらは「セッション」のみを選択しないでください。その場合、選択された属性タイプは、「セッション、メディア」、または「メディア」（望ましいセマンティクスに応じて）である必要があります。デフォルトのルールは、セッションレベルとメディアレベルの両方で発生する可能性があるすべての新しいSDP属性に対して、メディアレベルがセッションレベルを上書きします。これが新しいSDP属性の場合ではない場合は、明示的に記載されている必要があります。
IANA has registered the initial set of attribute names (<attribute-name> values) with definitions as in Section 6 of this memo (these definitions replace those in [RFC4566]).
IANAは、このメモのセクション6のように定義に属性名の初期セット（<attribute-name>値）を登録しました（これらの定義は[RFC4566]のものを置き換えます）。
Updated attribute registrations are accepted according to the "Specification Required" policy of [RFC8126].
更新された属性登録は、[RFC8126]の「仕様必要な」ポリシーに従って受け入れられます。
The Designated Expert reviewing the update is requested to evaluate whether the update is compatible with the prior intent and use of the attribute, and whether the new document is of sufficient maturity and authority in relation to the prior document.
更新されたエキスパートレビューは、更新が事前の意図と属性の使用と互換性があるかどうか、および新しい文書が以前の文書に関連して十分な成熟度と権限のどちらに互換性があるかどうかを評価するように要求されます。
The specification updating the attribute (for example, by adding a new value) MUST update registration information items from Section 8.2.4.1 according to the following constraints:
属性の更新（たとえば、新しい値を追加することによって）は、次の制約に従って、セクション8.2.4.1から登録情報を更新する必要があります。
* Contact name: a name for an entity responsible for the update MUST be provided.
* 連絡先名：アップデートの責任を負うエンティティの名前を提供する必要があります。
* Contact email address: an email address for an entity responsible for the update MUST be provided.
* 連絡先電子メールアドレス：アップデートを担当するエンティティの電子メールアドレスを提供する必要があります。
* Attribute name: MUST be provided and MUST NOT be changed. Otherwise it is a new attribute.
* 属性名：指定する必要があり、変更しないでください。それ以外の場合は新しい属性です。
* Attribute syntax: the existing rule syntax with the syntax extensions MUST be provided if there is a change to the syntax. A revision to an existing attribute usage MAY extend the syntax of an attribute, but MUST be backward compatible.
* 属性構文：構文に変更がある場合は、構文拡張機能を持つ既存のルール構文を提供する必要があります。既存の属性使用法に対するリビジョンは、属性の構文を拡張することができますが、下位互換性がある必要があります。
* Attribute semantics: a semantic description of new additional attribute values or a semantic extension of existing values. Existing attribute values semantics MUST only be extended in a backward compatible manner.
* 属性セマンティクス：新しい追加の属性値の意味論または既存の値の意味的拡張。既存の属性値セマンティクスは、下位互換性のある方法でのみ拡張する必要があります。
* Usage level: updates MAY only add additional levels.
* 使用レベル：アップデートは追加のレベルのみを追加することができます。
* Charset dependent: MUST NOT be changed.
* 文字セットに依存する：変更しないでください。
* Purpose: MAY be extended according to the updated usage.
* 目的：更新された使用法に従って拡張することができます。
* O/A procedures: MAY be updated in a backward compatible manner and/or it applies to a new usage level only.
* O / A手順：後方互換性のある方法で更新することができ、および/またはそれは新しい使用レベルのみに適用されます。
* Mux Category: no change unless from "TBD" to another value (see [RFC8859]. It MAY also change if media level is being added to the definition of an attribute that previously did not include it.
* MUXカテゴリ： "TBD"から別の値に変更されない限り、変更なし（RFC8859を参照してください。メディアレベルが以前に含めなかった属性の定義に追加されている場合は、変更される可能性があります。
* Reference: a new (additional or replacement) reference MUST be provided.
* 参照：新しい（追加または交換）参照を提供する必要があります。
Items SHOULD be omitted if there is no impact to them as a result of the attribute update.
属性更新の結果として、それらに影響がない場合は項目を省略してください。
A proliferation of bandwidth specifiers is strongly discouraged.
帯域幅指定子の急増は強く推奨されています。
New bandwidth specifiers (<bwtype> subfield values) 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を参照しなければならず、既存の登録帯域幅指定子が十分ではない理由を示しています。
The RFC MUST specify the Mux Category for this value as defined by [RFC8859].
RFCは、[RFC8859]で定義されているように、この値のMUXカテゴリを指定する必要があります。
The format of the <bwtype> registry is:
<BWType>レジストリの形式は次のとおりです。
+======+==========+==============+===========+
| Type | SDP Name | Mux Category | Reference |
+======+==========+==============+===========+
Table 6: Format of the <bwtype> Registry
IANA has updated the <bwtype> registry entries for the bandwidth specifiers "CT" and "AS" with the definitions in Section 5.8 of this memo (these definitions replace those in [RFC4566]).
IANAは、このメモのセクション5.8の定義を持つ帯域幅指定子、および「AS」の<BWType>レジストリエントリを更新しました（これらの定義は[RFC4566]で置き換えます）。
Network type "IN", representing the Internet, is defined in Section 5.2 and Section 5.7 of this memo (this definition replaces that in [RFC4566]).
インターネットを表すネットワークタイプは、このメモのセクション5.2とセクション5.7で定義されています（この定義は[RFC4566]で置き換えます）。
To enable SDP to reference a new non-Internet environment, a new network type (<nettype> subfield value) MUST be registered with IANA. The registration is subject to the "RFC Required" policy of [RFC8126]. Although non-Internet environments 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 registration MUST reference an RFC that gives details of the network type and the address type(s) that may be used with it.
SDPが新しいインターネット非インターネット環境を参照できるようにするには、新しいネットワークタイプ（<NetType>サブフィールド値）をIANAに登録する必要があります。登録は「RFC 8126」の「RFC必須」ポリシーの対象となります。非インターネット環境は通常IANAの保存ではありませんが、インターネットアプリケーションがインターネットアプリケーションで非インターネットアプリケーションと相互運用する必要がある場合は、公衆交換電話ネットワーク（PSTN）に入るときなどです。ネットワークタイプの数は小さく、めったに延長されるべきです。新しいネットワークタイプの登録は、ネットワークタイプの詳細とそれと共に使用され得るアドレスタイプを提供するRFCを参照する必要があります。
The format of the <nettype> registry is:
<NetType>レジストリの形式は次のとおりです。
+======+==========+========================+===========+
| Type | SDP Name | Usable addrtype Values | Reference |
+======+==========+========================+===========+
Table 7: Format of the <nettype> Registry
IANA has updated the <nettype> registry to this new format. The following is the updated content of the registry:
IANAはこの新しい形式で<NetType>レジストリを更新しました。以下は、レジストリの更新された内容です。
+=========+==========+========================+===========+
| Type | SDP Name | Usable addrtype Values | Reference |
+=========+==========+========================+===========+
| nettype | IN | IP4, IP6 | [RFC8866] |
+---------+----------+------------------------+-----------+
| nettype | TN | RFC2543 | [RFC2848] |
+---------+----------+------------------------+-----------+
| nettype | ATM | NSAP, GWID, E164 | [RFC3108] |
+---------+----------+------------------------+-----------+
| nettype | PSTN | E164 | [RFC7195] |
+---------+----------+------------------------+-----------+
Table 8: Content of the <nettype> registry
Note that both [RFC7195] and [RFC3108] registered "E164" as an address type, although [RFC7195] mentions that the "E164" address type has a different context for ATM and PSTN networks.
[RFC7195]と[RFC3108]の両方がアドレスタイプとして「E164」を登録したが、「E164」アドレスタイプはATMおよびPSTNネットワークのコンテキストが異なることを示している。
New address types (<addrtype>) MUST be registered with IANA. The registration is subject to the "RFC Required" policy of [RFC8126]. 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 8126」の「RFC必須」ポリシーの対象となります。新しいアドレスタイプ登録はRFCを参照しなければならず、アドレスタイプの構文の詳細を示します。アドレスタイプは頻繁に登録されることが期待されていません。
Section 5.7 of this document gives new definitions of address types "IP4" and "IP6".
このドキュメントのセクション5.7は、アドレスタイプ "IP4"と "IP6"の新しい定義を提供します。
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 [RFC5234] and [RFC7405].
このセクションでは、SDPのための拡張BNF文法を提供します。ABNFは[RFC5234]と[RFC7405]で定義されています。
; SDP Syntax
session-description = version-field
origin-field
session-name-field
[information-field]
[uri-field]
*email-field
*phone-field
[connection-field]
*bandwidth-field
1*time-description
[key-field]
*attribute-field
*media-description
version-field = %s"v" "=" 1*DIGIT CRLF
;this memo describes version 0
origin-field = %s"o" "=" username SP sess-id SP sess-version SP
nettype SP addrtype SP unicast-address CRLF
session-name-field = %s"s" "=" text CRLF
information-field = %s"i" "=" text CRLF
uri-field = %s"u" "=" uri CRLF
email-field = %s"e" "=" email-address CRLF
phone-field = %s"p" "=" phone-number CRLF
connection-field = %s"c" "=" nettype SP addrtype SP
connection-address CRLF
;a connection field must be present
;in every media description or at the
;session level
bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF
time-description = time-field [repeat-description]
time-description = time-field [繰り返し説明]
repeat-description = 1*repeat-field
[zone-field]
time-field = %s"t" "=" start-time SP stop-time CRLF
repeat-field = %s"r" "=" repeat-interval SP typed-time
1*(SP typed-time) CRLF
zone-field = %s"z" "=" time SP ["-"] typed-time
*(SP time SP ["-"] typed-time) CRLF
key-field = %s"k" "=" key-type CRLF
attribute-field = %s"a" "=" attribute CRLF
media-description = media-field [information-field] *connection-field *bandwidth-field [key-field] *attribute-field
メディア説明= Media-Field [Information-Field] * connection-field * andwidth-field [key-field] *属性フィールド
media-field = %s"m" "=" 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 =トークン;通常 "in"
addrtype = token ;typically "IP4" or "IP6"
addRtype =トークン。通常 "IP4"または "IP6"
; sub-rules of 'u=' uri = URI-reference ; see RFC 3986
;'u =' uri = URI参照のサブルール;RFC 3986を参照してください
; sub-rules of 'e=', see RFC 5322 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 =トークンのサブルール
bandwidth = 1*DIGIT
; sub-rules of 't='
start-time = time / "0"
stop-time = time / "0"
停止時間=時間/ "0"
time = POS-DIGIT 9*DIGIT
; Decimal representation of time in
; seconds since January 1, 1900 UTC.
; The representation is an unbounded
; length field containing at least
; 10 digits. Unlike some representations
; 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 = %s"d" / %s"h" / %s"m" / %s"s"
; NOTE: These units are case-sensitive.
; sub-rules of 'k='
key-type = %s"prompt" /
%s"clear:" text /
%s"base64:" base64 /
%s"uri:" uri
; NOTE: These names are case-sensitive.
base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = 2base64-char "==" / 3base64-char "="
base64-char = ALPHA / DIGIT / "+" / "/"
; sub-rules of 'a='
attribute = (attribute-name ":" attribute-value) /
attribute-name
attribute-name = token
attribute-value = byte-string
att-field = attribute-name ; for backward compatibility
att-field = attribute-name。下位互換性のために
; sub-rules of 'm='
media = token
;typically "audio", "video", "text", "image"
;or "application"
fmt = token ;typically an RTP payload type for audio ;and video media
FMT =トークン。通常、オーディオ用のRTPペイロードタイプ。ビデオメディア
proto = token *("/" token)
;typically "RTP/AVP", "RTP/SAVP", "udp",
;or "RTP/SAVPF"
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 [ "/" numaddr ]
; IP4 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 = IP6-address [ "/" numaddr ] ; IP6 address starting with FF
ip6-multicast = ip6-address ["/" numaddr];FF以降のIP6アドレス
numaddr = integer
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-UCHAR）
b1 = decimal-uchar ; less than "224"
B1 = 10進uchar;「224」未満
IP6-address = 6( h16 ":" ) ls32
/ "::" 5( h16 ":" ) ls32
/ [ h16 ] "::" 4( h16 ":" ) ls32
/ [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32
/ [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32
/ [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32
/ [ *4( h16 ":" ) h16 ] "::" ls32
/ [ *5( h16 ":" ) h16 ] "::" h16
/ [ *6( h16 ":" ) h16 ] "::"
h16 = 1*4HEXDIG
ls32 = ( h16 ":" h16 ) / IP4-address
; Generic for other address families extn-addr = non-ws-string
;他のアドレスファミリの一般的なextn-addr =非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 = ALPHA / DIGIT
/ "!" / "#" / "$" / "%" / "&"
/ "'" ; (single quote)
/ "*" / "+" / "-" / "." / "^" / "_"
/ "`" ; (Grave accent)
/ "{" / "|" / "}" / "~"
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
integer = POS-Digit * Digit
zero-based-integer = "0" / integer
ゼロベースinteger = "0" /整数
non-zero-int-or-real = integer / non-zero-real
non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT
ゼロ以外の実数=ゼロベース整数 "。"*桁POS-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 = <ALPHA definition from RFC 5234>
DIGIT = <DIGIT definition from RFC 5234>
CRLF = <CRLF definition from RFC 5234>
HEXDIG = <HEXDIG definition from RFC 5234>
SP = <SP definition from RFC 5234>
VCHAR = <VCHAR definition from RFC 5234>
URI-reference = <URI-reference definition from RFC 3986>
addr-spec = <addr-spec definition from RFC 5322>
* Generally clarified and refined terminology. Aligned terms used in text with the ABNF. The terms <attribute>, <att-field>, and "att-field" are now <attribute-name>. The terms <value> and <att-value> are now <attribute-value>. The term "media" is now <media>.
* 一般的に明らかにされ、精製された用語。ABNFとテキストで使用されている整列用語。<attribute>、<att-field>、および "att-field"という用語は<attribute-name>です。<value>と<att-value>という用語は<属性値>です。「メディア」という用語は<メディア>です。
* Identified now-obsolete items: "a=cat:" (Section 6.1), "a=keywds:" (Section 6.2), and "k=" (Section 5.12).
* 現在時代遅れの項目： "A = cat："（6.1節）、 "A = keywds："（セクション6.2）、および "k ="（5.12節）。
* Updated normative and informative references, and added references to additional relevant related RFCs.
* 規範的および有益な参照を更新し、追加の関連するRFCへの参照を追加しました。
* Reformatted the SDP Attributes section (Section 6) for readability. The syntax of attribute values is now given in ABNF.
* 読みやすさのためにSDP属性セクション（セクション6）を再フォーマットしました。属性値の構文がABNFで与えられます。
* Made mandatory the sending of RTCP with inactive media streams (Section 6.7.4).
* 非アクティブメディアストリームを使用してRTCPの送信を必須にしました（6.7.4項）。
* Removed the section "Private Sessions". That section dated back to a time when the primary use of SDP was with SAP (Session Announcement Protocol), which has fallen out of use. Now the vast majority of uses of SDP is for establishment of private sessions. The considerations for that are covered in Section 7.
* 「プライベートセッション」のセクションを削除しました。そのセクションは、SDPの主な使用がSAP（セッションアナウンスプロトコル）であった時点まで、使用不能になった。現在、SDPの使用量の大多数は、個人セッションを確立するためのものです。そのための考慮事項はセクション7で説明されています。
* Expanded and clarified the specification of the "a=lang:" (Section 6.12) and "a=sdplang:" (Section 6.11) attributes.
* 「A = LANG：」（セクション6.12）および「A = SDPLANG：」（セクション6.11）の指定を展開して明確にした。
* Removed some references to SAP because it is no longer in widespread use.
* 広範囲に使用されていないため、SAPへの参照を削除しました。
* Changed the way <fmt> values for UDP transport are registered (Section 8.2.3).
* UDPトランスポートの<FMT>値を登録する方法を変更しました（セクション8.2.3）。
* Changed the mechanism and documentation required for registering new attributes (Section 8.2.4.1).
* 新しい属性の登録に必要なメカニズムとドキュメントを変更しました（セクション8.2.4.1）。
* Tightened up IANA registration procedures for extensions. Removed phone number and long-form name (Section 8.2).
* 拡張のためにIANA登録手順を締め付けた。電話番号とロングフォーム名を削除しました（セクション8.2）。
* Expanded the IANA <nettype> registry to identify valid <addrtype> subfields (Section 8.2.6).
* 有効な<AddRType>サブフィールドを識別するためにIANA <NetType>レジストリを展開しました（セクション8.2.6）。
* Reorganized the several IANA "att-field" registries into a single <attribute-name> registry (Section 8.2.4).
* いくつかのIANA "ATT-FIELD"レジストリを単一の<attribute-name>レジストリに再編成しました（セクション8.2.4）。
* Revised ABNF syntax (Section 9) for clarity and for alignment with text. Backward compatibility is maintained with a few exceptions. Of particular note:
* 明確にし、テキストとの位置合わせのためのABNF構文（セクション9）を修正しました。下位互換性はいくつかの例外で維持されています。特に注意事項
- Revised the syntax of time descriptions ("t=", "r=", "z=") to remove ambiguities. Clarified that "z=" only modifies the immediately preceding "r=" lines. Made "z=" without a preceding "r=" a syntax error (Section 5.11). (This is incompatible with certain aberrant usage.)
- あいまいさを取り除くために、時間記述（ "t ="、 "r ="、 "z ="）の構文を修正しました。「z =」は、直前の「R =」行を変更するだけであることを明確にした。前の "r ="なしの "z ="を作った構文エラー（セクション5.11）。（これは特定の異常な使用法と互換性がありません。）
- Updated the "IP6-address" and "IP6-multicast" rules, consistent with the syntax in [RFC3986], mirroring a bug fix made to [RFC3261] by [RFC5954]. Removed rules that were unused as a result of this change.
- [RFC3986]では、[RFC5954]で[RFC3261]でバグ修正をミラーリングしながら、[IP6-Address "と" IP6-Multicast "ルールを更新しました。この変更の結果として未使用のルールを削除しました。
- The "att-field" rule has been renamed "attribute-name" because elsewhere "*-field" always refers to a complete line. However, the rulename "att-field" remains defined as a synonym for backward compatibility with references from other RFCs.
- "att-field"ルールは "* -field"が常に完全な行を参照しているため、 "attribute-name"という名前が変更されました。ただし、RuleName "att-field"は、他のRFCからの参照との下位互換性の同義語として定義されたままです。
- The "att-value" rule has been renamed "attribute-value".
- "att-value"ルールは "属性値"という名前です。
* Revised normative statements that were redundant with ABNF syntax, making the text non-normative.
* ABNF構文で冗長である規範文を修正し、テキストを非規範的にします。
* Revised IPv4 unicast and multicast addresses in the example SDP descriptions per [RFC5735] and [RFC5771].
* [RFC5735]および[RFC5771]の例のSDPの説明の例では、IPv4ユニキャストとマルチキャストアドレスを修正しました。
* Changed some examples to use IPv6 addresses, and added additional examples using IPv6.
* いくつかの例を変更してIPv6アドレスを使用し、IPv6を使用して追加の例を追加しました。
* Incorporated case-insensitivity rules from [RFC4855].
* [RFC4855]からのケース非感受性の規則を組み込んだ。
* Revised sections that incorrectly referenced NTP (Section 5.2, Section 5.9, Section 5.10, and Section 5.11).
* NTPが誤って参照されているセクション（セクション5.2、セクション5.10、およびセクション5.11）を修正しました。
* Clarified the explanation of the impact and use of the "a=charset:" attribute (Section 6.10).
* "A = charset："属性の影響の説明と使用の説明を明確にしました（6.10項）。
* Revised the description of the "a=type:" attribute to remove implication that it sometimes changes the default media direction to something other than "a=sendrecv" (Section 6.9).
* "a = type："属性の説明を修正して、デフォルトのメディアの方向を "a = sendRecv"以外のものに変更することがあることを削除することができます（セクション6.9）。
[E164] International Telecommunication Union, "E.164 : The international public telecommunication numbering plan", ITU Recommendation E.164, November 2010, <https://www.itu.int/rec/T-REC-E.164-201011-I/en>.
[E164]国際電気通信連合「E.164：国際公共通信番号計画」、ITU勧告E.164、2010年11月、<https：//www.itu.int/rec/t-rec-164-201011-I / EN>。
[ISO.8859-1.1998] International Organization for Standardization, "Information technology - 8-bit single byte coded graphic - character sets - Part 1: Latin alphabet No. 1, JTC1/ SC2", ISO/IEC Standard 8859-1, 1998.
[ISO.8859-1.1998]国際標準化のための国際機関、「情報技術 - 8ビット単位バイト符号化グラフィック - 文字セット - 第1部：ラテンアルファベット第1号、JTC1 / SC2」、ISO / IEC規格8859-1、1998。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P.、「ドメイン名 - コンセプトと施設」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<https：//www.rfc-editor.org/info/rfc1034>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P.、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https：//www.rfc-editor.org/info/rfc1035>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC2848] Petrack, S. and L. Conroy, "The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services", RFC 2848, DOI 10.17487/RFC2848, June 2000, <https://www.rfc-editor.org/info/rfc2848>.
[RFC2848] Petrack、S.およびL. Conroy、「PINTサービスプロトコル：電話コールサービスへのIPアクセスのための拡張およびSDPへの拡張」、RFC 2848、DOI 10.17487 / RFC2848、2000年6月、<https：// www。rfc-editor.org/info/rfc2848>。
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, <https://www.rfc-editor.org/info/rfc2978>.
[RFC2978] Freed、N.およびJ.Postel、 "Iana Charset登録手順"、BCP 19、RFC 2978、DOI 10.17487 / RFC2978、2000年10月、<https：//www.rfc-editor.org/info/rfc2978>。
[RFC3108] Kumar, R. and M. Mostafa, "Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, DOI 10.17487/RFC3108, May 2001, <https://www.rfc-editor.org/info/rfc3108>.
[RFC3108] Kumar、R.およびM. Mostafa、「ATMベアラ接続のセッション記述プロトコル（SDP）のための規則（SDP）、RFC 3108、DOI 10.17487 / RFC3108、2001年5月、<https：//www.rfc-editor.org/info/rfc3108>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] YERGEAU、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https：//www.rfc-editor.org/info/RFC3629>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、「Uniform Resource Identifier（URI）：汎用構文」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <https://www.rfc-editor.org/info/rfc4566>.
[RFC4566]ハンドリー、M.、Jacobson、V.、およびC.Perkins、「SDP：セッション記述プロトコル」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<https：//www.rfc-editor.org/情報/ RFC4566>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific Media Attributes in the Session Description Protocol (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, <https://www.rfc-editor.org/info/rfc5576>.
[RFC5576] Lennox、J.、OTT、J.、およびT.Schierl、「セッション記述プロトコル（SDP）」、RFC 5576、DOI 10.17487 / RFC5576、2009年6月、<https：//のソース固有のメディア属性www.rfc-editor.org/info/rfc5576>。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5646] Phillips、A.、ED。そして、「言語を特定するためのタグ」、BCP 47、RFC 5646、DOI 10.17487 / RFC5646、2009年9月、<https：//www.rfc-editor.org/info/rfc5646>。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890] Klensin、J.、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<https：//www.rfc-editor.org/info/RFC5890>。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.
[RFC5952]川村、S.およびM.川島、「IPv6アドレステキスト表現の推奨事項」、RFC 5952、DOI 10.17487 / RFC5952、2010年8月、<https：//www.rfc-editor.org/info/rfc5952>。
[RFC7195] Garcia-Martin, M. and S. Veikkolainen, "Session Description Protocol (SDP) Extension for Setting Audio and Video Media Streams over Circuit-Switched Bearers in the Public Switched Telephone Network (PSTN)", RFC 7195, DOI 10.17487/RFC7195, May 2014, <https://www.rfc-editor.org/info/rfc7195>.
[RFC7195] Garcia-Martin、M.およびS.Veikkolainen、「セッション記述プロトコル（SDP）拡張】公衆交換電話網（PSTN）の回線交換ベアリング（PSTN）「RFC 7195、DOI 10.17487/ RFC7195、2014年5月、<https://www.rfc-editor.org/info/rfc7195>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8859] Nandakumar, S., "A Framework for Session Description Protocol (SDP) Attributes When Multiplexing", RFC 8859, DOI 10.17487/RFC8859, January 2021, <https://www.rfc-editor.org/info/rfc8859>.
[RFC8859] Nandakumar、S。、「マルチプレクシング時のセッション記述プロトコル（SDP）属性のフレームワーク」、RFC 8859、DOI 10.17487 / RFC8859、2021年1月、<https：//www.rfc-editor.org/info/rfc8859>。
[RFC8864] Drage, K., Makaraju, M., Ejzak, R., Marcon, J., and R. Even, Ed., "Negotiation Data Channels Using the Session Description Protocol (SDP)", RFC 8864, DOI 10.17487/RFC8864, January 2021, <https://www.rfc-editor.org/info/rfc8864>.
[RFC8864]ドラジング、K.、Makaraju、M.、Ejzak、R.、Marcon、J.、およびR.さえ、「セッション記述プロトコルを使用したネゴシエーションデータチャネル（SDP）」、RFC 8864、DOI 10.17487/ RFC8864、2021年1月、<https://www.rfc-editor.org/info/rfc8864>。
[ITU.H332.1998] International Telecommunication Union, "H.332 : H.323 extended for loosely coupled conferences", ITU Recommendation H.332, September 1998, <https://www.itu.int/rec/T-REC-H.332-199809-I/en>.
[ITU.H332.1998]国際電気通信ユニオン、「H.332：H.323ゆるく結合会議のために拡張された拡大」、ITU勧告H.332、1998年9月、<https：//www.itu.int/rec/t-REC-H.332-199809-I / EN>。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, <https://www.rfc-editor.org/info/rfc2045>.
[RFC2045] Freed、N.およびN.Borenstein、「マルチポーズインターネットメール拡張（MIME）パート1：インターネットメッセージボディのフォーマット」、RFC 2045、DOI 10.17487 / RFC2045、1996年11月、<https：///www.rfc-editor.org/info/rfc2045>。
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, <https://www.rfc-editor.org/info/rfc2327>.
[RFC2327]ハンドリー、M.およびV.Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、DOI 10.17487 / RFC2327、1998年4月、<https：//www.rfc-editor.org/info/rfc2327>。
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, DOI 10.17487/RFC2974, October 2000, <https://www.rfc-editor.org/info/rfc2974>.
[RFC2974]ハンドリー、M.、Perkins、C.、およびE.Whelan、「セッションアナウンスプロトコル」、RFC 2974、DOI 10.17487 / RFC2974、2000年10月、<https：//www.rfc-editor.org/info/RFC2974>。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M.、E. Schooler、「SIP：セッション開始プロトコル」、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<https://www.rfc-editor.org/info/rfc3261>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <https://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J.およびH.Schulzrinne、「セッション記述プロトコル（SDP）」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<https：//ww.rfc-editor.org/ info / rfc3264>。
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003, <https://www.rfc-editor.org/info/rfc3550>.
[RFC3550] Schulzrinne、H.、Casner、S.、Frederick、R.、およびV. Jacobson、「RTP：リアルタイムアプリケーション用輸送プロトコル」、STD 64、RFC 3550、DOI 10.17487 / RFC3550、2003年7月、<https://www.rfc-editor.org/info/rfc3550>。
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, DOI 10.17487/RFC3551, July 2003, <https://www.rfc-editor.org/info/rfc3551>.
[RFC3551] Schulzrinne、H.およびS.Casner、STD 65、RFC 3551、DOI 10.17487 / RFC3551、2003年7月、<https：///www.rfc-編集者。ORG / INFO / RFC3551>。
[RFC3556] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, DOI 10.17487/RFC3556, July 2003, <https://www.rfc-editor.org/info/rfc3556>.
[RFC3556] Casner、S.、「セッション記述プロトコル（SDP）帯域幅修飾子（RTCP）帯域幅（RFC）帯域幅（RFC 3556、DOI 10.17487 / RFC3556、2003年7月、<https：//www.rfc-editor.org/ info / rfc3556>。
[RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003, <https://www.rfc-editor.org/info/rfc3605>.
[RFC3605] HUITEMA、C、「リアルタイム制御プロトコル（SDP）」（SDP） "、RFC 3605、DOI 10.17487 / RFC3605、2003年10月、<https://ww.rfc-editor.org/情報/ RFC3605>。
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, DOI 10.17487/RFC3711, March 2004, <https://www.rfc-editor.org/info/rfc3711>.
[RFC3711] Baugher、M.、McGrew、D.、Naslund、M.、Carrara、E.、K.Norrman、「安全なリアルタイムトランスポートプロトコル（SRTP）」、RFC 3711、DOI 10.17487 / RFC3711、3月2004年、<https：//www.rfc-editor.org/info/rfc3711>。
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004, <https://www.rfc-editor.org/info/rfc3840>.
[RFC3840] Rosenberg、J.、Schulzrinne、H.、およびP.Kyzivat、「セッション開始プロトコル（SIP）」、RFC 3840、DOI 10.17487 / RFC3840、2004年8月、<https：// www.rfc-editor.org / info / rfc3840>。
[RFC3890] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, DOI 10.17487/RFC3890, September 2004, <https://www.rfc-editor.org/info/rfc3890>.
[RFC3890] Westerlund、M.、「セッション記述プロトコル（SDP）」、RFC 3890、DOI 10.17487 / RFC3890、2004年9月、<https://www.rfc-editor.org/info/RFC3890>。
[RFC4568] Andreasen, F., Baugher, M., and D. Wing, "Session Description Protocol (SDP) Security Descriptions for Media Streams", RFC 4568, DOI 10.17487/RFC4568, July 2006, <https://www.rfc-editor.org/info/rfc4568>.
[RFC4568] Andreasen、F.、Baugher、M.、D. Wing、Media Streamsの「セッション記述プロトコル（SDP）セキュリティ説明」、RFC 4568、DOI 10.17487 / RFC4568、2006年7月、<https：// www。rfc-editor.org/info/rfc4568>。
[RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, DOI 10.17487/RFC4855, February 2007, <https://www.rfc-editor.org/info/rfc4855>.
[RFC4855] Casner、S.、RTPペイロードフォーマットの「メディアタイプ登録」、RFC 4855、DOI 10.17487 / RFC4855、2007年2月、<https：//www.rfc-editor.org/info/rfc4855>。
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, February 2008, <https://www.rfc-editor.org/info/rfc5124>.
[RFC5124] OTT、J.およびE.Carrara、「リアルタイムトランスポート制御プロトコル（RTCP）ベースのフィードバック（RTP / SAVPF）」、RFC 5124、DOI 10.17487 / RFC5124、2008年2月、<HTTPS）//www.rfc-editor.org/info/rfc5124>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P.、Ed。、「インターネットメッセージフォーマット」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<https：//www.rfc-editor.org/info/rfc5322>。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", RFC 5735, DOI 10.17487/RFC5735, January 2010, <https://www.rfc-editor.org/info/rfc5735>.
[RFC5735]綿、M.およびL. Vegoda、「特別使用IPv4アドレス」、RFC 5735、DOI 10.17487 / RFC5735、2010年1月、<https：//www.rfc-editor.org/info/rfc5735>。
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, <https://www.rfc-editor.org/info/rfc5771>.
[RFC5771]綿、M.、Vegoda、L.、D.Meyer、「IANAガイドラインのIANAガイドライン」、BCP 51、RFC 5771、DOI 10.17487 / RFC5771、2010年3月、<https：//www.rfc-editor.org/info/rfc5771>。
[RFC5888] Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010, <https://www.rfc-editor.org/info/rfc5888>.
[RFC5888] Camarillo、G.およびH.Schulzrinne「セッション記述プロトコル（SDP）グループ化フレームワーク」、RFC 5888、DOI 10.17487 / RFC5888、2010年6月、<https：//www.rfc-editor.org/info/RFC5888>。
[RFC5954] Gurbani, V., Ed., Carpenter, B., Ed., and B. Tate, Ed., "Essential Correction for IPv6 ABNF and URI Comparison in RFC 3261", RFC 5954, DOI 10.17487/RFC5954, August 2010, <https://www.rfc-editor.org/info/rfc5954>.
[RFC5954] Gurbani、V.、Ed。、Carpenter、B.、Ed。、およびB.Tate、Ed。、「RFC 3261のIPv6 ABNFおよびURI比較のための必須訂正」、RFC 5954、DOI 10.17487 / RFC5954、8月2010、<https://www.rfc-editor.org/info/rfc5954>。
[RFC6466] Salgueiro, G., "IANA Registration of the 'image' Media Type for the Session Description Protocol (SDP)", RFC 6466, DOI 10.17487/RFC6466, December 2011, <https://www.rfc-editor.org/info/rfc6466>.
[RFC6466] Salgueiro、G. "セッション記述プロトコル（SDP）"、RFC 6466、DOI 10.17487 / RFC6466、2011年12月、<https：///www.rfc-編集者の「IANA登録」。org / info / rfc6466>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J.、およびT.Hansen、「メディアタイプの仕様および登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<https：///www.rfc-editor.org/info/rfc6838>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールド、R.、ED。J.Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：メッセージ構文とルーティング」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https：//www.rfc-editor.org/info/RFC7230>。
[RFC7405] Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014, <https://www.rfc-editor.org/info/rfc7405>.
[RFC7405] KYZIVAT、P.、「ABNFの大文字と小文字の区別文字列サポート」、RFC 7405、DOI 10.17487 / RFC7405、2014年12月、<https：//www.rfc-editor.org/info/rfc7405>。
[RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms for Real-Time Transport Protocol (RTP) Sources", RFC 7656, DOI 10.17487/RFC7656, November 2015, <https://www.rfc-editor.org/info/rfc7656>.
[RFC7656] Lennox、J.、Gross、K.、Nandakumar、S.、Salgueiro、G.、B. Burman、ED。、「リアルタイムトランスポートプロトコル（RTP）ソースのためのセマンティクスおよびメカニズムの分類」、RFC 7656、DOI 10.17487 / RFC7656、2015年11月、<https：//www.rfc-editor.org/info/rfc7656>。
[RFC7826] Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M., and M. Stiemerling, Ed., "Real-Time Streaming Protocol Version 2.0", RFC 7826, DOI 10.17487/RFC7826, December 2016, <https://www.rfc-editor.org/info/rfc7826>.
[RFC7826] Schulzrinne、H.、Rao、A.、Lanphier、R.、Westerlund、M.、M. Stiemerling、Ed。、「リアルタイムストリーミングプロトコルバージョン2.0」、RFC 7826、DOI 10.17487 / RFC7826、12月2016年、<https：//www.rfc-editor.org/info/rfc7826>。
[RFC8445] Keranen, A., Holmberg, C., and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", RFC 8445, DOI 10.17487/RFC8445, July 2018, <https://www.rfc-editor.org/info/rfc8445>.
[RFC8445]ケラネン、A.、Holmberg、C.、J.Rosenberg、「インタラクティブ接続施設（氷）：ネットワークアドレス翻訳者のためのプロトコル」、RFC 8445、DOI 10.17487 / RFC8445、2018年7月、<https://www.rfc-editor.org/info/rfc8445>。
[RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, A., and R. Shpount, "Session Description Protocol (SDP) Offer/Answer Procedures for Interactive Connectivity Establishment (ICE)", RFC 8839, DOI 10.17487/RFC8839, January 2021, <https://www.rfc-editor.org/info/rfc8839>.
[RFC8839] Petit-Huguenin、M.、Nandakumar、S.、Holmberg、C.、Keränen、A.、R. Shpount、「セッション説明プロトコル（SDP）オファー/回答手順インタラクティブ接続確立（ICE）」RFC 8839、DOI 10.17487 / RFC8839、2021年1月、<https：//www.rfc-editor.org/info/rfc8839>。
[RFC8843] Holmberg, C., Alvestrand, H., and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", RFC 8843, DOI 10.17487/RFC8843, January 2021, <https://www.rfc-editor.org/info/rfc8843>.
[RFC8843] Holmberg、C、Alvestrand、H.、およびC.ジェンニング、「セッション記述プロトコル（SDP）」、RFC 8843、DOI 10.17487 / RFC8843、<https：// www。rfc-editor.org/info/rfc8843>。
Acknowledgements
謝辞
Many people in the IETF Multiparty Multimedia Session Control (MMUSIC) working group have made comments and suggestions contributing to this document.
IETFマルチパーティマルチメディアセッションコントロール（MMUSIC）ワーキンググループの多くの人々は、この文書に貢献するコメントや提案をしました。
In particular, we would like to thank the following people who contributed to the creation of this document or one of its predecessor documents: Adam Roach, Allison Mankin, Bernie Hoeneisen, Bill Fenner, Carsten Bormann, Eve Schooler, Flemming Andreasen, Gonzalo Camarillo, Jörg Ott, John Elwell, Jon Peterson, Jonathan Lennox, Jonathan Rosenberg, Keith Drage, Peter Parnes, Rob Lanphier, Ross Finlayson, Sean Olson, Spencer Dawkins, Steve Casner, Steve Hanna, Van Jacobson.
特に、この文書の作成に貢献した次の人々、またはその前任者の文書の1つに貢献してくれたくありません.Adam Roach、Allison Mankin、Bernie Hoeneisen、Bill Fenner、Carsten Bormann、Eve Surcherer、Flemming Andreasen、Gonzalo Camarillo、JörgOtt、John Elwell、Jon Peterson、Jonathan Lennox、Jonathan Rosenberg、Keith Drage、Peter Parnes、Rob Lanphier、Ross Finlayson、Sean Olson、Spencer Dawkins、Steve Casner、Steve Hanna、Van Jacobson。
Authors' Addresses
著者の住所
Ali Begen Networked Media Turkey
アリベンネットワークドメディアトルコ
Email: ali.begen@networked.media
Paul Kyzivat United States of America
Paul Kyzivatアメリカ合衆国
Email: pkyzivat@alum.mit.edu
Colin Perkins University of Glasgow School of Computing Science Glasgow G12 8QQ United Kingdom
Colin Perkins Glasgow大学コンピューティングサイエンスグラスゴーG12 8QQイギリス
Email: csp@csperkins.org
Mark Handley University College London Department of Computer Science London WC1E 6BT United Kingdom
マークハンドリー大学カレッジロンドンコンピュータサイエンス省ロンドンWC1E 6BTイギリス
Email: M.Handley@cs.ucl.ac.uk