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.
著作権（C）インターネット協会（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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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
セッション記述プロトコル（SDP）[3]セッション告知、セッション招待、およびマルチメディアセッション開始の他の形態の目的のためのマルチメディアセッションを記述する。 SDPは、能力交渉を提供することを意図していませんでした。これの必要性はますます重要になってきているようしかし、仕事はセッション記述と能力交渉の両方をサポートしている「次世代SDP」（SDPng）[4,5]で始まっています。 SDPngは、初期段階に現在あるSDPng上のSDPと仕事との後方互換性があると予想されていません。しかし、いくつかの他のプロトコル、例えばSIPは、[6]、メディアゲートウェイ制御プロトコル（MGCP）[7]、SDPを使用しての可能性があります
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.
予見可能な将来のためにそう続けます。それにもかかわらず、多くの場合、これらのシグナリングプロトコルは、能力交渉のいくつかの限定された形のために緊急に必要としています。
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.
例えば、エンドポイントは（UDPまたはTCP上）（RTPオーバー）G.711オーディオだけでなく、T.38ファックスリレーをサポートすることができます。エンドポイントは、同時に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に最小限と後方互換性機能の宣言機能を定義します。一緒に、これらの属性は、一つ以上の機能の説明が続く能力設定されたシーケンス番号から成る能力セットを定義します。セット内の各機能の説明は、サポートされているメディアフォーマットに関する情報が含まれていますが、エンドポイントは、これらのいずれかを使用することがコミットされていません。実際に宣言された機能を使用するためには、セッション交渉は[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つ以上の能力パラメータを含むことができます。セッション記述は、複数の能力セットを含めることはできませんしかし、能力セットは両方のセッションとメディアレベルでの機能を記述することができます。メディアレベルで提供能力の説明は、その特定のメディアストリームに適用されるのに対し、セッション・レベルで提供される機能の説明は、示されたメディアタイプのすべてのメディアストリームに適用します。私たちは、セッション機能とメディアストリーム機能として、それぞれ、これらを参照してください。メディアストリーム機能は、またはそれが適用されるメディア・ストリームと同じメディアタイプであってもなくてもよいです。
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.
能力セットは、エンドポイントが現在できるとサポートしていく所存です、すべてのメディアフォーマットを一覧一の以上の機能の説明に続いて、単一のシーケンス番号で開始する必要があります。メディアフォーマットは、メディア（「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>
=の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つのモジュロ256だけ増分されなければなりません。レシーバは、必ずしも発行されたすべての機能セットが表示されないことがあり、したがってによるシーケンス番号のギャップに設定する機能を拒否してはなりません。シーケンス番号は、いずれかのセッションレベルまたは媒体レベルの属性として提供されなければならない（複数の能力セットができないため）、しかし、セッション記述におけるシーケンス番号属性の複数の発生があってはなりません。
Each capability description in the capability set is on the form:
能力セット内の各機能の説明は、フォーム上にあります：
a=cdsc: <cap-num> <media> <transport> <fmt list>
= CDSC：<キャップ-NUM> <メディア> <輸送> <FMTリスト>
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.
ここで、<キャップNUM>（両方含まれる）機能に番号を付けるために使用され、<メディア>、<輸送>、および<FMTリスト>は、SDPの「M =」行で定義した通りである。1〜255の整数です。機能の説明は、送信を指し、デフォルトで機能を受け取ります。能力セットを生成する際に、機能番号が最初の能力の説明に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>
CPAR A = <キャップパー> cparmin A = <キャップパー> cparmax A = <キャップパー>
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.
<キャップパー>はその完全 '<タイプ> = <値>' の形式で帯域情報（ "B ="）または属性は、（ "="）のいずれかである（[3]参照）。性能パラメータ行は、前の「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」属性は、通常使用されるべきです。提供される場合、それは、エンドポイントが、それが<キャップパー>指定された値に応じて、先行する「CDSC」行のメディアフォーマットをサポートしていることを宣言していることを意味します。これは、例えば、「のfmtp」パラメータを指定するために使用することができます。セッションネゴシエーションが<キャップパー>の値を考慮せずに行おうとすると、それが原因エンドポイントのサポートの欠如のために失敗することがあります。能力記述は、同じまたは異なるパラメータを説明ゼロ、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」属性を使用する必要があります。しかし、与えられたパラメータが複数回属性「cparmin」で説明されてはならない機能の説明では、ゼロ、1、または複数の「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」属性を使用する必要があります。しかし、与えられたパラメータが複数回属性「cparmax」で説明されてはならない機能の説明では、ゼロ、1、または複数の「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」属性を使用して表現することができます。単一の範囲は、与えられたパラメータに指定することができることを、以前のルールに従います。
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
V = 0 0 = - 25678 753849 IP4 128.96.41.1 T = 0、M =オーディオ3456 RTP / AVP 18 96 = rtpmap IN IP4 128.96.41.1のS = Cは= IN：96電話イベントA =のfmtp：96 0- 15,32-35 =のSQN：0 = CDSC：1つのオーディオRTP / AVP 0 18 96 = CPAR：A =のfmtp：96 0-16,32-35 = CDSC：4画像UDPTLのT38のA = CDSC。 5画像の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、UDPまたはTCPを使用して* T.38 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.
次は4 3以降のメディアフォーマットが第一能力記述に含まれているのに対し、指定された最初の能力番号は、1であることに留意されたいです。また、それは既にメディア（「M =」）行に指定されたように、ペイロードタイプ96のためのrtpmapは、能力の記述に含まれていなかったことに注意してください。逆に、当然の機能の説明に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
V = 0 0 = - 25678 753849 IP4 IN 128.96.41.1のS = Cは= IP4 IN 128.96.41.1 T = 0、M =オーディオ3456 RTP / AVP 18 =をSQN：0 = CDSC：1オーディオRTP / AVP 0 18 M =映像3458 RTP / AVP 31 = CDSC：3ビデオ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.
*オーディオメディアストリームのための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:
2つのメディアフォーマットが第一能力記述に含まれていたので、次は、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
V = 0 0 = - 25678 753849 IP4 IN 128.96.41.1のS = Cは= IP4 IN 128.96.41.1 T = 0 0 = SQN：0 = CDSC：1オーディオRTP / AVP 0 18 = CDSC：3ビデオRTP / AVP 31〜34、M =オーディオ3456 RTP / AVP 18メートル=映像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-フィールド」（属性名）の次の新しい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ロングフォーム名：シーケンス番号属性名。属性の種類：セッションレベルとメディアレベル。文字セットの対象：いいえ目的：能力セットの番号。適切な値：第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ロングフォーム名：機能の説明を。属性の種類：セッションレベルとメディアレベル。文字セットの対象：いいえ目的：能力セットで能力を説明してください。適切な値：第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ロングフォーム名：能力パラメータ行属性名。属性の種類：セッションレベルとメディアレベル。文字セットの対象：いいえ目的：機能の説明パラメータを提供します。適切な値：第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ロングフォーム名：最小の能力パラメータ行を。属性の種類：セッションレベルとメディアレベル。文字セットの対象：いいえ目的：最小能力記述パラメータを提供します。適切な値：第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。属性の種類：セッションレベルとメディアレベル。文字セットの対象：いいえ目的：最大能力記述パラメータを提供します。適切な値：第3節を参照してください。
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[1]ブラドナーの、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Handley, M. and V. Jacobson, "SDP: session description protocol", Request for Comments 2327, April 1998.
[3]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、コメント2327、1998年4月の要求。
[4] Kutscher, Ott, Bormann and Curcio, "Requirements for Session Description and Capability Negotiation", Work in Progress.
[4] Kutscher、オット、ボルマンとCurcio、 "セッション記述と能力ネゴシエーションのための要件"、ProgressのWork。
[5] Kutscher, Ott and Borman, "Session Description and Capability Negotiation", Work in Progress.
[5] Kutscher、オットとボーマン、「セッション記述と能力交渉」が進行中で働いています。
[6] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: session initiation protocol", RFC 2543, March 1999.
[6]ハンドレー、M.、Schulzrinneと、H.、学生はE.およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、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]アランゴ、M.、デュガン、A.、エリオット、I.、のHuitema、C.及びS.ピケット、 "メディアゲートウェイ制御プロトコル（MGCP）バージョン1.0"、RFC 2705、1999年10月。
[8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", Work in Progress.
[8]ローゼンバーグ、J.、およびH. Schulzrinneと、 "SDPとオファー/アンサーモデル"、ProgressのWork。
[9] ITU-T Recommendation T.38 Annex D, "SIP/SDP Call Establishment Procedures".
[9] ITU-T勧告T.38の付属資料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のプロジェクトに触発されました。著者はこの仕様を改善するために、多くの詳細なコメントや提案を提供しイェルクオットとジョナサンローゼンバーグを認識し、感謝したいと思います。コリンパーキンス、oriTをレヴィンとトム・テイラーは、同様に貴重なフィードバックを提供します。
Flemming Andreasen Cisco Systems 499 Thornall Street, 8th floor Edison, NJ EMail: fandreas@cisco.com
フレミングAndreasenのシスコシステムズ499 Thornallストリート、8階のエジソン、NJ Eメール：fandreas@cisco.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。