RFC3388 日本語訳

Network Working Group                                       G. Camarillo
Request for Comments: 3388                                   G. Eriksson
Category: Standards Track                                      J. Holler
                                                                Ericsson
                                                          H. Schulzrinne
                                                     Columbia University
                                                           December 2002

コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 3388年のG.エリクソンカテゴリ: 標準化過程J.叫び声エリクソンH.Schulzrinneコロンビア大学2002年12月

   Grouping of Media Lines in the Session Description Protocol (SDP)

セッション記述プロトコルにおける、メディア線の組分け(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 two Session Description Protocol (SDP)
   attributes: "group" and "mid".  They allow to group together several
   "m" lines for two different purposes: for lip synchronization and for
   receiving media from a single flow (several media streams) that are
   encoded in different formats during a particular session, on
   different ports and host interfaces.

このドキュメントは2Session記述プロトコル(SDP)属性を定義します: 「グループ」で「中間です」。 彼らは2つの異なる役割のためにいくつかの「m」系列を一緒に分類させます: 唇同期とただ一つの流れ(いくつかのメディアストリーム)からの異なったポートとホスト・インターフェースの特定のセッションの間異なった形式でコード化されるメディアを受け取るために。

Table of Contents

目次

   1. Introduction..................................................  2
   2. Terminology...................................................  2
   3. Media Stream Identification Attribute.........................  3
   4. Group Attribute...............................................  3
   5. Use of "group" and "mid"......................................  3
   6. Lip Synchronization (LS)......................................  4
      6.1 Example of LS.............................................  5
   7. Flow Identification (FID).....................................  5
      7.1 SIP and Cellular Access...................................  6
      7.2 DTMF Tones................................................  6
      7.3 Media Flow Definition.....................................  6
      7.4 FID Semantics.............................................  7
          7.4.1 Examples of FID.....................................  8
      7.5 Scenarios that FID does not Cover........................  11

1. 序論… 2 2. 用語… 2 3. メディアは識別属性を流します… 3 4. 属性を分類してください… 3 5. 「グループ」で「中間」の使用… 3 6. 唇同期(LS)… 4 LSに関する6.1の例… 5 7. 流れ識別(くさび)… 5 7.1 一口とセルアクセサリー… 6 7.2 DTMFは調子を変えます… 6 7.3 メディアフロー定義… 6 7.4 くさび意味論… 7 7.4 くさびに関する.1の例… 8 Coverではなく、FIDがする7.5のシナリオ… 11

Camarillo et. al.           Standards Track                     [Page 1]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[1ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

          7.5.1 Parallel Encoding Using Different Codecs...........  11
          7.5.2 Layered Encoding...................................  12
          7.5.3 Same IP Address and Port Number....................  12
   8. Usage of the "group" Attribute in SIP........................  13
      8.1 Mid Value in Answers.....................................  13
          8.1.1 Example............................................  14
      8.2 Group Value in Answers...................................  15
          8.2.1 Example............................................  15
      8.3 Capability Negotiation...................................  16
          8.3.1 Example............................................  17
      8.4 Backward Compatibility...................................  17
          8.4.1 Offerer does not Support "group"...................  17
          8.4.2 Answerer does not Support "group"..................  17
   9.    Security Considerations...................................  18
   10.   IANA Considerations.......................................  18
   11.   Acknowledgements..........................................  19
   12.   References................................................  19
   13.   Authors' Addresses........................................  20
   14.   Full Copyright Statement..................................  21

7.5.1 異なったコーデックを使用して、コード化に沿ってください… 11 7.5 .2はコード化を層にしました… 12 7.5 .3 同じIPアドレスとポートナンバー… 12 8. 一口における「グループ」属性の用法… 13 8.1 答えにおける中間の値… 13 8.1 .1の例… 14 8.2 答えにおける値を分類してください… 15 8.2 .1の例… 15 8.3 能力交渉… 16 8.3 .1の例… 17 8.4 後方の互換性… 17 8.4 .1申出人はどんなSupportにも「分類しません」… 17 8.4 .2 AnswererはどんなSupportにも「分類しません」… 17 9. セキュリティ問題… 18 10. IANA問題… 18 11. 承認… 19 12. 参照… 19 13. 作者のアドレス… 20 14. 完全な著作権宣言文… 21

1. Introduction

1. 序論

   An SDP session description typically contains one or more media lines
   - they are commonly known as "m" lines.  When a session description
   contains more than one "m" line, SDP does not provide any means to
   express a particular relationship between two or more of them.  When
   an application receives an SDP session description with more than one
   "m" line, it is up to the application what to do with them.  SDP does
   not carry any information about grouping media streams.

SDPセッション記述は1つ以上のメディア系列を通常含んでいます--それらは「m」系列として一般的に知られています。 セッション記述が1つ以上の「m」系列を含んでいる場合、SDPはそれらの2つ以上の間の特定の関係を言い表すどんな手段も提供しません。 アプリケーションが1つ以上の「m」系列でSDPセッション記述を受けるとき、それはアプリケーションまで達しています。それらでそうするべきこと。 SDPは、メディアストリームを分類しながら、少しの情報も持ち歩きません。

   While in some environments this information can be carried out of
   band, it would be desirable to have extensions to SDP that allow the
   expression of how different media streams within a session
   description relate to each other.  This document defines such
   extensions.

いくつかの環境で、バンドからこの情報を運ぶことができる間、セッション記述の中の異なったメディアストリームがどう互いに関連するかに関する式を許容するSDPに拡張子を持っているのは望ましいでしょう。 このドキュメントはそのような拡大を定義します。

2. Terminology

2. 用語

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
   and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
   [1] and indicate requirement levels for compliant implementations.

本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[1]ということであり、対応する実装のために要件レベルを示すべきであるかをさせましょう。

Camarillo et. al.           Standards Track                     [Page 2]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[2ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

3. Media Stream Identification Attribute

3. メディアは識別属性を流します。

   A new "media stream identification" media attribute is defined.  It
   is used for identifying media streams within a session description.
   Its formatting in SDP [2] is described by the following BNF:

メディアが結果と考える新しい「メディアは識別を流すこと」が定義されます。 それは、セッション記述の中でメディアストリームを特定するのに使用されます。 SDP[2]の形式は以下のBNFによって説明されます:

        mid-attribute      = "a=mid:" identification-tag
        identification-tag = token

中間の属性=、「a=中間:、」 識別票識別票はトークンと等しいです。

   The identification tag MUST be unique within an SDP session
   description.

識別票はSDPセッション記述の中でユニークであるに違いありません。

4. Group Attribute

4. グループ属性

   A new "group" session-level attribute is defined.  It is used for
   grouping together different media streams.  Its formatting in SDP is
   described by the following BNF:

新しい「グループ」セッションレベル属性は定義されます。 一緒に分類するのに使用されて、異なったメディアストリームSDPの形式が以下のBNFによって説明されるということです:

        group-attribute    = "a=group:" semantics
                             *(space identification-tag)
        semantics          = "LS" | "FID"

グループ属性=「=は以下を分類します」。 意味論*(スペース識別票)意味論は「LS」と等しいです。| 「くさび」

   This document defines two standard semantics: LS (Lip
   Synchronization) and FID (Flow Identification).  Further semantics
   need to be defined in a standards-track document.  However, defining
   new semantics apart from LS and FID is discouraged.  Instead, it is
   RECOMMENDED to use other session description mechanisms such as
   SDPng.

このドキュメントは2の標準の意味論を定義します: LS(唇同期)とくさび(流れ識別)。 さらなる標準化過程文書で定義されるべき意味論の必要性。 しかしながら、LSとFIDは別として新しい意味論を定義するのはお勧めできないです。 代わりに、それはSDPngなどの他のセッション記述メカニズムを使用するRECOMMENDEDです。

5. Use of "group" and "mid"

5. 「グループ」で「中間」の使用

   All the "m" lines of a session description that uses "group" MUST be
   identified with a "mid" attribute whether they appear in the group
   line(s) or not.  If a session description contains at least one "m"
   line that has no "mid" identification the application MUST NOT
   perform any grouping of media lines.

それらがグループ系列に現れるか否かに関係なく、用途が「分類する」セッション記述のすべての「m」系列を「中間」の属性と同一視しなければなりません。 セッション記述が「中間」の識別を全く持っていない少なくとも1つの「m」系列を含んでいるなら、アプリケーションはメディア系列のどんな組分けも実行してはいけません。

   "a=group" lines are used to group together several "m" lines that are
   identified by their "mid" attribute.  "a=group" lines that contain
   identification-tags that do not correspond to any "m" line within the
   session description MUST be ignored.  The application acts as if the
   "a=group" line did not exist.  The behavior of an application
   receiving an SDP with grouped "m" lines is defined by the semantics
   field in the "a=group" line.

「=グループ」系列は、それらの「中間」の属性によって特定されるいくつかの「m」系列を一緒に分類するのに使用されます。 セッション記述の中でどんな「m」系列にも対応しない識別票を含む「=グループ」系列を無視しなければなりません。 まるで「=は分類する」という台詞が存在していないかのようにアプリケーションが行動します。 分類された「m」系列でSDPを受けるアプリケーションの働きは意味論分野によって「=は分類する」という台詞で定義されます。

Camarillo et. al.           Standards Track                     [Page 3]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[3ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

   There MAY be several "a=group" lines in a session description.  All
   the "a=group" lines of a session description MAY or MAY NOT use the
   same semantics.  An "m" line identified by its "mid" attribute MAY
   appear in more than one "a=group" line as long as the "a=group" lines
   use different semantics.  An "m" line identified by its "mid"
   attribute MUST NOT appear in more than one "a=group" line using the
   same semantics.

セッション記述にはいくつかの「=グループ」系列があるかもしれません。 すべてのセッション記述の系列が同じように使用するかもしれない「=グループ」意味論。 「中間」の属性によって特定された「m」系列は「=グループ」が系列が使用する「=グループ」異なった意味論と同じくらい長い間裏打ちする1つ以上に現れるかもしれません。 「中間」の属性によって特定された「m」系列は、「=グループ」が裏打ちする1つ以上に同じ意味論を使用することで現れてはいけません。

6. Lip Synchronization (LS)

6. 唇同期(LS)

   An application that receives a session description that contains "m"
   lines that are grouped together using LS semantics MUST synchronize
   the playout of the corresponding media streams.  Note that LS
   semantics not only apply to a video stream that has to be
   synchronized with an audio stream.  The playout of two streams of the
   same type can be synchronized as well.

LS意味論を使用することで一緒に分類される「m」系列を含むセッション記述を受けるアプリケーションは対応するメディアストリームの再生を同期させなければなりません。LS意味論がオーディオストリームと同期しなければならないビデオストリームに適用されるだけではないことに注意してください。 また、同じタイプの2つの流れの再生は同期できます。

   For RTP streams synchronization is typically performed using RTCP,
   which provides enough information to map time stamps from the
   different streams into a wall clock.  However, the concept of media
   stream synchronization MAY also apply to media streams that do not
   make use of RTP.  If this is the case, the application MUST recover
   the original timing relationship between the streams using whatever
   available mechanism.

RTPストリームにおいて、同期は、RTCP(タイムスタンプを異なったストリームから柱時計に写像できるくらいの情報を提供する)を使用することで通常実行されます。 しかしながら、また、メディアストリーム同期の概念はRTPを利用しないメディアストリームに適用されるかもしれません。 これがそうであるなら、どんな利用可能なメカニズムも使用して、アプリケーションはストリームの間のオリジナルのタイミング関係を回復しなければなりません。

Camarillo et. al.           Standards Track                     [Page 4]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[4ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

6.1 Example of LS

6.1 LSに関する例

   The following example shows a session description of a conference
   that is being multicast.  The first media stream (mid:1) contains the
   voice of the speaker who speaks in English.  The second media stream
   (mid:2) contains the video component and the third (mid:3) media
   stream carries the translation to Spanish of what he is saying.  The
   first and the second media streams MUST be synchronized.

以下の例は存在マルチキャストである会議のセッション記述を示しています。 最初のメディアが流れる、(中間、: 1は)英語で話すスピーカーの声を含んでいます。 2番目のメディアが流れる、(中間、: 2が)ビデオの部品と3番目を含んでいる、(中間、: 3)メディアストリームは彼が言っていることに関するスペイン語まで翻訳を運びます。 1番目と2番目のメディアストリームは同期しなければなりません。

       v=0
       o=Laura 289083124 289083124 IN IP4 one.example.com
       t=0 0
       c=IN IP4 224.2.17.12/127
       a=group:LS 1 2
       m=audio 30000 RTP/AVP 0
       a=mid:1
       m=video 30002 RTP/AVP 31
       a=mid:2
       m=audio 30004 RTP/AVP 0
       i=This media stream contains the Spanish translation
       a=mid:3

ローラ289083124 289083124IN IP4 1.example.com t=0 0c=IN IP4 224.2.17.12/127a=v=0o=グループ: LS=オーディオの30000RTP/AVP0 1 2m aが: 1mの中間の=ビデオと等しい、30002RTP/AVP31aが: 2mの中間の=オーディオの30004RTP/AVPと等しい、0、i、= このメディアストリームはa=中間であることでスペインの翻訳を含んでいます:、3

   Note that although the third media stream is not present in the group
   line, it still MUST contain a mid attribute (mid:3), as stated
   before.

3番目のメディアストリームがグループ系列では存在していませんが、まだ中間の属性を含まなければならないことに注意してください、(中間、: 3) 以前述べられるとして。

7. Flow Identification (FID)

7. 流れ識別(くさび)

   An "m" line in an SDP session description defines a media stream.
   However, SDP does not define what a media stream is.  This definition
   can be found in the RTSP specification. The RTSP RFC [5] defines a
   media stream as "a single media instance, e.g., an audio stream or a
   video stream as well as a single whiteboard or shared application
   group.  When using RTP, a stream consists of all RTP and RTCP packets
   created by a source within an RTP session".

SDPセッション記述における「m」系列はメディアストリームを定義します。 しかしながら、SDPは、メディアストリームが何であるかを定義しません。 RTSP仕様でこの定義を見つけることができます。 RTSP RFC[5]は「単一のホワイトボードか共有された応用グループと同様にただ一つのメディアインスタンス、例えば、オーディオストリームまたはビデオストリーム」とメディアストリームを定義します。 「RTPを使用するとき、ストリームはRTPセッション以内にソースによって作成されたすべてのRTPとRTCPパケットから成ります。」

   This definition assumes that a single audio (or video) stream maps
   into an RTP session.  The RTP RFC [6] defines an RTP session as
   follows: "For each participant, the session is defined by a
   particular pair of destination transport addresses (one network
   address plus a port pair for RTP and RTCP)".

この定義は、ただ一つのオーディオ(または、ビデオ)がRTPセッションまで地図を流すと仮定します。 RTP RFC[6]は以下のRTPセッションを定義します: 「各関係者に関して、セッションは送付先輸送アドレス(RTPとRTCPのための1つのネットワーク・アドレスとポート組)の特定の組によって定義されます。」

   While the previous definitions cover the most common cases, there are
   situations where a single media instance, (e.g., an audio stream or a
   video stream) is sent using more than one RTP session.  Two examples
   (among many others) of this kind of situation are cellular systems
   using SIP [3] and systems receiving DTMF tones on a different host
   than the voice.

前の定義は最も一般的なケースをカバーしていますが、状況が1つ以上のRTPセッションがただ一つのメディアインスタンスか、(例えば、オーディオストリームかビデオストリーム)を使用させられるところにあります。 この種類の状況に関する2つの例(多くの他のものの)が声より異なったホストの上でDTMFトーンを受けながらSIP[3]とシステムを使用するセルラ方式です。

Camarillo et. al.           Standards Track                     [Page 5]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[5ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

7.1 SIP and Cellular Access

7.1 一口とセルアクセス

   Systems using a cellular access and SIP as a signalling protocol need
   to receive media over the air.  During a session the media can be
   encoded using different codecs.  The encoded media has to traverse
   the radio interface.  The radio interface is generally characterized
   by being bit error prone and associated with relatively high packet
   transfer delays.  In addition, radio interface resources in a
   cellular environment are scarce and thus expensive, which calls for
   special measures in providing a highly efficient transport.  In order
   to get an appropriate speech quality in combination with an efficient
   transport, precise knowledge of codec properties are required so that
   a proper radio bearer for the RTP session can be configured before
   transferring the media.  These radio bearers are dedicated bearers
   per media type, i.e., codec.

合図プロトコルとしてセルアクセスとSIPを使用するシステムは、空気の上にメディアを受け取る必要があります。 セッションの間、異なったコーデックを使用することでメディアをコード化できます。 コード化されたメディアはラジオインタフェースを横断しなければなりません。 一般に、ラジオインタフェースは、比較的高いパケット転送遅れに傾向があって関連している噛み付いている誤りであることで特徴付けられます。 さらに、セル環境におけるラジオインタフェースリソースは、不十分であって、その結果、高価です(高能率的な輸送を提供する際に特別な測定を求めます)。 効率的な輸送と組み合わせて適切なスピーチ品質を得て、コーデックの特性に関する正確な知識が、メディアを移す前にRTPセッションのための適切なラジオ運搬人を構成できるくらい必要です。 すなわち、メディアタイプ、コーデックあたりこれらのラジオ運搬人はひたむきな運搬人です。

   Cellular systems typically configure different radio bearers on
   different port numbers.  Therefore, incoming media has to have
   different destination port numbers for the different possible codecs
   in order to be routed properly to the correct radio bearer.  Thus,
   this is an example in which several RTP sessions are used to carry a
   single media instance (the encoded speech from the sender).

セルラ方式は異なったポートナンバーで異なったラジオ運搬人を通常構成します。 したがって、入って来るメディアには異なった可能なコーデックの異なった仕向港番号が、適切に正しいラジオ運搬人に発送されるためになければなりません。 したがって、これはいくつかのRTPセッションがただ一つのメディアインスタンス(送付者からのコード化されたスピーチ)を運ぶのに使用される例です。

7.2 DTMF Tones

7.2 DTMFトーン

   Some voice sessions include DTMF tones.  Sometimes the voice handling
   is performed by a different host than the DTMF handling.  It is
   common to have an application server in the network gathering DTMF
   tones for the user while the user receives the encoded speech on his
   user agent.  In this situations it is necessary to establish two RTP
   sessions: one for the voice and the other for the DTMF tones.  Both
   RTP sessions are logically part of the same media instance.

いくつかの声のセッションがDTMFトーンを含んでいます。 時々、声の取り扱いはDTMF取り扱いと異なったホストによって実行されます。 ユーザは彼のユーザエージェントに関するコード化されたスピーチを受け取りますが、ユーザのためのネットワーク集会DTMFトーンにおけるアプリケーション・サーバーを持っているのは一般的です。 この状況で、2つのRTPセッションを確立するのが必要です: 声のための1つとDTMFのためのもう片方が調子を変えます。 両方のRTPセッションは論理的にそうです。同じメディアインスタンスの一部。

7.3 Media Flow Definition

7.3 メディアフロー定義

   The previous examples show that the definition of a media stream in
   [5] do not cover some scenarios.  It cannot be assumed that a single
   media instance maps into a single RTP session.  Therefore, we
   introduce the definition of a media flow:

前の例は、[5]のストリームがそうしないメディアの定義がいくつかのシナリオをカバーするのを示します。 ただ一つのメディアインスタンスが独身のRTPにセッションを写像すると思うことができません。 したがって、私たちはメディア流動の定義を導入します:

   Media flow consists of a single media instance, e.g., an audio stream
   or a video stream as well as a single whiteboard or shared
   application group.  When using RTP, a media flow comprises one or
   more RTP sessions.

メディア流動は単一のホワイトボードか共有された応用グループと同様にただ一つのメディアインスタンス、例えば、オーディオストリームまたはビデオストリームから成ります。 RTPを使用するとき、メディア流動は1つ以上のRTPセッションを包括します。

Camarillo et. al.           Standards Track                     [Page 6]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[6ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

7.4 FID Semantics

7.4 くさび意味論

   Several "m" lines grouped together using FID semantics form a media
   flow.  A media agent handling a media flow that comprises several "m"
   lines MUST send a copy of the media to every "m" line part of the
   flow as long as the codecs and the direction attribute present in a
   particular "m" line allow it.

FID意味論を使用することで一緒に分類されたいくつかの「m」系列がメディア流動を形成します。 特定の「m」系列における現在のコーデックと方向属性がそれを許容する限り、いくつかの「m」系列を包括するメディア流動を扱っているメディアエージェントは流れのあらゆる「m」系列部分にメディアのコピーを送らなければなりません。

   It is assumed that the application uses only one codec at a time to
   encode the media produced.  This codec MAY change dynamically during
   the session, but at any particular moment only one codec is in use.

アプリケーションがメディアが生産したエンコードに一度に1つのコーデックだけを使用すると思われます。 このコーデックはセッションの間ダイナミックに変化するかもしれませんが、どんな特定の瞬間の唯一のものでも、コーデックは使用中です。

   The application encodes the media using the current codec and checks
   one by one all the "m" lines that are part of the flow.  If a
   particular "m" line contains the codec being used and the direction
   attribute is "sendonly" or "sendrecv", a copy of the encoded media is
   sent to the address/port specified in that particular media stream.
   If either the "m" line does not contain the codec being used or the
   direction attribute is neither "sendonly" nor "sendrecv", nothing is
   sent over this media stream.

アプリケーションは、現在のコーデックを使用することでメディアをコード化して、流れの一部であるすべての「m」系列をひとつずつチェックします。 方向属性が特定の「m」系列が使用されるコーデックを含んでいて、"sendonly"か"sendrecv"であるなら、その特定のメディアストリームで指定されたアドレス/ポートにコード化されたメディアのコピーを送ります。 方向属性が「m」系列が使用されるコーデックを含んでいないか、"sendonly"でなくてまた"sendrecv"でないなら、このメディアストリームの上に何も送りません。

   The application typically ends up sending media to different
   destinations (IP address/port number) depending on the codec used at
   any moment.

いつ何時使用されたコーデックによって、アプリケーションは結局、異なった目的地(IPアドレス/ポートナンバー)にメディアを通常送ります。

Camarillo et. al.           Standards Track                     [Page 7]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[7ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

7.4.1 Examples of FID

7.4.1 くさびに関する例

   The session description below might be sent by a SIP user agent using
   a cellular access.  The user agent supports GSM on port 30000 and AMR
   on port 30002.  When the remote party sends GSM, it will send RTP
   packets to port number 30000.  When AMR is the codec chosen, packets
   will be sent to port 30002.  Note that the remote party can switch
   between both codecs dynamically in the middle of the session.
   However, in this example, only one media stream at a time carries
   voice.  The other remains "muted" while its corresponding codec is
   not in use.

以下でのセッション記述は、セルアクセサリーを使用することでSIPユーザエージェントによって送られるかもしれません。 ユーザエージェントはポート30000の上のGSMとポート30002の上のAMRをサポートします。 リモートパーティーがGSMを送るとき、それは、No.30000を移植するためにパケットをRTPに送るでしょう。 AMRが選ばれたコーデックであるときに、30002を移植するためにパケットを送るでしょう。 リモートパーティーがセッションの途中でダイナミックに両方のコーデックを切り換えることができることに注意してください。 しかしながら、この例では、1つのメディアストリームだけが一度に、声を通ります。 もう片方が対応するコーデックが使用中でない間、「音を消された」ままで残っています。

         v=0
         o=Laura 289083124 289083124 IN IP4 two.example.com
         t=0 0
         c=IN IP4 131.160.1.112
         a=group:FID 1 2
         m=audio 30000 RTP/AVP 3
         a=rtpmap:3 GSM/8000
         a=mid:1
         m=audio 30002 RTP/AVP 97
         a=rtpmap:97 AMR/8000
         a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2;
       mode-change-neighbor; maxframes=1
         a=mid:2

ローラ289083124 289083124IN IP4two v=0o=.example.com tが0 0c=IN IP4と等しい、131.160、.1、.112、=グループ: FID1 2m=オーディオの30000RTP/AVP3a=rtpmap: 3 中間の: 1m=オーディオの30002RTP/AVP97GSM/8000a=a=rtpmap: 97 AMR/8000a=fmtp: 97 モードに設定された=0、2、5、7。 モード変化期間=2。 モード変化隣人。 maxframes=1 a=中間:、2

   (The linebreak in the fmtp line accommodates RFC formatting
   restrictions; SDP does not have continuation lines.)

(fmtp系列におけるlinebreakはRFC形式制限に対応します; SDPには、継続行がありません。)

   In the previous example, a system receives media on the same IP
   address on different port numbers.  The following example shows how a
   system can receive different codecs on different IP addresses.

前の例では、システムは異なったポートナンバーに関する同じIPアドレスにメディアを受け取ります。 以下の例はシステムが異なったIPアドレスでどう異なったコーデックを受けることができるかを示しています。

Camarillo et. al.           Standards Track                     [Page 8]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[8ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

        v=0
        o=Laura 289083124 289083124 IN IP4 three.example.com
        t=0 0
        c=IN IP4 131.160.1.112
        a=group:FID 1 2
        m=audio 20000 RTP/AVP 0
        c=IN IP4 131.160.1.111
        a=rtpmap:0 PCMU/8000
        a=mid:1
        m=audio 30002 RTP/AVP 97
        a=rtpmap:97 AMR/8000
        a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2;
      mode-change-neighbor; maxframes=1
        a=mid:2

ローラ289083124 289083124IN IP4three v=0o=.example.com tが0 0c=IN IP4と等しい、131.160、.1、.112、=グループ: 1 2mのFID=オーディオの20000RTP/AVP、0、c、=IN IP4 131.160.1.111a=rtpmap: 0 中間の: 1m=オーディオの30002RTP/AVP97PCMU/8000a=a=rtpmap: 97 AMR/8000a=fmtp: 97 モードに設定された=0、2、5、7。 モード変化期間=2。 モード変化隣人。 maxframes=1 a=中間:、2

   (The linebreak in the fmtp line accomodates RFC formatting
   restrictions; SDP does not have continuation lines.)

(fmtp系列accomodates RFC形式制限におけるlinebreak; SDPには、継続行がありません。)

   The cellular terminal of this example only supports the AMR codec.
   However, many current IP phones only support PCM (payload 0).  In
   order to be able to interoperate with them, the cellular terminal
   uses a transcoder whose IP address is 131.160.1.111.  The cellular
   terminal includes in its SDP support for PCM at that IP address.
   Remote systems will send AMR directly to the terminal but PCM will be
   sent to the transcoder.  The transcoder will be configured (using
   whatever method) to convert the incoming PCM audio to AMR and send it
   to the terminal.

この例のセル端末はAMRコーデックをサポートするだけです。しかしながら、多くの現在のIP電話が、PCMが(ペイロード0)であるとサポートするだけです。 セル端末は、それらで共同利用できるように、IPアドレスがあるトランスコーダを使用します。131.160 .1 .111。 セル端末はそのIPアドレスにSDPにPCMのサポートを含んでいます。 リモートシステムは直接端末にAMRを送るでしょうが、PCMをトランスコーダに送るでしょう。 トランスコーダは、入って来るPCMオーディオをAMRに変換して、それを端末に送るために構成されるでしょう(どんなメソッドも使用します)。

   The next example shows how the "group" attribute used with FID
   semantics can indicate the use of two different codecs in the two
   directions of a bidirectional media stream.

次の例はFID意味論と共に使用される「グループ」属性がどう双方向のメディアストリームの2つの方向への2つの異なったコーデックの使用を示すことができるかを示しています。

       v=0
       o=Laura 289083124 289083124 IN IP4 four.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       a=group:FID 1 2
       m=audio 30000 RTP/AVP 0
       a=mid:1
       m=audio 30002 RTP/AVP 8
       a=recvonly
       a=mid:2

ローラ289083124 289083124IN IP4four v=0o=.example.com tが0 0c=IN IP4と等しい、131.160、.1、.112、=グループ: FID=オーディオの30000RTP/AVP0 1 2m aは中間の: 1m=オーディオの30002RTP/AVP8a=recvonly aと=中間であることで等しいです:、2

   A user agent that receives the SDP above knows that at a certain
   moment it can send either PCM u-law to port number 30000 or PCM A-law
   to port number 30002.  However, the media agent also knows that the
   other end will only send PCM u-law (payload 0).

上のSDPを受け取るユーザエージェントはNo.30002を移植するためにNo.30000かPCM A-法を移植するためにPCM u-法を送ることができるある瞬間にそれを知っています。 しかしながら、また、メディアエージェントは、もう一方の端がPCM u-法(ペイロード0)を送るだけであるのを知っています。

Camarillo et. al.           Standards Track                     [Page 9]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[9ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

   The following example shows a session description with different "m"
   lines grouped together using FID semantics that contain the same
   codec.

以下の例は、同じコーデックを含む系列がFID意味論を使用することで一緒に分類されたのを異なった「m」があるセッション記述に示します。

       v=0
       o=Laura 289083124 289083124 IN IP4 five.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       a=group:FID 1 2 3
       m=audio 30000 RTP/AVP 0
       a=mid:1
       m=audio 30002 RTP/AVP 8
       a=mid:2
       m=audio 20000 RTP/AVP 0 8
       c=IN IP4 131.160.1.111
       a=recvonly
       a=mid:3

ローラ289083124 289083124IN IP4five v=0o=.example.com tが0 0c=IN IP4と等しい、131.160、.1、.112、aはグループ: FID=オーディオの30000RTP/AVP0 1 2 3m aと=中間であることで等しいです: 1mはオーディオの30002RTP/AVP8aと=中間であることで等しいです: 2mがオーディオの20000RTP/AVPと等しい、0 8、c、IN IP4 131.160.1.111a=recvonly a=と中間であることで等しいです:、3

   At a particular point in time, if the media agent is sending PCM u-
   law (payload 0), it sends RTP packets to 131.160.1.112 on port 30000
   and to 131.160.1.111 on port 20000 (first and third "m" lines).  If
   it is sending PCM A-law (payload 8), it sends RTP packets to
   131.160.1.112 on port 30002 and to 131.160.1.111 on port 20000
   (second and third "m" lines).

30000を移植して、131.160に。メディアエージェントがPCM u法(ペイロード0)を送るなら、時間内にの特定のポイントでは、131.160へのパケットをRTPに送る、.1、.112、オンである、.1 .111 ポート20000(1番目と3番目の「m」系列)の上で。 30002を移植して、131.160に。A-法(ペイロード8)をPCMに送るなら、131.160へのパケットをRTPに送る、.1、.112、オンである、.1 .111 ポート20000(2番目と3番目の「m」系列)の上で。

   The system that generated the SDP above supports PCM u-law on port
   30000 and PCM A-law on port 30002.  Besides, it uses an application
   server whose IP address is 131.160.1.111 that records the
   conversation.  That is why the application server always receives a
   copy of the audio stream regardless of the codec being used at any
   given moment (it actually performs an RTP dump, so it can effectively
   receive any codec).

上のSDPを生成したシステムはポート30002の上でポート30000とPCM A-法でPCM u-法をサポートします。 そのうえ、それはIPアドレスがあるアプリケーション・サーバーを使用します。131.160 .1 会話を記録する.111。 それはアプリケーション・サーバーがコーデックにかかわらずいつなんどきでも使用されることでオーディオストリームのコピーをいつも受ける(実際にRTPダンプを実行するので、事実上、それはどんなコーデックも受けることができます)理由です。

   Remember that if several "m" lines grouped together using FID
   semantics contain the same codec the media agent MUST send media over
   several RTP sessions at the same time.

FID意味論を使用することで一緒に分類されたいくつかの「m」系列が同じコーデックを含むならメディアエージェントが同時にいくつかのRTPセッションにメディアを移動しなければならないのを覚えていてください。

Camarillo et. al.           Standards Track                    [Page 10]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[10ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

   The last example of this section deals with DTMF tones.  DTMF tones
   can be transmitted using a regular voice codec or can be transmitted
   as telephony events.  The RTP payload for DTMF tones treated as
   telephone events is described in RFC 2833 [7].  Below, there is an
   example of an SDP session description using FID semantics and this
   payload type.

このセクションに関する最後の例はDTMFトーンに対処します。 DTMFトーンを通常の音声コーデックを使用することで伝えることができるか、または電話イベントとして伝えることができます。 電話イベントとして扱われたDTMFトーンのためのRTPペイロードはRFC2833[7]で説明されます。 以下に、FID意味論とこのペイロードタイプを使用するSDPセッション記述に関する例があります。

       v=0
       o=Laura 289083124 289083124 IN IP4 six.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       a=group:FID 1 2
       m=audio 30000 RTP/AVP 0
       a=mid:1
       m=audio 20000 RTP/AVP 97
       c=IN IP4 131.160.1.111
       a=rtpmap:97 telephone-events
       a=mid:2

ローラ289083124 289083124IN IP4six v=0o=.example.com tが0 0c=IN IP4と等しい、131.160、.1、.112、aはグループ: FID=オーディオの30000RTP/AVP0 1 2m aと=中間であることで等しいです: 1mがオーディオの20000RTP/AVPと等しい、97、c、=IN IP4 131.160.1.111a=rtpmap: 97 電話イベントa=中間:、2

   The remote party would send PCM encoded voice (payload 0) to
   131.160.1.112 and DTMF tones encoded as telephony events to
   131.160.1.111.  Note that only voice or DTMF is sent at a particular
   point of time.  When DTMF tones are sent, the first media stream does
   not carry any data and, when voice is sent, there is no data in the
   second media stream.  FID semantics provide different destinations
   for alternative codecs.

リモートパーティーは.1の.112とDTMFトーンが電話イベントとして131.160にコード化した131.160へのコード化された声(ペイロード0)をPCMに送るでしょう。.1 .111。 声かDTMFだけが時間の特定のポイントで送られることに注意してください。 DTMFトーンを送るとき、最初のメディアストリームは少しのデータも運びません、そして、声を送るとき、2番目のメディアストリームにはデータが全くありません。 FID意味論は異なった目的地を代替のコーデックに提供します。

7.5 Scenarios that FID does not Cover

7.5 Coverではなく、FIDがするシナリオ

   It is worthwhile mentioning some scenarios where the "group"
   attribute using existing semantics (particularly FID) might seem to
   be applicable but is not.

既存の意味論(特にFID)を使用する「グループ」属性は適切であるように思えるかもしれませんが、ないいくつかのシナリオを参照する価値があります。

7.5.1 Parallel Encoding Using Different Codecs

7.5.1 異なったコーデックを使用する平行なコード化

   FID semantics are useful when the application only uses one codec at
   a time.  An application that encodes the same media using different
   codecs simultaneously MUST NOT use FID to group those media lines.
   Some systems that handle DTMF tones are a typical example of parallel
   encoding using different codecs.

アプリケーションが一度に1つのコーデックしか使用しないとき、FID意味論は役に立ちます。 同時に異なったコーデックを使用することで同じメディアをコード化するアプリケーションは、それらのメディア系列を分類するのにFIDを使用してはいけません。 DTMFトーンを扱ういくつかのシステムが異なったコーデックを使用する平行なコード化の典型的な例です。

   Some systems implement the RTP payload defined in RFC 2833, but when
   they send DTMF tones they do not mute the voice channel.  Therefore,
   in effect they are sending two copies of the same DTMF tone: encoded
   as voice and encoded as a telephony event.  When the receiver gets
   both copies, it typically uses the telephony event rather than the
   tone encoded as voice.  FID semantics MUST NOT be used in this
   context to group both media streams since such a system is not using

いくつかのシステムがRFC2833で定義されたRTPペイロードを実装しますが、トーンをDTMFに送るとき、それらは音声チャンネルに音を消しません。 したがって、事実上、彼らはコピー2部の同じDTMFトーンを送ります: 声としてコード化されて、電話イベントとしてコード化されます。 受信機が両方のコピーを手に入れるとき、それは声としてコード化されたトーンよりむしろ電話イベントを通常使用します。 システムが使用していないそのようなもの以来両方のメディアストリームを分類するのにこのような関係においてはFID意味論を使用してはいけません。

Camarillo et. al.           Standards Track                    [Page 11]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[11ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

   alternative codecs but rather different parallel encodings for the
   same information.

同じ情報のための代替のコーデックにもかかわらず、かなり異なった平行なencodings。

7.5.2 Layered Encoding

7.5.2 層にされたコード化

   Layered encoding schemes encode media in different layers.  Quality
   at the receiver varies depending on the number of layers received.
   SDP provides a means to group together contiguous multicast addresses
   that transport different layers.  The "c" line below:

層にされたコード化は異なった層でエンコードメディアを計画します。 受け取られた層の数によって、受信機の品質は異なります。 SDPは異なった層を輸送する隣接のマルチキャストアドレスを一緒に分類する手段を提供します。 以下の「c」系列:

       c=IN IP4 224.2.1.1/127/3

cがIN IP4 224.2.1.1/と等しい、127/3

   is equivalent to the following three "c" lines:

以下の3と同等物が「c」であるという台詞:

       c=IN IP4 224.2.1.1/127
       c=IN IP4 224.2.1.2/127
       c=IN IP4 224.2.1.3/127

IP4 224.2.1.1/127c=IN IP4 224.2.1.2/127c=IN IP4 224.2.1.3/のc=、127

   FID MUST NOT be used to group "m" lines that do not represent the
   same information.  Therefore, FID MUST NOT be used to group "m" lines
   that contain the different layers of layered encoding scheme.
   Besides, we do not define new group semantics to provide a more
   flexible way of grouping different layers because the already
   existing SDP mechanism covers the most useful scenarios.

FID MUST NOT、使用されて、同じ情報を表さない「m」系列を分類してください。 したがって、FID MUST NOT、使用されて、異なった層の層にされたコード化体系を含む「m」系列を分類してください。 そのうえ、私たちは、既に既存のSDPメカニズムが最も役に立つシナリオをカバーしているので異なった層を分類するよりフレキシブルな方法を提供するために新しいグループ意味論を定義しません。

7.5.3 Same IP Address and Port Number

7.5.3 同じIPアドレスとポートナンバー

   If several codecs have to be sent to the same IP address and port,
   the traditional SDP syntax of listing several codecs in the same "m"
   line MUST be used.  FID MUST NOT be used to group "m" lines with the
   same IP address/port.  Therefore, an SDP like the one below MUST NOT
   be generated.

同じIPアドレスとポートにいくつかのコーデックを送らなければならないなら、同じ「m」系列でいくつかのコーデックを記載する伝統的なSDP構文を使用しなければなりません。 FID MUST NOT、使用されて、同じIPアドレス/ポートで「m」系列を分類してください。 したがって、以下のもののようなSDPを生成してはいけません。

       v=0
       o=Laura 289083124 289083124 IN IP4 six.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       a=group:FID 1 2
       m=audio 30000 RTP/AVP 0
       a=mid:1
       m=audio 30000 RTP/AVP 8
       a=mid:2

ローラ289083124 289083124IN IP4six v=0o=.example.com tが0 0c=IN IP4と等しい、131.160、.1、.112、=グループ: FID=オーディオの30000RTP/AVP0 1 2m aは中間の=オーディオの30000RTP/AVP8: 1m aと=中間であることで等しいです:、2

Camarillo et. al.           Standards Track                    [Page 12]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[12ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

   The correct SDP for the session above would be the following one:

上のセッションのための正しいSDPは以下の1つでしょう:

       v=0
       o=Laura 289083124 289083124 IN IP4 six.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       m=audio 30000 RTP/AVP 0 8

ローラ289083124 289083124IN IP4six v=0o=.example.com tが0 0c=IN IP4と等しい、131.160、.1、.112m、オーディオの30000RTP/AVP0 8と等しいです。

   If two "m" lines are grouped using FID they MUST differ in their
   transport addresses (i.e., IP address plus port).

2「m」の線がFIDを使用することで分類されるなら、それらは輸送アドレス(すなわち、IPアドレスとポート)において異ならなければなりません。

8. Usage of the "group" Attribute in SIP

8. 一口における「グループ」属性の用法

   SDP descriptions are used by several different protocols, SIP among
   them.  We include a section about SIP because the "group" attribute
   will most likely be used mainly by SIP systems.

SDP記述はいくつかの異なったプロトコル、それらの中のSIPによって使用されます。 「グループ」属性がたぶん主にSIPシステムによって使用されるので、私たちはSIPに関するセクションを入れます。

   SIP [3] is an application layer protocol for establishing,
   terminating and modifying multimedia sessions.  SIP carries session
   descriptions in the bodies of the SIP messages but is independent
   from the protocol used for describing sessions.  SDP [2] is one of
   the protocols that can be used for this purpose.

SIP[3]は、マルチメディアセッションを確立して、終えて、変更するための応用層プロトコルです。 SIPはSIPメッセージのボディーでセッション記述を運びますが、セッションについて説明するのに使用されるプロトコルから独立しています。 SDP[2]はこのために使用できるプロトコルの1つです。

   At session establishment SIP provides a three-way handshake (INVITE-
   200 OK-ACK) between end systems. However, just two of these three
   messages carry SDP, as described in [4].

セッション設立では、SIPは3方向ハンドシェイク(INVITE200OK-ACK)をエンドシステムの間に供給します。しかしながら、ちょうどこれらの3つのメッセージのうち2はSDPを運びます、[4]で説明されるように。

8.1 Mid Value in Answers

8.1 答えにおける中間の値

   The "mid" attribute is an identifier for a particular media stream.
   Therefore, the "mid" value in the offer MUST be the same as the "mid"
   value in the answer.  Besides, subsequent offers (e.g., in a re-
   INVITE) SHOULD use the same "mid" value for the already existing
   media streams.

「中間」の属性は特定のメディアの流れのための識別子です。 したがって、申し出における「中間」の値は答えにおける「中間」の値と同じであるに違いありません。 そのうえ、その後の申し出(例えば、再INVITEの)SHOULDは既に既存のメディアの流れに同じ「中間」の値を使用します。

   RFC 3264 [4] describes the usage of SDP in relation to SIP.  The
   offerer and the answerer align their media description so that the
   nth media stream ("m=" line) in the offerer's session description
   corresponds to the nth media stream in the answerer's description.

RFC3264[4]はSIPと関連してSDPの使用法を説明します。 申出人とanswererは、申出人のセッション記述におけるn番目のメディアの流れ(「m=」線)がanswererの記述におけるn番目のメディアの流れに対応するように、彼らのメディア記述を並べます。

   The presence of the "group" attribute in an SDP session description
   does not modify this behavior.

SDPセッション記述における、「グループ」属性の存在はこの振舞いを変更しません。

   Since the "mid" attribute provides a means to label "m" lines, it
   would be possible to perform media alignment using "mid" labels
   rather than matching nth "m" lines.  However this would not bring any

「中間」の属性が「m」線をラベルする手段を提供するので、メディア整列を実行するのはむしろn番目の「m」線を合わせるより「中間」のラベルを使用することで可能でしょう。 しかしながら、これはいずれも持って来ないでしょう。

Camarillo et. al.           Standards Track                    [Page 13]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[13ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

   gain and would add complexity to implementations.  Therefore SIP
   systems MUST perform media alignment matching nth lines regardless of
   the presence of the "group" or "mid" attributes.

獲得して、実現に複雑さを加えるでしょう。 したがって、SIPシステムは「グループ」か「中間」の属性の存在にかかわらずn番目の線に合っているメディア整列を実行しなければなりません。

   If a media stream that contained a particular "mid" identifier in the
   offer contains a different identifier in the answer the application
   ignores all the "mid" and "group" lines that might appear in the
   session description.  The following example illustrates this
   scenario.

申し出における特定の「中間」の識別子を含んだメディアの流れが答えにおける異なった識別子を含んでいるなら、アプリケーションはセッション記述に現れるかもしれないすべての「中間」と「グループ」線を無視します。 以下の例はこのシナリオを例証します。

8.1.1 Example

8.1.1 例

   Two SIP entities exchange SDPs during session establishment. The
   INVITE contains the SDP below:

2つのSIP実体がセッション設立の間、SDPsを交換します。 INVITEは以下のSDPを含んでいます:

       v=0
       o=Laura 289083124 289083124 IN IP4 seven.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       a=group:FID 1 2
       m=audio 30000 RTP/AVP 0 8
       a=mid:1
       m=audio 30002 RTP/AVP 0 8
       a=mid:2

ローラ289083124 289083124IN IP4seven v=0o=.example.com tが0 0c=IN IP4と等しい、131.160、.1、.112、=グループ: FID=オーディオの30000RTP/AVP0 8 1 2m aは中間の=オーディオの30002RTP/AVP0 8: 1m aと=中間であることで等しいです:、2

   The 200 OK response contains the following SDP:

200OK応答は以下のSDPを含んでいます:

       v=0
       o=Bob 289083122 289083122 IN IP4 eigth.example.com
       t=0 0
       c=IN IP4 131.160.1.113
       a=group:FID 1 2
       m=audio 25000 RTP/AVP 0 8
       a=mid:2
       m=audio 25002 RTP/AVP 0 8
       a=mid:1

ボブ289083122 289083122IN v=0o=IP4 eigth.example.com tが0 0c=IN IP4と等しい、131.160、.1、.113、=グループ: FID=オーディオの25000RTP/AVP0 8 1 2m aは中間の=オーディオの25002RTP/AVP0 8: 2m aと=中間であることで等しいです:、1

   Since alignment of "m" lines is performed based on matching of nth
   lines, the first stream had "mid:1" in the INVITE and "mid:2" in the
   200 OK.  Therefore, the application MUST ignore every "mid" and
   "group" lines contained in the SDP.

そして、「m」線の整列がn番目の線のマッチングに基づいて実行されるので最初の流れが実行された、「中間、: INVITEの1インチ、「中間、: 200OKの2インチ、」 したがって、アプリケーションは線がSDPに含んだあらゆる「中間」と「グループ」を無視しなければなりません。

Camarillo et. al.           Standards Track                    [Page 14]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[14ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

   A well-behaved SIP user agent would have returned the SDP below in
   the 200 OK:

品行方正のSIPユーザエージェントは以下の200におけるSDPにOKを返したでしょう:

       v=0
       o=Bob 289083122 289083122 IN IP4 nine.example.com
       t=0 0
       c=IN IP4 131.160.1.113
       a=group:FID 1 2
       m=audio 25002 RTP/AVP 0 8
       a=mid:1
       m=audio 25000 RTP/AVP 0 8
       a=mid:2

ボブ289083122 289083122IN IP4nine v=0o=.example.com tが0 0c=IN IP4と等しい、131.160、.1、.113、=グループ: FID=オーディオの25002RTP/AVP0 8 1 2m aは中間の=オーディオの25000RTP/AVP0 8: 1m aと=中間であることで等しいです:、2

8.2 Group Value in Answers

8.2 答えにおける階級値

   A SIP entity that receives an offer that contains an "a=group" line
   with semantics that it does not understand MUST return an answer
   without the "group" line.  Note that, as it was described in the
   previous section, the "mid" lines MUST still be present in the
   answer.

それが理解していない意味論で「=グループ」線を含む申し出を受けるSIP実体は「グループ」線なしで返答しなければなりません。 それが前項で説明されたとき、「中間」の線が答えでまだ存在していなければならないことに注意してください。

   A SIP entity that receives an offer that contains an "a=group" line
   with semantics that are understood MUST return an answer that
   contains an "a=group" line with the same semantics.  The
   identification-tags contained in this "a=group" lines MUST be the
   same that were received in the offer or a subset of them (zero
   identification-tags is a valid subset).  When the identification-tags
   in the answer are a subset, the "group" value to be used in the
   session MUST be the one present in the answer.

理解されている意味論で「=グループ」線を含む申し出を受けるSIP実体は同じ意味論がある「=グループ」線を含む答えを返さなければなりません。 これに含まれた識別票「=グループ」線は、申し出で受け取られた同じくらいかそれらの部分集合であるに違いありません(どんな識別票も有効な部分集合ではありません)。 答えにおける識別票が部分集合であるときに、セッションのときに使用されるべき「グループ」値は答えにおける現在のものでなければなりません。

   SIP entities refuse media streams by setting the port to zero in the
   corresponding "m" line.  "a=group" lines MUST NOT contain
   identification-tags that correspond to "m" lines with port zero.

SIP実体は、対応する「m」線におけるゼロにポートを設定することによって、メディアの流れを拒否します。 「=グループ」線はポートで「m」線に対応する識別票ゼロを含んではいけません。

   Note that grouping of m lines MUST always be requested by the
   offerer, never by the answerer.  Since SIP provides a two-way SDP
   exchange, an answerer that requested grouping would not know whether
   the "group" attribute was accepted by the offerer or not.  An
   answerer that wants to group media lines SHOULD issue another offer
   after having responded to the first one (in a re-INVITE for
   instance).

申出人と、決していずれのanswererもいつも、mの組分けが立ち並んでいるというメモを要求しなければならないというわけではありません。 SIPが両用SDP交換を供給するので、組分けを要求したanswererは、「グループ」属性が申出人によって受け入れられたかどうかを知らないでしょう。 SHOULDが最初のもの(例えば、再INVITEの)に応じた後に別の申し出を発行するメディア線を分類したがっているanswerer。

8.2.1 Example

8.2.1 例

   The example below shows how the callee refuses a media stream offered
   by the caller by setting its port number to zero.  The "mid" value
   corresponding to that media stream is removed from the "group" value
   in the answer.

合わせる訪問される人がどうメディアの流れを拒否するかがポートナンバーを設定するのによる訪問者による申し出であったゼロショーの下における例。 答えにおける「グループ」値からそのメディアの流れに対応する「中間」の値を取り除きます。

Camarillo et. al.           Standards Track                    [Page 15]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[15ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

   SDP in the INVITE from caller to callee:

訪問者から訪問される人までのINVITEのSDP:

       v=0
       o=Laura 289083124 289083124 IN IP4 ten.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       a=group:FID 1 2 3
       m=audio 30000 RTP/AVP 0
       a=mid:1
       m=audio 30002 RTP/AVP 8
       a=mid:2
       m=audio 30004 RTP/AVP 3
       a=mid:3

ローラ289083124 289083124IN IP4ten v=0o=.example.com tが0 0c=IN IP4と等しい、131.160、.1、.112、=グループ: FID=オーディオの30000RTP/AVP0 1 2 3m aは中間の=オーディオの30002RTP/AVP8: 1m aと=中間であることで等しいです: 2mはオーディオの30004RTP/AVP3aと=中間であることで等しいです:、3

   SDP in the INVITE from callee to caller:

訪問される人から訪問者までのINVITEのSDP:

       v=0
       o=Bob 289083125 289083125 IN IP4 eleven.example.com
       t=0 0
       c=IN IP4 131.160.1.113
       a=group:FID 1 3
       m=audio 20000 RTP/AVP 0
       a=mid:1
       m=audio 0 RTP/AVP 8
       a=mid:2
       m=audio 20002 RTP/AVP 3
       a=mid:3

ボブ289083125 289083125IN IP4eleven v=0o=.example.com tが0 0c=IN IP4と等しい、131.160、.1、.113、=グループ: FID=オーディオの20000RTP/AVP0 1 3m aは中間の=オーディオの0RTP/AVP8: 1m aと=中間であることで等しいです: 2mはオーディオの20002RTP/AVP3aと=中間であることで等しいです:、3

8.3 Capability Negotiation

8.3 能力交渉

   A client that understands "group" and "mid" but does not want to make
   use of them in a particular session MAY want to indicate that it
   supports them.  If a client decides to do that, it SHOULD add an
   "a=group" line with no identification-tags for every semantics it
   understands.

「グループ」で「中間」を理解していますが、特定のセッションのときにそれらを利用したがっていないクライアントは、それらを支持するのを示したがっているかもしれません。 クライアントが、決めるなら、それをしてください、それ。SHOULDはそれが理解しているあらゆる意味論のために識別票なしで「=グループ」線を加えます。

   If a server receives an offer that contains empty "a=group" lines, it
   SHOULD add its capabilities also in the form of empty "a=group" lines
   to its answer.

サーバが申し出を受けるなら、それは「=グループ」人影のない線を含んでいます、それ。SHOULDは「=グループ」人影のない線の形でも能力を答えに加えます。

Camarillo et. al.           Standards Track                    [Page 16]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[16ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

8.3.1 Example

8.3.1 例

   A system that supports both LS and FID semantics but does not want to
   group any media stream for this particular session generates the
   following SDP:

LSとFID意味論の両方を支持しますが、この特定のセッションのためのどんなメディアの流れも分類したがっていないシステムは以下のSDPを発生させます:

       v=0
       o=Bob 289083125 289083125 IN IP4 twelve.example.com
       t=0 0
       c=IN IP4 131.160.1.113
       a=group:LS
       a=group:FID
       m=audio 20000 RTP/AVP 0 8

ボブ289083125 289083125IN IP4twelve v=0o=.example.com tが0 0c=IN IP4と等しい、131.160、.1、.113、=グループ: LS a=は分類します: FID mはオーディオの20000RTP/AVP0 8と等しいです。

   The server that receives that offer supports FID but not LS.  It
   responds with the SDP below:

その申し出を受けるサーバはLSではなく、FIDを支持します。 それは以下のSDPと共に応じます:

       v=0
       o=Laura 289083124 289083124 IN IP4 thirteen.example.com
       t=0 0
       c=IN IP4 131.160.1.112
       a=group:FID
       m=audio 30000 RTP/AVP 0

ローラ289083124 289083124IN IP4thirteen v=0o=.example.com tが0 0c=IN IP4と等しい、131.160、.1、.112、=グループ: FID mはオーディオの30000RTP/AVP0と等しいです。

8.4 Backward Compatibility

8.4 後方の互換性

   This document does not define any SIP "Require" header.  Therefore,
   if one of the SIP user agents does not understand the "group"
   attribute the standard SDP fall back mechanism MUST be used
   (attributes that are not understood are simply ignored).

このドキュメントはどんな「必要SIP」ヘッダーも定義しません。 したがって、SIPユーザエージェントのひとりが、「グループ」が標準のSDP秋を結果と考えるのを理解していないなら、逆メカニズムを使用しなければなりません(理解されていない属性は単に無視されます)。

8.4.1 Offerer does not Support "group"

8.4.1 申出人はどんなSupportにも「分類しません」。

   This situation does not represent a problem because grouping requests
   are always performed by offerers, not by answerers.  If the offerer
   does not support "group" this attribute will just not be used.

組分け要求がいつもanswerersではなく、申出人によって実行されるので、この状況は問題を表しません。 申出人が「グループ」を支持しないと、この属性はただ使用されないでしょう。

8.4.2 Answerer does not Support "group"

8.4.2 AnswererはどんなSupportにも「分類しません」。

   The answerer will ignore the "group" attribute, since it does not
   understand it (it will also ignore the "mid" attribute).  For LS
   semantics, the answerer might decide to perform or to not perform
   synchronization between media streams.

それを理解していないので(また、それは「中間」の属性を無視するでしょう)、answererは「グループ」属性を無視するでしょう。 LS意味論のために、answererは、働くか、またはメディアの流れの間の同期を実行しないと決めるかもしれません。

   For FID semantics, the answerer will consider that the session
   comprises several media streams.

FID意味論のために、answererは、セッションがいくつかのメディアの流れを含むと考えるでしょう。

   Different implementations would behave in different ways.

異なった実現は異なった方法で振る舞うでしょう。

Camarillo et. al.           Standards Track                    [Page 17]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[17ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

   In the case of audio and different "m" lines for different codecs an
   implementation might decide to act as a mixer with the different
   incoming RTP sessions, which is the correct behavior.

実現がミキサーとして異なった入って来るRTPセッションで機能すると決めるかもしれない異なったコーデックのためのオーディオの、そして、異なった「m」線の場合で。(それは、正しい振舞いです)。

   An implementation might also decide to refuse the request (e.g., 488
   Not acceptable here or 606 Not Acceptable) because it contains
   several "m" lines.  In this case, the server does not support the
   type of session that the caller wanted to establish.  In case the
   client is willing to establish a simpler session anyway, he SHOULD
   re-try the request without "group" attribute and only one "m" line
   per flow.

また、実現は、いくつかの「m」線を含んでいるので、要求(例えば、ここで許容できる488Notか606Not Acceptable)を拒否すると決めるかもしれません。 この場合、サーバは訪問者が確立したがっていたセッションのタイプを支持しません。 場合では、クライアントは、とにかくより簡単なセッションを確立しても構わないと思っていて、彼は「グループ」属性のない要求と1「m」だけ、が流れ単位で裏打ちするSHOULD再試行です。

9. Security Considerations

9. セキュリティ問題

   Using the "group" parameter with FID semantics, an entity that
   managed to modify the session descriptions exchanged between the
   participants to establish a multimedia session could force the
   participants to send a copy of the media to any particular
   destination.

FID意味論がある「グループ」パラメタを使用して、関係者は何とかマルチメディアセッションを証明するために関係者の間で交換されたセッション記述を変更した実体によってやむを得ずどんな特定の目的地にもメディアのコピーを送ることができました。

   Integrity mechanism provided by protocols used to exchange session
   descriptions and media encryption can be used to prevent this attack.

プロトコルによって提供された保全メカニズムは以前はよくセッション記述を交換していました、そして、この攻撃を防ぐのにメディア暗号化は使用できます。

10. IANA Considerations

10. IANA問題

   This document defines two SDP attributes: "mid" and "group".

このドキュメントは2つのSDP属性を定義します: 「中間」と「グループ。」

   The "mid" attribute is used to identify media streams within a
   session description and its format is defined in Section 3.

「中間」の属性はセッション記述の中でメディアの流れを特定するのに使用されます、そして、書式はセクション3で定義されます。

   The "group" attribute is used for grouping together different media
   streams and its format is defined in Section 4.

「グループ」属性は異なったメディアの流れを一緒に分類するのに使用されます、そして、書式はセクション4で定義されます。

   This document defines a framework to group media lines in SDP using
   different semantics. Semantics to be used with this framework are
   registered by the IANA when they are published in standards track
   RFCs.

このドキュメントは、異なった意味論を使用することでSDPのメディア線を分類するために枠組みを定義します。 それらが標準化過程RFCsで発行されるとき、この枠組みと共に使用されるべき意味論はIANAによって登録されます。

   The IANA Considerations section of the RFC MUST include the following
   information, which appears in the IANA registry along with the RFC
   number of the publication.

RFC MUSTのIANA Considerations部は以下の情報を含めます。(それは、公表のRFC番号に伴うIANA登録に現れます)。

      o  A brief description of the semantics.

o 意味論の簡単な説明。

      o  Token to be used within the group attribute. This token may be
         of any length, but SHOULD be no more than four characters long.

o グループ属性の中で使用されるべき象徴。 この象徴がどんな長さのそうですがも、SHOULDは4つのキャラクタが切望するほどそうではありません。

      o  Reference to an standards track RFC.

o 標準化過程RFCの参照。

Camarillo et. al.           Standards Track                    [Page 18]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[18ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

   The only entries in the registry for the time being are:

当分の間間の登録における唯一のエントリーは以下の通りです。

   Semantics            Token  Reference
   -------------------  -----  -----------
   Lip synchronization  LS     RFC 3388
   Flow identification  FID    RFC 3388

意味論象徴参照------------------- ----- ----------- 唇同期LS RFC3388Flow識別FID RFC3388

11. Acknowledgments

11. 承認

   The authors would like to thank Jonathan Rosenberg, Adam Roach, Orit
   Levin and Joerg Ott for their feedback on this document.

作者はこのドキュメントの彼らのフィードバックについてジョナサン・ローゼンバーグ、アダム・ローチ、Oritレヴィン、およびヨルク・オットに感謝したがっています。

12. References

12. 参照

12.1 Normative References

12.1 標準の参照

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

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

   [2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol",
       RFC 2327, April 1998.

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

   [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
       Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
       Session Initiation Protocol", RFC 3261, June 2002.

[3] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

   [4] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the
       Session Description Protocol (SDP)", RFC 3264, June 2002.

[4] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。

12.2 Informative References

12.2 有益な参照

   [5] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming
       Protocol (RTSP)", RFC 2326, April 1998.

[5]SchulzrinneとH.とラオとA.とR.Lanphier、「リアルタイムのストリーミングのプロトコル(RTSP)」、RFC2326 1998年4月。

   [6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP:
       A Transport Protocol for Real-Time Applications", RFC 1889,
       January 1996.

[6]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。

   [7] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits,
       Telephony Tones and Telephony Signals", RFC 2833, May 2000.

[7] Schulzrinne、H.、およびS.Petrack(「DTMFケタ、電話トーン、および電話信号のためのRTP有効搭載量」、RFC2833)は2000がそうするかもしれません。

Camarillo et. al.           Standards Track                    [Page 19]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[19ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

13. Authors' Addresses

13. 作者のアドレス

   Gonzalo Camarillo
   Ericsson
   Advanced Signalling Research Lab.
   FIN-02420 Jorvas
   Finland

ゴンサロキャマリロエリクソンは合図研究研究室を進めました。 フィン-02420Jorvasフィンランド

   Phone: +358 9 299 3371
   Fax: +358 9 299 3052
   EMail: Gonzalo.Camarillo@ericsson.com

以下に電話をしてください。 +358 9 299 3371Fax: +358 9 299 3052はメールされます: Gonzalo.Camarillo@ericsson.com

   Jan Holler
   Ericsson Research
   S-16480 Stockholm
   Sweden

Jan Hollerエリクソン研究S-16480ストックホルムスウェーデン

   Phone: +46 8 58532845
   Fax: +46 8 4047020
   EMail: Jan.Holler@era.ericsson.se

以下に電話をしてください。 +46 8 58532845Fax: +46 8 4047020 メール: Jan.Holler@era.ericsson.se

   Goran AP Eriksson
   Ericsson Research
   S-16480 Stockholm
   Sweden

ゴラン・APエリクソン・エリクソン研究S-16480ストックホルムスウェーデン

   Phone: +46 8 58531762
   Fax: +46 8 4047020
   EMail: Goran.AP.Eriksson@era.ericsson.se

以下に電話をしてください。 +46 8 58531762Fax: +46 8 4047020 メール: Goran.AP.Eriksson@era.ericsson.se

   Henning Schulzrinne
   Dept. of Computer Science
   Columbia University
   1214 Amsterdam Avenue
   New York, NY 10027
   USA

コンピュータサイエンスコロンビア大学1214アムステルダムAvenueニューヨーク10027ニューヨーク(米国)のヘニングSchulzrinne部

   EMail: schulzrinne@cs.columbia.edu

メール: schulzrinne@cs.columbia.edu

Camarillo et. al.           Standards Track                    [Page 20]

RFC 3388             Grouping of Media Lines in SDP        December 2002

キャマリロetアル。 メディアの標準化過程[20ページ]RFC3388組分けは2002年12月にSDPに立ち並びます。

14. Full Copyright Statement

14. 完全な著作権宣言文

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

Camarillo et. al.           Standards Track                    [Page 21]

キャマリロetアル。 標準化過程[21ページ]