[要約] RFC 3407は、SDP（Session Description Protocol）のSimple Capability Declarationに関する仕様です。このRFCの目的は、SDPを使用してセッションの能力を宣言するための簡単な方法を提供することです。
Network Working Group F. Andreasen
Request for Comments: 3407 Cisco Systems
Category: Standards Track October 2002
Session Description Protocol (SDP) Simple Capability Declaration
セッション説明プロトコル（SDP）簡単な機能宣言
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document defines a set of Session Description Protocol (SDP) attributes that enables SDP to provide a minimal and backwards compatible capability declaration mechanism. Such capability declarations can be used as input to a subsequent session negotiation, which is done by means outside the scope of this document. This provides a simple and limited solution to the general capability negotiation problem being addressed by the next generation of SDP, also known as SDPng.
このドキュメントでは、SDPが最小限の逆互換能力宣言メカニズムを提供できるようにするセッション説明プロトコル（SDP）属性のセットを定義します。このような能力宣言は、その後のセッション交渉への入力として使用できます。これは、このドキュメントの範囲外の手段によって行われます。これは、SDPNGとしても知られる次世代のSDPによって対処される一般的な能力交渉の問題に対するシンプルで限定的なソリューションを提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC-2119 [2]に記載されているように解釈される。
The Session Description Protocol (SDP) [3] describes multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. SDP was not intended to provide capability negotiation. However, as the need for this has become increasingly important, work has begun on a "next generation SDP" (SDPng) [4,5] that supports both session description and capability negotiation. SDPng is not anticipated to be backwards compatible with SDP and work on SDPng is currently in the early stages. However, several other protocols, e.g. SIP [6] and Media Gateway Control Protocol (MGCP) [7], use SDP and are likely to continue doing so for the foreseeable future. Nevertheless, in many cases these signaling protocols have an urgent need for some limited form of capability negotiation.
セッション説明プロトコル（SDP）[3]は、セッションの発表、セッションの招待状、およびその他の形式のマルチメディアセッション開始の目的でマルチメディアセッションについて説明しています。SDPは、機能交渉を提供することを意図していませんでした。しかし、これの必要性がますます重要になるにつれて、セッションの説明と能力交渉の両方をサポートする「次世代SDP」（SDPNG）[4,5]で作業が開始されました。SDPNGはSDPと逆方向に互換性があるとは予想されておらず、SDPNGの作業は現在初期段階にあります。ただし、他のいくつかのプロトコル、例えばSIP [6]およびMedia Gateway Controlプロトコル（MGCP）[7]は、SDPを使用し、予見可能な将来のために継続する可能性があります。それにもかかわらず、多くの場合、これらのシグナル伝達プロトコルは、限られた形式の能力交渉を緊急に必要としています。
For example, an endpoint may support G.711 audio (over RTP) as well as T.38 fax relay (over UDP or TCP). Unless the endpoint is willing to support two media streams at the same time, this cannot currently be expressed in SDP. Another example involves support for multiple codecs. An endpoint indicates this by including all the codecs in the "m=" line in the session description. However, the endpoint thereby also commits to simultaneous support for each of these codecs. In practice, Digital Signal Processor (DSP) memory and processing power limitations may not make this feasible.
たとえば、エンドポイントは、G.711オーディオ（RTPを超える）およびT.38 Faxリレー（UDPまたはTCPを超える）をサポートする場合があります。エンドポイントが2つのメディアストリームを同時にサポートする意思がない限り、これは現在SDPで表現することはできません。別の例には、複数のコーデックのサポートが含まれます。エンドポイントは、セッションの説明の「m =」行にすべてのコーデックを含めることにより、これを示します。ただし、エンドポイントは、これらの各コーデックの同時サポートもコミットします。実際には、デジタル信号プロセッサ（DSP）メモリと処理電力の制限がこれを実行可能にしない場合があります。
As noted in [4], the problem with SDP is that media descriptions are used to describe session parameters as well as capabilities without a clear distinction between the two.
[4]で述べたように、SDPの問題は、メディアの説明が、2つの間を明確に区別することなくセッションパラメーターと機能を記述するために使用されることです。
In this document, we define a minimal and backwards compatible capability declaration feature in SDP by defining a set of new SDP attributes. Together, these attributes define a capability set, which consists of a capability set sequence number followed by one or more capability descriptions. Each capability description in the set contains information about supported media formats, but the endpoint is not committing to use any of these. In order to actually use a declared capability, session negotiation will have to be done by means outside the scope of this document, e.g., using the offer/answer model [8].
このドキュメントでは、新しいSDP属性のセットを定義することにより、SDPの最小限の互換互換能力宣言機能を定義します。一緒に、これらの属性は機能セットを定義します。これは、機能セットセットシーケンス番号で構成され、1つ以上の機能説明が続きます。セットの各機能の説明には、サポートされているメディア形式に関する情報が含まれていますが、エンドポイントはこれらのいずれかを使用することをコミットしていません。宣言された能力を実際に使用するには、このドキュメントの範囲外、たとえばオファー/回答モデルを使用している間、セッション交渉を行う必要があります[8]。
It should be noted that the mechanism is not intended to solve the general capability negotiation problem targeted by SDPng. It is merely intended as a simple and limited solution to the most urgent problems facing current users of SDP.
メカニズムは、SDPNGの対象となる一般的な能力交渉問題を解決することを意図していないことに注意する必要があります。これは、SDPの現在のユーザーが直面している最も緊急の問題に対するシンプルで限定的なソリューションとして単に意図されています。
The SDP Simple Capability Declaration (simcap) is defined by a set of SDP attributes. Together, these attributes form a capability set which describes the complete media capabilities of the endpoint. Any previous capability sets issued by the endpoint for the session in question no longer apply. The capability set consists of a sequence number and one or more capability descriptions. Each such capability description describes the media type and media formats supported and may include one or more capability parameters to further define the capability. A session description MUST NOT contain more than one capability set, however the capability set can describe capabilities at both the session and media level. Capability descriptions provided at the session level apply to all media streams of the media type indicated, whereas capability descriptions provided at the media level apply to that particular media stream only. We refer to these respectively as session capabilities and media stream capabilities. A media stream capability may or may not be of the same media type as the media stream to which it applies.
SDPの単純な機能宣言（SIMCAP）は、一連のSDP属性によって定義されます。一緒に、これらの属性は、エンドポイントの完全なメディア機能を説明する機能セットを形成します。問題のセッションのエンドポイントによって発行された以前の機能セットは、もはや適用されません。機能セットは、シーケンス番号と1つ以上の機能の説明で構成されています。このような機能の各説明は、サポートされているメディアタイプとメディア形式を記述し、機能をさらに定義するための1つ以上の機能パラメーターを含めることができます。セッションの説明には1つ以上の機能セットを含めることはできませんが、機能セットはセッションレベルとメディアレベルの両方で機能を説明できます。セッションレベルで提供される機能の説明は、示されているメディアタイプのすべてのメディアストリームに適用されますが、メディアレベルで提供される機能の説明は、その特定のメディアストリームのみにのみ適用されます。これらをそれぞれセッション機能とメディアストリーム機能と呼びます。メディアストリーム機能は、適用されるメディアストリームと同じメディアタイプである場合とそうでない場合があります。
The capability set MUST begin with a single sequence number followed by one or more capability descriptions listing all media formats the endpoint is currently able and willing to support. More specifically, if a media format is included in a media ("m=") line, then by definition the media format MUST be included in either a session capability or a media stream capability for that media line. The endpoint MAY include additional media formats in a capability if it is capable of supporting those media formats in a session with its peer. An endpoint MUST NOT include capabilities it knows it cannot use in a particular session. An endpoint receiving a capability set from another endpoint MAY use any of the media formats included in that capability set in a later attempt to negotiate media streams with the other endpoint, e.g., using the offer/answer model [8]. If a new capability set is received from the other endpoint, the old capability set MUST NOT be used any longer. Session capabilities can be used for any media streams of the indicated media type, whereas media stream capabilities can only be used for their associated media line. However, an endpoint receiving a capability set with a given media format MUST NOT assume that a subsequent attempt to negotiate a media stream using just this media format will succeed.
機能セットは、単一のシーケンス番号から開始する必要があります。その後、すべてのメディア形式をリストする1つまたは複数の機能の説明が、エンドポイントが現在可能であり、喜んでサポートすることを望んでいます。より具体的には、メディア形式がメディア（ "m ="）行に含まれている場合、定義上、メディア形式は、そのメディアラインのセッション機能またはメディアストリーム機能のいずれかに含める必要があります。エンドポイントには、ピアとのセッションでこれらのメディア形式をサポートできる場合、機能に追加のメディア形式が含まれる場合があります。エンドポイントには、特定のセッションで使用できないと知っている機能を含めてはなりません。別のエンドポイントからセットセットを受信するエンドポイントは、オファー/回答モデルを使用して、他のエンドポイントとメディアストリームを他のエンドポイントと交渉しようとする後の試みに設定されたその機能に含まれるメディア形式のいずれかを使用できます[8]。新しい機能セットが他のエンドポイントから受信された場合、古い機能セットをもう使用してはなりません。セッション機能は、指定されたメディアタイプの任意のメディアストリームに使用できますが、メディアストリーム機能は関連するメディアラインにのみ使用できます。ただし、特定のメディア形式でセットセットを受信するエンドポイントは、このメディア形式のみを使用してメディアストリームを交渉しようとするその後の試みが成功すると仮定してはなりません。
The individual capability descriptions in a capability set can be provided contiguously or they can be scattered throughout the session description. The first capability description MUST, however, follow immediately after the sequence number.
機能セットの個々の機能の説明は、連続的に提供することも、セッションの説明全体に散在することもできます。ただし、最初の機能の説明は、シーケンス番号の直後に従う必要があります。
The sequence number is on the form:
シーケンス番号はフォーム上にあります。
a=sqn: <sqn-num>
where <sqn-num> is an integer between 0 and 255 (both included). The initial sequence number MUST be 0 (zero) and it MUST be incremented by 1 modulo 256 with each new capability set issued by the endpoint. Receivers may not necessarily see all capability sets issued and hence MUST NOT reject a capability set due to gaps in sequence numbers. The sequence number MUST either be provided as a session-level or media-level attribute, however there MUST NOT be more than one occurrence of the sequence number attribute in the session description (since there cannot be more than one capability set).
ここで、<sqn-num>は0〜255の間の整数です（両方が含まれています）。初期シーケンス番号は0（ゼロ）でなければならず、エンドポイントによって発行された新しい機能セットごとに、1 Modulo 256で増分する必要があります。受信機は必ずしもすべての機能セットが発行されるとは限らないため、シーケンス番号のギャップのために機能セットを拒否してはなりません。シーケンス番号は、セッションレベルまたはメディアレベルの属性として提供する必要がありますが、セッションの説明にシーケンス番号属性の1つ以上の発生がある必要があります（複数の機能セットがないため）。
Each capability description in the capability set is on the form:
機能セットの各機能の説明は、フォーム上にあります。
a=cdsc: <cap-num> <media> <transport> <fmt list>
where <cap-num> is an integer between 1 and 255 (both included) used to number the capabilities, and <media>, <transport>, and <fmt list> are defined as in the SDP "m=" line. The capability description refers to a send and receive capability by default. When generating a capability set, the capability number MUST start with 1 in the first capability description, and be incremented by the number of media formats in the <fmt list> for each subsequent capability description. The media formats in the <fmt list> are numbered from left to right. Receivers of a capability set MUST NOT, however, reject capability descriptions due to gaps in the capability numbers. The capability number provides a convenient handle within the context of the capability set (as referenced by the sequence number) which may be used to reference a particular capability by means outside of this specification.
ここで、<cap-num>は1〜255の間の整数であり（両方が含まれています）、機能の番号を付け、<media>、<fmtリスト>はSDP "m ="行のように定義されます。機能の説明とは、デフォルトで送信および受信機能を指します。機能セットを生成する場合、機能番号は最初の機能説明から1から始まり、後続の各機能説明の<FMTリスト>のメディア形式の数によって増加する必要があります。<FMTリスト>のメディア形式には、左から右に番号が付けられています。ただし、機能セットの受信機は、機能数のギャップのために機能の説明を拒否してはなりません。機能番号は、この仕様以外の手段で特定の機能を参照するために使用できる機能セット（シーケンス番号で参照）のコンテキスト内で便利なハンドルを提供します。
A capability description can include one or more capability parameter lines on the form:
機能の説明には、フォームに1つ以上の機能パラメーター行を含めることができます。
a=cpar: <cap-par>
a=cparmin: <cap-par>
a=cparmax: <cap-par>
where <cap-par> is either bandwidth information ("b=") or an attribute ("a=") in its full '<type>=<value>' form (see [3]). A capability parameter line provides additional parameters for the preceding "cdsc" attribute line. Capability parameter lines for a capability description SHOULD immediately follow the "cdsc" line they refer to. Nevertheless, the capability description includes all capability parameter lines until the next capability description ("cdsc") or media ("m=") line in the session description.
ここで、<cap-par>は、帯域幅情報（ "b ="）または属性（ "a ="）のいずれかです。機能パラメーターラインは、前の「CDSC」属性行の追加パラメーターを提供します。機能説明の機能パラメーターラインは、すぐに参照する「CDSC」ラインに従う必要があります。それにもかかわらず、機能の説明には、セッションの説明の次の機能説明（ "CDSC"）またはメディア（ "m ="）行まで、すべての機能パラメーター行が含まれます。
The "cpar" attribute should normally be used when capability parameter values are to be specified. When provided, it means that the endpoint is declaring that it supports the media formats in the preceding "cdsc" line in accordance with the <cap-par> value specified. This can, for example, be used to specify "fmtp" parameters. If a session negotiation is attempted without considering the <cap-par> value, it may fail due to lack of endpoint support. A capability description may contain zero, one, or more "cpar" attribute lines describing either the same or different parameters. Describing the same parameter more than once can be used to specify alternatives.
通常、「CPAR」属性を使用する必要があります。パラメーター値を指定する場合は、通常使用する必要があります。提供される場合、エンドポイントは、指定された<cap-par>値に従って、前の「CDSC」ラインのメディア形式をサポートすることを宣言していることを意味します。これは、たとえば、「FMTP」パラメーターを指定するために使用できます。<cap-par>値を考慮せずにセッションの交渉が試みられた場合、エンドポイントのサポートがないために失敗する可能性があります。機能の説明には、同じパラメーターまたは異なるパラメーターを記述するゼロ、1つ、またはそれ以上の「CPAR」属性行を含めることができます。同じパラメーターを複数回記述することは、代替案を指定するために使用できます。
Where a minimum numerical value is to be specified, the "cparmin" attribute should be used. There may be zero, one, or more "cparmin" attribute lines in a capability description, however a given parameter MUST NOT be described by a "cparmin" attribute more than once.
最小数値を指定する場合、「cparmin」属性を使用する必要があります。ゼロ、1つ、またはそれ以上の「cParmin」属性行が機能説明にある場合がありますが、特定のパラメーターは「cparmin」属性によって複数回記述されてはなりません。
Where a maximum numerical value is to be specified, the "cparmax" attribute should be used. There may be zero, one, or more "cparmax" attribute lines in a capability description, however a given parameter MUST NOT be described by a "cparmax" attribute more than once.
最大数値を指定する場合、「cParmax」属性を使用する必要があります。ゼロ、1つ、またはそれ以上の「cParmax」属性行が機能説明にある場合がありますが、特定のパラメーターを「cParmax」属性によって複数回記述してはなりません。
Ranges of numerical values can be expressed by using a "cparmin" and a "cparmax" attribute for a given parameter. It follows from the previous rules, that only a single range can be specified for a given parameter.
数値の範囲は、特定のパラメーターの「cparmin」と「cparmax」属性を使用して表現できます。以前のルールから、特定のパラメーターに対して1つの範囲のみを指定できるということです。
Capability descriptions may be provided at both the session-level and media-level. A capability description provided at the session-level applies to all the media streams of the indicated media type in the session description. A capability description provided at the media-level only applies to that particular media stream (regardless of media type). If a capability description with media type X is provided at the session-level, and there are no media streams of type X in the session description, then it is undefined which of the media streams the capability description applies to (except if there is only one media stream). It is therefore RECOMMENDED, that such capabilities are provided at the media-level instead.
セッションレベルとメディアレベルの両方で、機能の説明が提供される場合があります。セッションレベルで提供される機能の説明は、セッションの説明で、指定されたメディアタイプのすべてのメディアストリームに適用されます。メディアレベルで提供される機能の説明は、その特定のメディアストリームにのみ適用されます（メディアタイプに関係なく）。メディアタイプXを使用した機能の説明がセッションレベルで提供され、セッションの説明にタイプXのメディアストリームがない場合、どのメディアストリームが適用されるメディアストリームが未定義です（1つのメディアストリーム）。したがって、そのような機能が代わりにメディアレベルで提供されることを推奨します。
Below we show an example session description using the above simple capability declaration mechanism:
以下に、上記の単純な機能宣言メカニズムを使用して、セッションの説明の説明を示します。
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 18 96
a=rtpmap:96 telephone-event
a=fmtp:96 0-15,32-35
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18 96
a=cpar: a=fmtp:96 0-16,32-35
a=cdsc: 4 image udptl t38
a=cdsc: 5 image tcp t38
The sender of this session description is currently prepared to send and receive G.729 audio as well as telephone-events 0-15 and 32-35. The sender is furthermore capable of supporting:
このセッションの説明の送信者は現在、G.729オーディオと電話のイベント0-15および32-35を送信および受け取る準備ができています。送信者はさらに、次のことをサポートできます。
* PCMU encoding for the audio media stream,
* telephone events 0-16 and 32-35,
* T.38 fax relay using udp or tcp (see [9]).
*オーディオメディアストリームのPCMUエンコード、
*電話イベント0-16および32-35、
* T.38 UDPまたはTCPを使用したFAXリレー（[9]を参照）。
Note, that the first capability number specified is 1, whereas the next is 4 since three media formats were included in the first capability description. Also note that the rtpmap for payload type 96 was not included in the capability description, as it was already specified for the media ("m=") line. Conversely, it would of course not have been valid to provide the rtpmap in the capability description and then omit the "a=rtpmap" line.
指定された最初の機能番号は1であるのに対し、次の機能は3つのメディア形式が最初の機能説明に含まれているため4です。また、ペイロードタイプ96のRTPMAPは、メディア（ "m ="）行で既に指定されているため、機能の説明に含まれていなかったことに注意してください。逆に、もちろん、機能の説明にrtpmapを提供し、「a = rtpmap」行を省略することは有効ではありませんでした。
Below, we show another example of the simple capability declaration mechanism, this time with multiple media streams:
以下に、単純な機能宣言メカニズムの別の例を示します。今回は複数のメディアストリームを使用しています。
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
m=audio 3456 RTP/AVP 18
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
m=video 3458 RTP/AVP 31
a=cdsc: 3 video RTP/AVP 31 34
The sender of this session description is currently prepared to send and receive G.729 audio and H.261 video. The sender is furthermore capable of supporting:
このセッションの説明の送信者は現在、G.729オーディオとH.261ビデオを送信および受信するために準備されています。送信者はさらに、次のことをサポートできます。
* PCMU encoding for the audio media stream, * H.263 for the video media stream.
* Audio Media StreamのPCMUエンコード、 * H.263ビデオメディアストリーム。
Note that the first capability number specified is 1, whereas the next is 3, since two media formats were included in the first capability description. Also note that the sequence number applies to the entire capability set, i.e. both audio and video, and hence is only supplied once. Finally, note that the media formats 18 and 31 are listed in both the media lines and the capability set as required. The above session description could have equally been supplied as follows:
指定された最初の機能番号は1であるのに対し、次は2つのメディア形式が最初の機能説明に含まれていたため、3は3です。また、シーケンス番号は、オーディオとビデオの両方に適用されるため、1回のみ提供されることに注意してください。最後に、メディアフォーマット18と31は、必要に応じてメディアラインと設定された機能の両方にリストされていることに注意してください。上記のセッションの説明は、次のように等しく提供されている可能性があります。
v=0
o=- 25678 753849 IN IP4 128.96.41.1
s=
c=IN IP4 128.96.41.1
t=0 0
a=sqn: 0
a=cdsc: 1 audio RTP/AVP 0 18
a=cdsc: 3 video RTP/AVP 31 34
m=audio 3456 RTP/AVP 18
m=video 3458 RTP/AVP 31
i.e., with the capability set provided at the session-level.
つまり、セッションレベルで提供される機能セットを使用します。
Capability negotiation of security-sensitive parameters is a delicate process, and should not be done without careful evaluation of the design, including the possible susceptibility to downgrade attacks. Use of capability re-negotiation may make the session susceptible to denial of service, without design care as to authentication.
セキュリティに敏感なパラメーターの能力交渉は微妙なプロセスであり、攻撃のダウングレードの可能性を含む、設計を慎重に評価することなく行うべきではありません。能力の再交渉の使用により、セッションは、認証に関する設計に注意することなく、サービスの拒否の影響を受けやすくなる場合があります。
This document defines the following new SDP parameters of type "att-field" (attribute names):
このドキュメントでは、「att-field」（属性名）のタイプの次の新しいSDPパラメーターを定義します。
Attribute name: sqn Long form name: Sequence number. Type of attribute: Session-level and media-level. Subject to charset: No. Purpose: Capability set numbering. Appropriate values: See Section 3.
属性名：SQN LONGフォーム名：シーケンス番号。属性のタイプ：セッションレベルとメディアレベル。charsetの対象：いいえ。目的：機能設定番号。適切な値：セクション3を参照してください。
Attribute name: cdsc Long form name: Capability description. Type of attribute: Session-level and media-level. Subject to charset: No. Purpose: Describe capabilities in a capability set. Appropriate values: See Section 3.
属性名：CDSCロングフォーム名：機能説明。属性のタイプ：セッションレベルとメディアレベル。charsetの対象：いいえ。目的：機能セットで機能を説明します。適切な値：セクション3を参照してください。
Attribute name: cpar Long form name: Capability parameter line. Type of attribute: Session-level and media-level. Subject to charset: No. Purpose: Provide capability description parameters. Appropriate values: See Section 3.
属性名：CPAR LONGフォーム名：機能パラメーター行。属性のタイプ：セッションレベルとメディアレベル。charsetの対象：いいえ。目的：機能説明パラメーターを提供します。適切な値：セクション3を参照してください。
Attribute name: cparmin Long form name: Minimum capability parameter line. Type of attribute: Session-level and media-level. Subject to charset: No. Purpose: Provide minimum capability description parameters. Appropriate values: See Section 3.
属性名：CParmin Longフォーム名：最小機能パラメーター行。属性のタイプ：セッションレベルとメディアレベル。charsetの対象：いいえ。目的：最小機能説明パラメーターを提供します。適切な値：セクション3を参照してください。
Attribute name: cparmax Long form name: Maximum capability parameter line. Type of attribute: Session-level and media-level. Subject to charset: No. Purpose: Provide maximum capability description parameters. Appropriate values: See Section 3.
属性名：CParmax Longフォーム名：最大機能パラメーター行。属性のタイプ：セッションレベルとメディアレベル。charsetの対象：いいえ。目的：最大の機能説明パラメーターを提供します。適切な値：セクション3を参照してください。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Handley, M. and V. Jacobson, "SDP: session description protocol", Request for Comments 2327, April 1998.
[3] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、コメントのリクエスト2327、1998年4月。
[4] Kutscher, Ott, Bormann and Curcio, "Requirements for Session Description and Capability Negotiation", Work in Progress.
[4] Kutscher、Ott、Bormann and Curcio、「セッションの説明と能力交渉の要件」、進行中の作業。
[5] Kutscher, Ott and Borman, "Session Description and Capability Negotiation", Work in Progress.
[5] Kutscher、Ott、およびBorman、「セッションの説明と能力交渉」、進行中の作業。
[6] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: session initiation protocol", RFC 2543, March 1999.
[6] Handley、M.、Schulzrinne、H.、Schooler、E。and J. Rosenberg、「SIP：SESSION INTIATION Protocol」、RFC 2543、1999年3月。
[7] Arango, M., Dugan, A., Elliott, I., Huitema, C. and S. Pickett, "Media Gateway Control Protocol (MGCP) Version 1.0", RFC 2705, October 1999.
[7] Arango、M.、Dugan、A.、Elliott、I.、Huitema、C。and S. Pickett、「Media Gateway Control Protocol（MGCP）バージョン1.0」、RFC 2705、1999年10月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", Work in Progress.
[8] Rosenberg、J。およびH. Schulzrinne、「SDPを使用したオファー/回答モデル」は、進行中の作業です。
[9] ITU-T Recommendation T.38 Annex D, "SIP/SDP Call Establishment Procedures".
[9] ITU-Tの推奨T.38 Annex D、「SIP/SDPコール設立手順」。
This work draws upon the ongoing work on SDPng in the IETF MMUSIC Working Group; in particular [4]. Furthermore this work was inspired by the CableLabs PacketCable project. The author would like to recognize and thank Joerg Ott and Jonathan Rosenberg who provided many detailed comments and suggestions to improve this specification. Colin Perkins, Orit Levin and Tom Taylor provided valuable feedback as well.
この作業は、IETF MMUSICワーキンググループのSDPNGで進行中の作業に基づいています。特に[4]。さらに、この作業は、CableLabs Packetcableプロジェクトに触発されました。著者は、この仕様を改善するために多くの詳細なコメントと提案を提供してくれたJoerg OttとJonathan Rosenbergを認識し、感謝したいと思います。コリン・パーキンス、オリット・レビン、トム・テイラーも貴重なフィードバックを提供しました。
Flemming Andreasen Cisco Systems 499 Thornall Street, 8th floor Edison, NJ EMail: fandreas@cisco.com
フレミングアンドレアセンシスコシステム499 Thornall Street、8階エジソン、ニュージャージー州メール：fandreas@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。