RFC3407 日本語訳

Network Working Group                                       F. Andreasen
Request for Comments: 3407                                 Cisco Systems
Category: Standards Track                                   October 2002

Andreasenがコメントのために要求するワーキンググループF.をネットワークでつないでください: 3407年のシスコシステムズカテゴリ: 標準化過程2002年10月

   Session Description Protocol (SDP) Simple Capability Declaration

セッションの記述のプロトコルの(SDP)簡単な能力宣言

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

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が最小量の、そして、遅れているコンパチブル能力宣言メカニズムを提供するのを可能にする1セットのSession記述プロトコル(SDP)属性を定義します。 その後のセッション交渉(このドキュメントの範囲の外の手段で行われる)に入力されるようにそのような能力宣言を使用できます。 これはSDPの次の世代によって扱われて、また、SDPngとして知られていることにおける一般的な能力交渉問題に簡単で限られた解決法を提供します。

1. Conventions Used in this Document

1. このDocumentのコンベンションUsed

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC-2119[2]で説明されるように本書では解釈されることであるべきですか?

2. Introduction

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

Session記述プロトコル(SDP)[3]はセッション発表(セッション招待、および他の形式のマルチメディアセッション開始)の目的のためのマルチメディアセッションについて説明します。 SDPが能力交渉を提供することを意図しませんでした。 しかしながら、この必要性がますます重要になるのに従って、仕事はセッション記述と能力交渉の両方をサポートする「次の世代SDP」(SDPng)[4、5]で始まりました。 SDPngは後方にSDPと互換性があった状態であるように予期されません、そして、初期段階に、現在、SDPngへの作業があります。 しかしながら、他のいくつかのプロトコル(例えば、SIP[6]とメディアゲートウェイControlプロトコル(MGCP)[7])が、SDPを使用して、ありそうです。

Andreasen                   Standards Track                     [Page 1]

RFC 3407           SDP Simple Capability Declaration        October 2002

能力宣言2002年10月に簡単なAndreasen標準化過程[1ページ]RFC3407SDP

   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.

例えば、終点は、T.38ファックスリレー(UDPかTCPの上の)と同様にG.711がオーディオであるとサポートするかもしれません(RTPの上で)。 終点が同時に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で1セットの新しい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の現在のユーザに面するのにおいて最も緊急の問題に意図します。

3. Simple Capability Declaration Attributes

3. 簡単な能力宣言属性

   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

SDP Simple Capability Declaration(simcap)は1セットのSDP属性によって定義されます。 これらの属性は終点の完全なメディア能力について説明する能力セットを一緒に、形成します。 問題のセッションのために終点によって発行されたどんな前の能力セットももう適用されません。 能力セットは一連番号と1つ以上の能力記述から成ります。 そのようなそれぞれの能力記述は、タイプとメディア形式がサポートしたメディアを説明して、さらに能力を定義するために1つ以上の能力パラメタを含むかもしれません。 セッション記述は1つ以上の能力セットを含んではいけなくて、しかしながら、能力セットはセッションとメディアレベルの両方で能力について説明できます。 セッションレベルで提供された能力記述はメディアのすべてのメディアの流れに適用されます。

Andreasen                   Standards Track                     [Page 2]

RFC 3407           SDP Simple Capability Declaration        October 2002

能力宣言2002年10月に簡単なAndreasen標準化過程[2ページ]RFC3407SDP

   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.

ところが、タイプは、メディアレベルで提供された能力記述がその特定のメディアストリームだけに適用されるのを示しました。 セッション能力とメディアが能力を流すとき、私たちはそれぞれこれらを参照します。 それが適用されるメディアストリームと同じメディアタイプにはメディアストリーム能力があるかもしれません。

   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=」)系列に含まれているなら定義上、より明確に、セッション能力にメディア形式を含まなければならない、さもなければ、メディアはそのメディア系列のための能力を流します。 同輩とのセッションのときにそれらのメディアが形式であるとサポートすることができるなら、終点は能力に追加メディア形式を含むかもしれません。 終点はそれが特定のセッションのときに使用できないのを知っている能力を含んではいけません。 能力がもう片方の終点とメディアストリームを交渉する後の試みでセットしたのでメディア形式のどれかを含んでいて、終点が別の終点5月の使用から能力セットを受けて、例えば、申し出/答えを使用して、[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>

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であるに違いありません(ゼロ)、そして、それをそれぞれの新しい能力セットとの法256が終点で発行した1つ増加しなければなりません。 受信機は、すべての能力セットが発行されるのを必ず見るかもしれないというわけではなくて、したがって、一連番号におけるギャップのため設定された能力を拒絶してはいけません。 セッションレベルかメディアレベル属性として一連番号を提供しなければならなくて、しかしながら、セッション記述における、一連番号属性の1回以上の発生があるはずがありません(1つ以上の能力セットがあるはずがないので)。

Andreasen                   Standards Track                     [Page 3]

RFC 3407           SDP Simple Capability Declaration        October 2002

能力宣言2002年10月に簡単なAndreasen標準化過程[3ページ]RFC3407SDP

   Each capability description in the capability set is on the form:

フォームの上に能力セットにおけるそれぞれの能力記述があります:

     a=cdsc: <cap-num> <media> <transport> <fmt list>

a=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.

<輸送>、および<fmtリスト>はSDP「m=」系列でnumに帽子をかぶらせている<>がどこの数の能力、および<メディア>まで使用される1〜255(ともに含まれている)の整数であるかが定義されます。 記述が参照する能力は、aに発信して、デフォルトで能力を受けます。 能力セットを生成するとき、能力番号から最初の能力記述で1から始まって、それぞれのその後の能力記述のために<fmtリスト>のメディア形式の数で増加しなければなりません。 <fmtリスト>のメディア形式は左から右まで付番されます。 しかしながら、1つの能力セットの受信機は能力番号におけるギャップによる能力記述を拒絶してはいけません。 能力番号はこの仕様の外で手段で能力セット(一連番号によって参照をつけられるように)の文脈の中の参照に使用されるかもしれない便利なハンドルに特定の能力を供給します。

   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>

a=cpar: <上限平価>a=cparmin: <上限平価>a=cparmax: <上限平価>。

   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"属性系列のための追加パラメタを提供します。 能力記述SHOULDのための能力パラメタ行はすぐに、彼らが言及する"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"属性系列が同じであるか異なったパラメタについて説明する場合、能力記述はゼロを含むかもしれません。 代替手段を指定するのに一度より多くの同じパラメタについて説明するのを使用できます。

Andreasen                   Standards Track                     [Page 4]

RFC 3407           SDP Simple Capability Declaration        October 2002

能力宣言2002年10月に簡単なAndreasen標準化過程[4ページ]RFC3407SDP

   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"属性を使用することによって、数値の範囲を言い表すことができます。 それは与えられたパラメタにただ一つの範囲しか指定できないという前の規則から続きます。

   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のメディアの流れが全くありません、そして、次に、能力記述が、メディアストリームのどれがそうするのに申し込むかは、未定義です(あるメディアストリームしかなければ、除いてください)。 それはしたがって、RECOMMENDED、能力が代わりにメディアレベルで提供されるそのそのようなものです。

   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

0 0v=0o=-25678 753849IN IP4 128.96.41.1 s=c=IN IP4 128.96.41.1t=m=オーディオの3456RTP/AVP18 96a=rtpmap: 96 電話イベントa=fmtp: 96 0-15、32-35a=sqn: 0a=cdsc: 1 オーディオのRTP/AVP0 18 96a=cpar: a=fmtp: 96 0-16、32-35a=cdsc: 4イメージudptl t38 a=cdsc: 5イメージtcp t38

Andreasen                   Standards Track                     [Page 5]

RFC 3407           SDP Simple Capability Declaration        October 2002

能力宣言2002年10月に簡単なAndreasen標準化過程[5ページ]RFC3407SDP

   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:

このセッション記述の送付者は、現在、0-15に32-35に電話イベントと同様にG.729オーディオを送って、受け取る用意ができています。 その上、送付者がそう、以下をサポートすることができます。

   *  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を使用することでリレーを送ります。([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

v=0o=-25678 753849IN IP4 128.96.41.1 s=c=IN IP4 128.96.41.1tは0 0m=オーディオの3456RTP/AVP18a=sqnと等しいです: 0a=cdsc: 1 オーディオのRTP/AVP0 18mはビデオ3458RTP/AVP31a=cdscと等しいです: 3 ビデオRTP/AVP31 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:

最初の能力番号が指定したというメモは1ですが、次のことは3です、2つのメディア形式が最初の能力記述に含まれていたので。 また、一連番号がすなわち、全体の能力セット、オーディオとビデオの両方に適用して、したがって、一度供給されるだけであることに注意してください。 最終的に、メディア書式18と31が系列と能力が必要に応じて設定する両方のメディアで記載されていることに注意してください。 以下の通り等しく上のセッション記述を供給したかもしれません:

Andreasen                   Standards Track                     [Page 6]

RFC 3407           SDP Simple Capability Declaration        October 2002

能力宣言2002年10月に簡単なAndreasen標準化過程[6ページ]RFC3407SDP

     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=0o=-25678 753849IN IP4 128.96.41.1 s=c=IN IP4 128.96.41.1tは0 0a=sqnと等しいです: 0a=cdsc: 1 オーディオのRTP/AVP0 18a=cdsc: 3 3456年の18mの31 34mのビデオRTP/AVP=オーディオRTP/AVP=ビデオ3458RTP/AVP31

   i.e., with the capability set provided at the session-level.

すなわち、能力に、セットはセッションレベルで提供されました。

4. Security Considerations

4. セキュリティ問題

   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.

セキュリティ機密のパラメタの能力交渉をデリケートなプロセスであり、デザインの慎重な評価なしでするべきではありません、攻撃を格下げするために可能な敏感さを含んでいて。 能力再交渉の使用で、セッションは認証に関してデザイン心配なしでサービスの否定に影響されやすくなるかもしれません。

5. IANA Considerations

5. IANA問題

   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 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 Longは名前を形成します: 能力記述。 属性のタイプ: セッションレベルとメディアレベル。 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を見てください。

Andreasen                   Standards Track                     [Page 7]

RFC 3407           SDP Simple Capability Declaration        October 2002

能力宣言2002年10月に簡単なAndreasen標準化過程[7ページ]RFC3407SDP

   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を見てください。

6. Normative References

6. 引用規格

   [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
       9, RFC 2026, October 1996.

[1] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」

   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [3] Handley, M. and V. Jacobson, "SDP: session description protocol",
       Request for Comments 2327, April 1998.

[3] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、Comments2327、1998年4月のRequest。

7. Informative References

7. 有益な参照

   [4] Kutscher, Ott, Bormann and Curcio, "Requirements for Session
       Description and Capability Negotiation", Work in Progress.

[4] 「セッション記述と能力交渉のための要件」というクッチャー、オット、ボルマン、およびカーシオは進行中で働いています。

   [5] Kutscher, Ott and Borman, "Session Description and Capability
       Negotiation", Work in Progress.

[5] 「セッション記述と能力交渉」というクッチャー、オット、およびボーマンは進行中で働いています。

   [6] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
       "SIP: session initiation protocol", RFC 2543, March 1999.

[6] ハンドレー、M.、Schulzrinne、H.、学生、E.、およびJ.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、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.とデュガン、A.、エリオット、I.とHuitemaとC.とS.ピケット、「メディアゲートウェイコントロールは(MGCP)についてバージョン1インチ議定書の中で述べます、RFC2705、1999年10月。」

   [8] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
       SDP", Work in Progress.

[8] 「SDPの申し出/答えモデル」というローゼンバーグ、J.、およびH.Schulzrinneは進行中で働いています。

   [9] ITU-T Recommendation T.38 Annex D, "SIP/SDP Call Establishment
       Procedures".

[9] ITU-T推薦T.38はD、「一口/SDP呼設定手順」を付加します。

Andreasen                   Standards Track                     [Page 8]

RFC 3407           SDP Simple Capability Declaration        October 2002

能力宣言2002年10月に簡単なAndreasen標準化過程[8ページ]RFC3407SDP

8. Acknowledgments

8. 承認

   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レヴィン、およびトム・テイラーはまた、有益なフィードバックを提供しました。

9. Author's Address

9. 作者のアドレス

   Flemming Andreasen
   Cisco Systems
   499 Thornall Street, 8th floor
   Edison, NJ
   EMail: fandreas@cisco.com

フレミングAndreasenシスコシステムズ499Thornall通り、8階のエディソン、ニュージャージーEMail: fandreas@cisco.com

Andreasen                   Standards Track                     [Page 9]

RFC 3407           SDP Simple Capability Declaration        October 2002

能力宣言2002年10月に簡単なAndreasen標準化過程[9ページ]RFC3407SDP

10. Full Copyright Statement

10. 完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

Andreasen                   Standards Track                    [Page 10]

Andreasen標準化過程[10ページ]