[要約] RFC 3388は、SDPでメディアラインをグループ化するための仕様です。目的は、複数のメディアストリームを1つのグループとしてまとめ、セッションの管理と制御を容易にすることです。
Network Working Group G. Camarillo
Request for Comments: 3388 G. Eriksson
Category: Standards Track J. Holler
Ericsson
H. Schulzrinne
Columbia University
December 2002
Grouping of Media Lines in the Session Description Protocol (SDP)
セッション説明プロトコル（SDP）のメディアラインのグループ化
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document defines 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.
このドキュメントでは、2つのセッション説明プロトコル（SDP）属性を定義します： "Group"と "Mid"。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
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
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.
一部の環境では、この情報はバンドから実行できますが、セッションの説明内の異なるメディアストリームが互いにどのように関連するかを表現できるSDPへの拡張を持つことが望ましいでしょう。このドキュメントでは、このような拡張機能を定義しています。
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.
このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "BCP 14、RFC 2119 [1]に記載されているように解釈され、準拠の実装の要件レベルを示します。
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.
識別タグは、SDPセッションの説明内で一意でなければなりません。
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.
このドキュメントでは、2つの標準セマンティクスを定義します。LS（リップ同期）とFID（フロー識別）。さらなるセマンティクスは、標準トラックドキュメントで定義する必要があります。ただし、LSとFIDとは別に新しいセマンティクスを定義することは落胆します。代わりに、SDPNGなどの他のセッション説明メカニズムを使用することをお勧めします。
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.
「a =グループ」行は、「中間」属性によって識別されるいくつかの「m」行をグループ化するために使用されます。セッション説明内の「M」行に対応しない識別タグを含む「a =グループ」行は無視する必要があります。アプリケーションは、「a = group」行が存在しなかったかのように機能します。グループ化された「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 =グループ」行は、同じセマンティクスを使用する場合と使用できない場合があります。「MID」属性によって識別される「M」行は、「A =グループ」行が異なるセマンティクスを使用する限り、複数の「A =グループ」行に表示される場合があります。「Mid」属性によって識別された「M」行は、同じセマンティクスを使用して複数の「A =グループ」線に表示されてはなりません。
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を使用して実行されます。RTCPは、異なるストリームからタイムスタンプを壁の時計にマッピングするのに十分な情報を提供します。ただし、メディアストリームの同期の概念は、RTPを使用しないメディアストリームにも適用される場合があります。この場合、アプリケーションは、利用可能なメカニズムを使用して、ストリーム間の元のタイミング関係を回復する必要があります。
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.
次の例は、マルチキャストである会議のセッションの説明を示しています。最初のメディアストリーム（MID：1）には、英語で話すスピーカーの声が含まれています。2番目のメディアストリーム（MID：2）にはビデオコンポーネントが含まれており、3番目の（MID：3）メディアストリームには、彼が言っていることのスペイン語への翻訳があります。最初と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
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番目のメディアストリームはグループラインに存在していませんが、前述のように、MID属性（MID：3）を含む必要があることに注意してください。
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セッションを次のように定義します。「各参加者について、セッションは特定の宛先輸送アドレス（1つのネットワークアドレスと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.
以前の定義は最も一般的なケースをカバーしていますが、単一のメディアインスタンス（たとえば、オーディオストリームやビデオストリーム）が複数のRTPセッションを使用して送信される状況があります。この種の状況の2つの例（他の多くの場合）は、SIP [3]を使用したセルラーシステムと、音声とは異なるホストでDTMFトーンを受け取るシステムです。
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セッションを使用して、単一のメディアインスタンス（送信者からのエンコードされたスピーチ）を運ぶために使用される例です。
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つは音声用、もう1つはDTMFトーン用です。両方のRTPセッションは、論理的に同じメディアインスタンスの一部です。
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セッションで構成されます。
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つのコーデックのみを使用していると想定されています。このコーデックはセッション中に動的に変化する可能性がありますが、特定の瞬間には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」ラインを1つずつチェックします。特定の「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アドレス/ポート番号）に送信することになります。
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およびポート30002でAMRでGSMをサポートします。リモートパーティがGSMを送信すると、RTPパケットがポート番号30000に送信されます。パーティーは、セッションの途中で両方のコーデックを動的に切り替えることができます。ただし、この例では、一度に音声を運ぶメディアストリームは1つだけです。もう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
(The linebreak in the fmtp line accommodates RFC formatting restrictions; SDP does not have continuation lines.)
（FMTPラインのラインブレイクには、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アドレスで異なるコーデックを受信する方法を示しています。
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
(The linebreak in the fmtp line accomodates RFC formatting restrictions; SDP does not have continuation lines.)
（FMTPラインのラインブレークには、RFCのフォーマット制限に対応します。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アドレスでPCMのSDPサポートが含まれています。リモートシステムは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
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を受信するユーザーエージェントは、特定の瞬間にPCM U-Lawをポート番号30000に送信するか、PCM A-Lawをポート番号30002に送信できることを知っています。PCM U-Law（ペイロード0）。
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
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).
特定の時点で、メディアエージェントがPCM U-Law（ペイロード0）を送信している場合、ポート30000の131.160.1.112にRTPパケットを送信し、ポート20000（1番目と3番目の「M」ライン）で131.160.1.111に送信します。。PCM A-Law（ペイロード8）を送信している場合、ポート30002でRTPパケットを131.160.1.112に送信し、ポート20000（2番目と3番目の「M」ライン）で131.160.1.111に送信します。
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を生成したシステムは、ポート30000のPCM U-Lawとポート30002のPCM A-Lawをサポートします。さらに、会話を記録する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セッションでメディアを同時に送信する必要があることを忘れないでください。
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セッションの説明の例を示します。
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
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.
リモートパーティは、PCMエンコード音声（ペイロード0）を131.160.1.112に送信し、テレフォニーイベントとして131.160.1.111にエンコードされたDTMFトーンを送信します。音声またはDTMFのみが特定の時点で送信されることに注意してください。DTMFトーンが送信されると、最初のメディアストリームにはデータが含まれておらず、音声が送信されると、2番目のメディアストリームにデータがありません。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）を使用して「グループ」属性が適用できるように見えるかもしれませんが、そうではないシナリオに言及することは価値があります。
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セマンティクスは、アプリケーションが一度に1つのコーデックのみを使用する場合に役立ちます。異なるコーデックを同時に使用して同じメディアをエンコードするアプリケーションは、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セマンティクスを使用してはなりません。
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 = 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
C = IN IP4 224.2.1.1/127 C = IN IP4 224.2.1.2/127 C = IN IP4 224.2.1.3/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を使用して、同じ情報を表していない「M」行をグループ化してはなりません。したがって、FIDを使用して、層状エンコードスキームの異なる層を含む「M」線をグループ化してはなりません。また、既存のSDPメカニズムが最も有用なシナリオをカバーするため、さまざまなレイヤーをグループ化するより柔軟な方法を提供するために、新しいグループセマンティクスを定義するものではありません。
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のような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
The correct SDP for the session above would be the following one:
上記のセッションの正しいSDPは次のものです。
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
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 8
If two "m" lines are grouped using FID they MUST differ in their transport addresses (i.e., IP address plus port).
FIDを使用して2つの「M」ラインがグループ化されている場合、トランスポートアドレス（つまり、IPアドレスプラスポート）が異なる必要があります。
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方向の握手（Invite-200 ok-ack）を提供します。ただし、[4]で説明されているように、これら3つのメッセージのうち2つだけがSDPを搭載しています。
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.
「Mid」属性は、特定のメディアストリームの識別子です。したがって、オファーの「中間」の値は、答えの「中間」値と同じでなければなりません。その上、後続のオファー（例えば、re invite）は、既存のメディアストリームに同じ「中間」値を使用する必要があります。
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の使用について説明しています。OffererとAnswererは、メディアの説明を調整して、Offererのセッションの説明のnth Mediaストリーム（ "m =" line）が、回答者の説明の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 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.
「Mid」属性は「M」ラインにラベルを付ける手段を提供するため、nth "m"行を一致させるのではなく、「Mid」ラベルを使用してメディアアラインメントを実行することが可能です。ただし、これは利益をもたらさず、実装に複雑さを加えます。したがって、SIPシステムは、「グループ」または「Mid」属性の存在に関係なく、NTH行を一致させるメディアアライメントを実行する必要があります。
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.
オファーに特定の「MID」識別子を含むメディアストリームに、回答に異なる識別子が含まれている場合、アプリケーションは、セッションの説明に表示される可能性のあるすべての「ミッド」ラインと「グループ」行を無視します。次の例は、このシナリオを示しています。
Two SIP entities exchange SDPs during session establishment. The INVITE contains the SDP below:
2つのSIPエンティティは、セッションの確立中にSDPを交換します。招待状には以下の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
The 200 OK response contains the following SDP:
200 OK応答には、次の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
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.
nthラインの一致に基づいて「m」行のアラインメントが実行されるため、最初のストリームには招待状に「mid：1」、200 okに「mid：2」がありました。したがって、アプリケーションは、SDPに含まれるすべての「中間」および「グループ」行を無視する必要があります。
A well-behaved SIP user agent would have returned the SDP below in the 200 OK:
行儀の良いSIPユーザーエージェントは、200 OKで以下のSDPを返していたでしょう。
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
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 = group」行を含むオファーを受け取る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交換を提供するため、グループ化を要求した回答者は、「グループ」属性が提供者によって受け入れられたかどうかがわかりません。メディアラインをグループ化したい回答者は、最初のラインに応答した後に別のオファーを発行する必要があります（たとえば、再入手）。
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.
以下の例は、ポート番号をゼロに設定することにより、Calleeが発信者が提供するメディアストリームを拒否する方法を示しています。そのメディアストリームに対応する「ミッド」値は、回答の「グループ」値から削除されます。
SDP in the INVITE from caller to callee:
発信者からCalleeへの招待の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
SDP in the INVITE from callee to caller:
CalleeからCallerへの招待の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
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 =グループ」行を含むオファーを受け取った場合、その機能を空の「a =グループ」行の形でその回答に追加する必要があります。
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
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
V = 0 O = Laura 289083124 289083124 In IP4 Thirteen.example.com T = 0 C = IN IP4 131.160.1.112 A =グループ：FID M = Audio 30000 RTP/AVP 0
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ユーザーエージェントの1つが「グループ」属性を理解していない場合、標準のSDPフォールバックメカニズムを使用する必要があります（理解されていない属性は単に無視されます）。
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.
この状況は、グループ化のリクエストが常に応答者ではなく提供者によって実行されるため、問題を表していません。オファーが「グループ」をサポートしていない場合、この属性は使用されません。
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.
FIDセマンティクスの場合、回答者はセッションがいくつかのメディアストリームで構成されていることを考慮します。
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.
オーディオおよび異なるコーデックの異なる「M」行の場合、実装は、正しい動作であるさまざまな着信RTPセッションを持つミキサーとして機能することを決定する場合があります。
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」行が含まれているため、リクエストを拒否することも決定する場合があります（ここでは、ここでは受け入れられない、または606は受け入れられない606）。この場合、サーバーは発信者が確立したいセッションの種類をサポートしていません。クライアントがとにかくよりシンプルなセッションを確立する意思がある場合、彼はフローごとに「グループ」属性と1つの「m」行のみをせずにリクエストを再試行する必要があります。
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.
セッションの説明とメディア暗号化の交換に使用されるプロトコルによって提供される整合性メカニズムを使用して、この攻撃を防ぐことができます。
This document defines two SDP attributes: "mid" and "group".
このドキュメントでは、2つのSDP属性を定義します：「MID」と「グループ」。
The "mid" attribute is used to identify media streams within a session description and its format is defined in Section 3.
「Mid」属性は、セッションの説明内でメディアストリームを識別するために使用され、その形式はセクション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でメディアラインをグループ化するフレームワークを定義します。このフレームワークで使用されるセマンティクスは、IANAが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に関する考慮事項セクションには、IANAレジストリに表示されるRFC番号に掲載されている次の情報を含める必要があります。
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 グループ属性内で使用されるトークン。このトークンは任意の長さである可能性がありますが、長さ4文字以下でなければなりません。
o Reference to an standards track RFC.
o 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
The authors would like to thank Jonathan Rosenberg, Adam Roach, Orit Levin and Joerg Ott for their feedback on this document.
著者は、この文書に関するフィードバックについて、ジョナサン・ローゼンバーグ、アダム・ローチ、オリット・レビン、ジョーグ・オットに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley、M。and 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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、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] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）のオファー/回答モデル」、RFC 3264、2002年6月。
[5] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[5] Schulzrinne、H.、Rao、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.、Frederick、R。and 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. Petrack、「DTMFディジット、テレフォニートーン、テレフォニーシグナルのRTPペイロード」、RFC 2833、2000年5月。
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Gonzalo Camarillo Ericsson Advanced Signaling Research Lab。Fin-02420 Jorvas Finland
Phone: +358 9 299 3371
Fax: +358 9 299 3052
EMail: Gonzalo.Camarillo@ericsson.com
Jan Holler Ericsson Research S-16480 Stockholm Sweden
Jan Holler Ericsson Research S-16480 Stockholm Sweden
Phone: +46 8 58532845
Fax: +46 8 4047020
EMail: Jan.Holler@era.ericsson.se
Goran AP Eriksson Ericsson Research S-16480 Stockholm Sweden
Goran Ap Eriksson Ericsson Research S-16480 Stockholm Sweden
Phone: +46 8 58531762
Fax: +46 8 4047020
EMail: Goran.AP.Eriksson@era.ericsson.se
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
コンピューターサイエンスコロンビア大学のヘニングシュルツリン部1214アムステルダムアベニューニューヨーク、ニューヨーク10027 USA
EMail: schulzrinne@cs.columbia.edu
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。