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

Grouping of Media Lines in the Session Description Protocol (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.




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.


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
          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
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」ラインとして知られています。セッション記述は、複数の「M」の行が含まれている場合、SDPは、それらの2つ以上の間の特定の関係を表現する任意の手段を提供しません。アプリケーションが複数の「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.


2. Terminology

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"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" BCP 14、RFC 2119に記載されているように、[1]に解釈されるべきであり、対応する実装の要求レベルを示します。

3. Media Stream Identification Attribute

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

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


4. Group Attribute

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"

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.


5. Use of "group" and "mid"

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.


"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.

「A =グループ」線が一緒にグループにそれらの「中間」属性によって識別される複数の「M」の行に使用されます。セッション記述内の任意の「M」の行に対応していない識別タグを含む「A =基」行は無視されなければなりません。 「A =グループ」行が存在しなかったかのようにアプリケーションが動作します。グループ化された「M」の行とSDPを受信するアプリケーションの動作は、「A =基」行のセマンティクスフィールドによって定義されます。

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.

セッション記述のいくつかの「A =グループ」行があるかもしれません。セッション記述のすべての「A =グループ」の行は、同じセマンティクスを使用しない場合があります。その「半ば」属性によって識別される「M」の行は、限り、「A =グループ」行は異なる意味を使用して、複数の「A =グループ」行に表示されることがあります。その「半ば」属性によって識別される「M」の行は、同じセマンティクスを使用して複数の「A =グループ」の行に現れてはいけません。

6. Lip Synchronization (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.


6.1 Example of 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.


       o=Laura 289083124 289083124 IN IP4
       t=0 0
       c=IN IP4
       a=group:LS 1 2
       m=audio 30000 RTP/AVP 0
       m=video 30002 RTP/AVP 31
       m=audio 30004 RTP/AVP 0
       i=This media stream contains the Spanish translation

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.


7. Flow Identification (FID)

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とRTCPパケットから成りRTPセッション内のソース」で作成されました。

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のポートペア)によって定義されます」。

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.


7.1 SIP and Cellular Access
7.1 SIPおよびセルラーアクセス

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).


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トーンを集めるネットワーク内のアプリケーションサーバを持つことが一般的です。 DTMFトーンのための音声用とその他:この状況では、2つのRTPセッションを確立する必要があります。どちらのRTPセッションは、論理的に同じメディアインスタンスの一部です。

7.3 Media Flow Definition

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:


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を使用する場合は、メディアフローは、一回の以上のRTPセッションを備えます。

7.4 FID Semantics
7.4 FIDセマンティクス

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.


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.


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.

アプリケーションは、現在のコーデックとチェックフローの一部である1つすべての「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.


7.4.1 Examples of FID

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.


         o=Laura 289083124 289083124 IN IP4
         t=0 0
         c=IN IP4
         a=group:FID 1 2
         m=audio 30000 RTP/AVP 3
         a=rtpmap:3 GSM/8000
         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

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


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.


v=0 o=Laura 289083124 289083124 IN IP4 t=0 0 c=IN IP4 a=group:FID 1 2 m=audio 20000 RTP/AVP 0 c=IN IP4 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

V = 0 0 = Lauraの289083124 289083124 IN IP4 T = 0、C = IN IP4 A =基:FID 1 2 M =オーディオ20000 RTP / AVP 0 C = IN IP4 A = rtpmap:0 PCMU / 8000 =ミッド:1 M =オーディオ30002 RTP / AVP 97 = rtpmap:97 AMR / 8000 =の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.)


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


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.


       o=Laura 289083124 289083124 IN IP4
       t=0 0
       c=IN IP4
       a=group:FID 1 2
       m=audio 30000 RTP/AVP 0
       m=audio 30002 RTP/AVP 8

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を受信するユーザエージェントは、ある瞬間に、それは、ポート番号30002にポート番号30000またはPCM A-法のいずれかのPCM U-法則を送ることができますが、メディアエージェントはまた、もう一方の端にのみ送信されますことを知っていることを知っていますPCM U-法則(ペイロード0)。

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


       o=Laura 289083124 289083124 IN IP4
       t=0 0
       c=IN IP4
       a=group:FID 1 2 3
       m=audio 30000 RTP/AVP 0
       m=audio 30002 RTP/AVP 8
       m=audio 20000 RTP/AVP 0 8
       c=IN IP4

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

特定の時点で、PCMのU則(ペイロード0)を送信するメディア・エージェントである場合、それはポート20000のポート30000上及び131.160.1.111に131.160.1.112にRTPパケットを送信する(第一及び第三の「M」の行) 。それはPCMのA則(ペイロード8)を送信している場合は、ポート20000(第二及び第三の「M」の行)上のポート30002上及び131.160.1.111に131.160.1.112にRTPパケットを送信します。

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 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を生成したシステムは、それは、そのIPアドレスの会話を記録している131.160.1.111であるアプリケーション・サーバを使用して、ほかにポート30002上のポート30000およびPCM A-法にPCMのU-法則をサポートしています。アプリケーションサーバは常に(それが効果的に任意のコーデックを受け取ることができますので、それは実際には、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.


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ペイロードは、RFC 2833に記載されている[7]。以下、FIDセマンティクスを使用してSDPセッション記述と、このペイロードタイプの例があります。

       o=Laura 289083124 289083124 IN IP4
       t=0 0
       c=IN IP4
       a=group:FID 1 2
       m=audio 30000 RTP/AVP 0
       m=audio 20000 RTP/AVP 97
       c=IN IP4
       a=rtpmap:97 telephone-events

The remote party would send PCM encoded voice (payload 0) to and DTMF tones encoded as telephony events to 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.

相手は131.160.1.111にテレフォニーイベントとしてエンコード131.160.1.112とDTMFトーンにPCM符号化された音声(ペイロード0)を送信します。音声のみまたはDTMFは、時間の特定の時点で送信されることに注意してください。 DTMFトーンが送信されると、第一のメディアストリームは、音声が送信されたとき、第2のメディアストリーム内のデータが存在しない、任意のデータを搬送せず。 FID意味論は、代替コーデックの異なる宛先を提供しています。

7.5 Scenarios that FID does not Cover

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


7.5.1 Parallel Encoding Using Different Codecs

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.

アプリケーションは一度に一つのコーデックを使用する場合、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 alternative codecs but rather different parallel encodings for the same information.

一部のシステムでは、RFC 2833で定義されたRTPペイロードを実装するが、彼らはDTMFトーンを送信するときには、音声チャネルをミュートしないでください。そのため、実際にはそれらは同じDTMFトーンの2つのコピーを送信している:声としてエンコードおよびテレフォニーイベントとしてエンコードされました。受信機は両方のコピーを取得すると、それは一般的に音声としてエンコードされた音ではなく、テレフォニーイベントを使用しています。このようなシステムは、同じ情報のための代替コーデックではなく、異なる並列エンコーディングを使用していないので、FIDのセマンティクスは、両方のメディアストリームグループにこの文脈で使用してはいけません。

7.5.2 Layered Encoding

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

IP4のC =

is equivalent to the following three "c" lines:


       c=IN IP4
       c=IN IP4
       c=IN IP4

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.


7.5.3 Same IP Address and Port Number

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は、同一のIPアドレス/ポートでグループ「M」の行に使用してはいけません。したがって、以下のようなSDPを生成してはいけません。

       o=Laura 289083124 289083124 IN IP4
       t=0 0
       c=IN IP4
       a=group:FID 1 2
       m=audio 30000 RTP/AVP 0
       m=audio 30000 RTP/AVP 8

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


       o=Laura 289083124 289083124 IN IP4
       t=0 0
       c=IN IP4
       m=audio 30000 RTP/AVP 0 8

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


8. Usage of the "group" Attribute in SIP

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]は、この目的のために使用することができるプロトコルの一つです。

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ウェイハンドシェイク(INVITE-200 OK-ACK)を提供します。 [4]で説明されるようしかし、ちょうど2つのこれらの3つのメッセージのは、SDPを運びます。

8.1 Mid Value in Answers

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.


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.

RFC 3264 [4]はSIPに関連してSDPの使用を記載しています。オファーのセッション記述におけるn番目のメディアストリーム(「M =」行)は回答の説明におけるn番目のメディア・ストリームに対応するようにオファーとアンサーは、そのメディア記述を整列させます。

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


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


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

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

2つのSIPエンティティは、セッション確立中のSDPを交換します。 INVITE以下SDPが含まれています。

       o=Laura 289083124 289083124 IN IP4
       t=0 0
       c=IN IP4
       a=group:FID 1 2
       m=audio 30000 RTP/AVP 0 8
       m=audio 30002 RTP/AVP 0 8

The 200 OK response contains the following SDP:

200 OK応答は、以下SDPが含まれています。

       o=Bob 289083122 289083122 IN IP4
       t=0 0
       c=IN IP4
       a=group:FID 1 2
       m=audio 25000 RTP/AVP 0 8
       m=audio 25002 RTP/AVP 0 8

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.

200 OKで:INVITE「2中間」の「M」の行のアラインメントがn番目のラインのマッチングに基づいて行われるので、第一の流れは、「1中間」を有していました。したがって、アプリケーションは、SDPに含まれるすべての「中」と「グループ」の行を無視しなければなりません。

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

行儀のSIPユーザエージェントは、200 OKで、以下のSDPを返したでしょう:

       o=Bob 289083122 289083122 IN IP4
       t=0 0
       c=IN IP4
       a=group:FID 1 2
       m=audio 25002 RTP/AVP 0 8
       m=audio 25000 RTP/AVP 0 8
8.2 Group Value in Answers

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.

それは、「グループ」行せずに答えを返さなければなら理解していないセマンティクスを持つ「A =グループ」の行が含まれているの申し出を受けた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.

理解される意味論を持つ「A =グループ」行を含むオファーを受信するSIPエンティティは、同じ意味を持つ「A =グループ」線を含む応答を返さなければなりません。この「A =基」行に含まれる識別タグを提供またはそれらのサブセットにおいて(ゼロ識別タグの有効なサブセットである)を受信したのと同じでなければなりません。答えで識別タグがサブセットである場合、セッションで使用される「グループ」値は、回答の一方に存在していなければなりません。

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」の行にはゼロにポートを設定することによって、メディアストリームを拒否します。 「A =グループ」線がポートゼロと「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).

m行のグループ化は常に決して回答によって、オファー側から要求されなければならないことに注意してください。 SIPは、双方向のSDP交換を提供するので、グループ化要求された回答は、「グループ」属性は、オファーかによって受け入れられたかどうかを知ることはできません。最初の1に応答した後に別のオファーを発行する必要があり、グループのメディアラインに望んでいる回答(中再INVITE例えば)。

8.2.1 Example

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.


SDP in the INVITE from caller to callee:


       o=Laura 289083124 289083124 IN IP4
       t=0 0
       c=IN IP4
       a=group:FID 1 2 3
       m=audio 30000 RTP/AVP 0
       m=audio 30002 RTP/AVP 8
       m=audio 30004 RTP/AVP 3

SDP in the INVITE from callee to caller:


       o=Bob 289083125 289083125 IN IP4
       t=0 0
       c=IN IP4
       a=group:FID 1 3
       m=audio 20000 RTP/AVP 0
       m=audio 0 RTP/AVP 8
       m=audio 20002 RTP/AVP 3
8.3 Capability Negotiation

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.

「グループ」と「中期」を理解しますが、特定のセッションでそれらを使用することを望んでいないクライアントは、それが彼らをサポートすることを示すために必要がある場合があります。クライアントはそれを行うことを決定した場合、それは理解し、すべてのセマンティクスのためノー識別タグで「A =グループ」の行を追加する必要があります。

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.

サーバは空の「A =グループ」の行が含まれているの申し出を受けた場合、それはその答えに空「=グループは」ラインの形でも、その機能を追加する必要があります。

8.3.1 Example

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:


       o=Bob 289083125 289083125 IN IP4
       t=0 0
       c=IN IP4
       m=audio 20000 RTP/AVP 0 8

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


       o=Laura 289083124 289083124 IN IP4
       t=0 0
       c=IN IP4
       m=audio 30000 RTP/AVP 0
8.4 Backward Compatibility

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).


8.4.1 Offerer does not Support "group"

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.


8.4.2 Answerer does not Support "group"

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.

それはそれを理解していないので、回答は(それはまた、「半ば」属性を無視します)、「グループ」属性を無視します。 LSセマンティクスについては、回答は実行したり、メディアストリーム間の同期を実行しないことを決めるかもしれません。

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


Different implementations would behave in different ways.


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.


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.


9. Security Considerations

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.


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".


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


The "group" attribute is used for grouping together different media streams and its format is defined in Section 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.


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のIANA Considerations部は、出版のRFC番号とともにIANAレジストリに表示される次の情報を含まなければなりません。

o A brief description of the semantics.


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 Reference to an standards track RFC.


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


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

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


12. References
12.1 Normative References

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

[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

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

[2]ハンドレー、M.およびV. Jacobsonの "SDP:セッション記述プロトコル"、RFC 2327、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.学生、 "SIP:セッション開始プロトコル"、 RFC 3261、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と、RFC 3264、2002年6月 "セッション記述プロトコル(SDP)とのオファー/アンサーモデル"。

12.2 Informative References

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

[5] SchulzrinneとH.とラオとA.とR. Lanphier、 "リアルタイムストリーミングプロトコル(RTSP)"、RFC 2326、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. Jacobson氏、 "RTP:リアルタイムアプリケーションのためのトランスポートプロトコル"、RFC 1889、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. 2000 Petrackとを、 "DTMFケタ、電話トーン、および電話信号のためのRTPペイロード"、RFC 2833、2000年5月。

13. Authors' Addresses

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

ゴンサロ・カマリロエリクソン高度なシグナリング研究所。 FIN-02420 Jorvasフィンランド

Phone: +358 9 299 3371 Fax: +358 9 299 3052 EMail:

電話:+358 9 299 3371ファックス:+358 9 299 3052 Eメール

Jan Holler Ericsson Research S-16480 Stockholm Sweden


Phone: +46 8 58532845 Fax: +46 8 4047020 EMail:

電話:+46 8 58532845ファックス:+46 8 4047020 Eメール

Goran AP Eriksson Ericsson Research S-16480 Stockholm Sweden


Phone: +46 8 58531762 Fax: +46 8 4047020 EMail:

電話:+46 8 58531762ファックス:+46 8 4047020 Eメール

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

コンピュータサイエンスコロンビア大学1214アムステルダムAvenueニューヨークのヘニングSchulzrinneと部長、NY 10027 USA



14. Full Copyright Statement

Copyright (C) The Internet Society (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.


The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.






Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。