[要約] RFC 3264は、SDP（Session Description Protocol）を用いて、二者間でメディア通信のパラメータを合意するための「オファー/アンサー (Offer/Answer) モデル」を定義しています。一方が通信の希望条件（オファー）を提示し、もう一方がそれを承諾または修正（アンサー）する際の一貫したメッセージ交換のルールを規定しています。SIPなどのシグナリングプロトコルを介して、音声、ビデオ、およびデータストリームの種類や符号化方式を確実に調整するための論理的な枠組みを提供することを目的としています。
Network Working Group J. Rosenberg
Request for Comments: 3264 dynamicsoft
Obsoletes: 2543 H. Schulzrinne
Category: Standards Track Columbia U.
June 2002
An Offer/Answer Model with 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.
本書は、インターネットコミュニティ向けのインターネット標準化過程のプロトコルを規定し、改善に向けた議論や提案を求めます。このプロトコルの標準化状況については、「Internet Official Protocol Standards」（STD 1）の最新版を参照してください。本書は無制限に配布できます。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
概要
This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP).
本書は、2つのエンティティがセッション記述プロトコル（SDP）を利用し、両者間のマルチメディアセッションについて共通の認識を形成する仕組みを定義します。一方の参加者が自身の視点から希望するセッションを記述して相手に提示し、相手は自身の視点から希望するセッションを回答します。このオファー/アンサーモデルは、セッション全体を把握するために双方の情報が必要となるユニキャストセッションで特に有用です。このモデルは、セッション開始プロトコル（SIP）などで使用されます。
Table of Contents
目次
1 Introduction ........................................ 2
2 Terminology ......................................... 3
3 Definitions ......................................... 3
4 Protocol Operation .................................. 4
5 Generating the Initial Offer ........................ 5
5.1 Unicast Streams ..................................... 5
5.2 Multicast Streams ................................... 8
6 Generating the Answer ............................... 9
6.1 Unicast Streams ..................................... 9
6.2 Multicast Streams ................................... 12
7 Offerer Processing of the Answer .................... 12
8 Modifying the Session ............................... 13
8.1 Adding a Media Stream ............................... 13
8.2 Removing a Media Stream ............................. 14
8.3 Modifying a Media Stream ............................ 14
8.3.1 Modifying Address, Port or Transport ................ 14
8.3.2 Changing the Set of Media Formats ................... 15
8.3.3 Changing Media Types ................................ 17
8.3.4 Changing Attributes ................................. 17
8.4 Putting a Unicast Media Stream on Hold .............. 17
9 Indicating Capabilities ............................. 18
10 Example Offer/Answer Exchanges ...................... 19
10.1 Basic Exchange ...................................... 19
10.2 One of N Codec Selection ............................ 21
11 Security Considerations ............................. 23
12 IANA Considerations ................................. 23
13 Acknowledgements .................................... 23
14 Normative References ................................ 23
15 Informative References .............................. 24
16 Authors' Addresses .................................. 24
17 Full Copyright Statement............................. 25
The Session Description Protocol (SDP) [1] was originally conceived as a way to describe multicast sessions carried on the Mbone. The Session Announcement Protocol (SAP) [6] was devised as a multicast mechanism to carry SDP messages. Although the SDP specification allows for unicast operation, it is not complete. Unlike multicast, where there is a global view of the session that is used by all participants, unicast sessions involve two participants, and a complete view of the session requires information from both participants, and agreement on parameters between them.
セッション記述プロトコル（SDP）[1]は、もともとMbone上で伝送するマルチキャストセッションを記述する方法として考案されました。セッション告知プロトコル（SAP）[6]は、SDPメッセージを伝送するマルチキャストの仕組みとして考案されました。SDPの仕様はユニキャスト動作も認めていますが、そのための定義は不完全です。すべての参加者が共通のセッション像を利用するマルチキャストとは異なり、ユニキャストセッションには2者が関与します。そのため、セッション全体を把握するには両者の情報とパラメーターの合意が必要です。
As an example, a multicast session requires conveying a single multicast address for a particular media stream. However, for a unicast session, two addresses are needed - one for each participant. As another example, a multicast session requires an indication of which codecs will be used in the session. However, for unicast, the set of codecs needs to be determined by finding an overlap in the set supported by each participant.
たとえば、マルチキャストセッションでは、特定のメディアストリームに対して1つのマルチキャストアドレスを伝えれば十分です。一方、ユニキャストセッションでは、各参加者用に2つのアドレスが必要です。また、マルチキャストセッションでは使用するコーデックを示せばよいのに対し、ユニキャストでは、各参加者がサポートするコーデック集合の共通部分を求めて使用するコーデックを決める必要があります。
As a result, even though SDP has the expressiveness to describe unicast sessions, it is missing the semantics and operational details of how it is actually done. In this document, we remedy that by defining a simple offer/answer model based on SDP. In this model, one participant in the session generates an SDP message that constitutes the offer - the set of media streams and codecs the offerer wishes to use, along with the IP addresses and ports the offerer would like to use to receive the media. The offer is conveyed to the other participant, called the answerer. The answerer generates an answer, which is an SDP message that responds to the offer provided by the offerer. The answer has a matching media stream for each stream in the offer, indicating whether the stream is accepted or not, along with the codecs that will be used and the IP addresses and ports that the answerer wants to use to receive media.
このように、SDPにはユニキャストセッションを記述する表現力はありますが、実際の手順を定める意味論と運用上の詳細が不足しています。本書では、SDPに基づく単純なオファー/アンサーモデルを定義して、この不足を補います。一方の参加者（オファー側）は、使用を希望するメディアストリームとコーデック、およびメディア受信用のIPアドレスとポートを含むSDPメッセージを生成し、これをオファーとして相手（アンサー側）に伝えます。アンサー側はオファーに応答するSDPメッセージを生成します。アンサーにはオファー内の各ストリームに対応するメディアストリームが含まれ、各ストリームを受け入れるかどうか、使用するコーデック、アンサー側がメディア受信用に使用するIPアドレスとポートが示されます。
It is also possible for a multicast session to work similar to a unicast one; its parameters are negotiated between a pair of users as in the unicast case, but both sides send packets to the same multicast address, rather than unicast ones. This document also discusses the application of the offer/answer model to multicast streams.
マルチキャストセッションもユニキャストと同様に動作させられます。この場合、パラメーターはユニキャストと同じように2者間で交渉しますが、両者はユニキャストアドレスではなく同じマルチキャストアドレスにパケットを送信します。本書では、オファー/アンサーモデルをマルチキャストストリームに適用する方法も説明します。
We also define guidelines for how the offer/answer model is used to update a session after an initial offer/answer exchange.
初回のオファー/アンサー交換後にセッションを更新する際の、オファー/アンサーモデルの使用指針も定義します。
The means by which the offers and answers are conveyed are outside the scope of this document. The offer/answer model defined here is the mandatory baseline mechanism used by the Session Initiation Protocol (SIP) [7].
オファーとアンサーを伝送する手段は本書の範囲外です。ここで定義するオファー/アンサーモデルは、セッション開始プロトコル（SIP）[7]が使用する必須の基本メカニズムです。
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 RFC 2119 [2] and indicate requirement levels for compliant implementations.
本書では、「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」というキーワードをRFC 2119 [2]の定義に従って解釈します。これらのキーワードは、準拠する実装に求める要件の強さを示します。
The following terms are used throughout this document:
次の用語は、このドキュメント全体で使用されます。
Agent: An agent is the protocol implementation involved in the offer/answer exchange. There are two agents involved in an offer/answer exchange.
エージェント（Agent）: オファー/アンサー交換に関与するプロトコルの実装です。交換には2つのエージェントが関与します。
Answer: An SDP message sent by an answerer in response to an offer received from an offerer.
アンサー（Answer）: オファー側から受信したオファーに応答して、アンサー側が送信するSDPメッセージです。
Answerer: An agent which receives a session description from another agent describing aspects of desired media communication, and then responds to that with its own session description.
アンサー側（Answerer）: 希望するメディア通信の内容を記述したセッション記述を別のエージェントから受信し、自身のセッション記述で応答するエージェントです。
Media Stream: From RTSP [8], a media stream is a single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. In SDP, a media stream is described by an "m=" line and its associated attributes.
メディアストリーム（Media Stream）: RTSP [8]で用いられる用語で、音声や映像のストリーム、単一のホワイトボード、または共有アプリケーションのグループなど、1つのメディアインスタンスを指します。SDPでは、メディアストリームを「m=」行と関連属性で記述します。
Offer: An SDP message sent by an offerer.
オファー：提供者から送信されたSDPメッセージ。
Offerer: An agent which generates a session description in order to create or modify a session.
オファー側（Offerer）: セッションを作成または変更するためにセッション記述を生成するエージェントです。
The offer/answer exchange assumes the existence of a higher layer protocol (such as SIP) which is capable of exchanging SDP for the purposes of session establishment between agents.
オファー/アンサー交換では、エージェント間でセッションを確立するためにSDPを交換できる上位層プロトコル（SIPなど）が存在することを前提とします。
Protocol operation begins when one agent sends an initial offer to another agent. An offer is initial if it is outside of any context that may have already been established through the higher layer protocol. It is assumed that the higher layer protocol provides maintenance of some kind of context which allows the various SDP exchanges to be associated together.
プロトコルの動作は、一方のエージェントが初期オファーを他方に送信した時点で始まります。上位層プロトコルを通じてすでに確立されている可能性のあるコンテキストの外で行われるオファーを、初期オファーとします。上位層プロトコルは、複数のSDP交換を相互に関連付けられるよう、何らかのコンテキストを維持すると想定します。
The agent receiving the offer MAY generate an answer, or it MAY reject the offer. The means for rejecting an offer are dependent on the higher layer protocol. The offer/answer exchange is atomic; if the answer is rejected, the session reverts to the state prior to the offer (which may be absence of a session).
オファーを受信したエージェントは、アンサーを生成してもよく (MAY)、オファーを拒否してもよい (MAY) です。拒否の方法は上位層プロトコルによって異なります。オファー/アンサー交換は不可分です。アンサーが拒否された場合、セッションはオファー前の状態（セッションが存在しない状態の場合もあります）に戻ります。
At any time, either agent MAY generate a new offer that updates the session. However, it MUST NOT generate a new offer if it has received an offer which it has not yet answered or rejected. Furthermore, it MUST NOT generate a new offer if it has generated a prior offer for which it has not yet received an answer or a rejection. If an agent receives an offer after having sent one, but before receiving an answer to it, this is considered a "glare" condition.
どちらのエージェントも、いつでもセッションを更新する新しいオファーを生成してもよいです (MAY)。ただし、受信したオファーにまだ回答も拒否もしていない場合、新しいオファーを生成してはなりません (MUST NOT)。また、以前に送信したオファーへの回答または拒否をまだ受け取っていない場合も、新しいオファーを生成してはなりません (MUST NOT)。エージェントがオファーを送信した後、その回答を受け取る前に相手からオファーを受信した状態を「glare」と呼びます。
The term glare was originally used in circuit switched telecommunications networks to describe the condition where two switches both attempt to seize the same available circuit on the same trunk at the same time. Here, it means both agents have attempted to send an updated offer at the same time.
glareという用語は、もともと回線交換通信網で、2つの交換機が同じトランク上の同じ空き回線を同時に捕捉しようとする状態を指していました。本書では、両方のエージェントが同時に更新オファーを送信しようとした状態を指します。
The higher layer protocol needs to provide a means for resolving such conditions. The higher layer protocol will need to provide a means for ordering of messages in each direction. SIP meets these requirements [7].
上位層プロトコルは、このような状態を解決する手段を提供する必要があります。また、各方向のメッセージを順序付ける手段も提供する必要があります。SIPはこれらの要件を満たしています [7]。
The offer (and answer) MUST be a valid SDP message, as defined by RFC 2327 [1], with one exception. RFC 2327 mandates that either an e or a p line is present in the SDP message. This specification relaxes that constraint; an SDP formulated for an offer/answer application MAY omit both the e and p lines. The numeric value of the session id and version in the o line MUST be representable with a 64 bit signed integer. The initial value of the version MUST be less than (2**62)-1, to avoid rollovers. Although the SDP specification allows for multiple session descriptions to be concatenated together into a large SDP message, an SDP message used in the offer/answer model MUST contain exactly one session description.
オファー（およびアンサー）は、1つの例外を除き、RFC 2327 [1]で定義された有効なSDPメッセージでなければなりません (MUST)。RFC 2327では、SDPメッセージに「e=」行または「p=」行のいずれかを含めることが必須です。本仕様ではこの制約を緩和し、オファー/アンサー用途のSDPでは「e=」行と「p=」行の両方を省略してもよいです (MAY)。オリジン行「o=」のセッションIDとバージョンの数値は、符号付き64ビット整数で表現できなければなりません (MUST)。桁あふれを避けるため、バージョンの初期値は (2**62)-1 未満でなければなりません (MUST)。SDP仕様では複数のセッション記述を連結して1つの大きなSDPメッセージにできますが、オファー/アンサーモデルで使用するSDPメッセージには、セッション記述をちょうど1つ含めなければなりません (MUST)。
The SDP "s=" line conveys the subject of the session, which is reasonably defined for multicast, but ill defined for unicast. For unicast sessions, it is RECOMMENDED that it consist of a single space character (0x20) or a dash (-).
SDPの「s=」行はセッションの主題を示します。マルチキャストでは妥当な意味を持ちますが、ユニキャストでは明確に定義しにくいものです。ユニキャストセッションでは、単一の空白文字 (0x20) またはハイフン (-) だけで構成することが推奨されます (SHOULD)。
Unfortunately, SDP does not allow the "s=" line to be empty.
ただし、SDPでは「s=」行を空にできません。
The SDP "t=" line conveys the time of the session. Generally, streams for unicast sessions are created and destroyed through external signaling means, such as SIP. In that case, the "t=" line SHOULD have a value of "0 0".
SDPの「t=」行はセッションの時間を示します。一般に、ユニキャストセッションのストリームはSIPなどの外部シグナリング手段で作成・終了します。その場合、「t=」行の値は「0 0」とすべきです (SHOULD)。
The offer will contain zero or more media streams (each media stream is described by an "m=" line and its associated attributes). Zero media streams implies that the offerer wishes to communicate, but that the streams for the session will be added at a later time through a modified offer. The streams MAY be for a mix of unicast and multicast; the latter obviously implies a multicast address in the relevant "c=" line(s).
オファーには0個以上のメディアストリームを含められます（各ストリームは「m=」行と関連属性で記述します）。ストリームが0個の場合、オファー側は通信を希望しているものの、変更オファーを通じて後からストリームを追加することを意味します。ストリームにはユニキャストとマルチキャストを混在させてもよく (MAY)、マルチキャストの場合は該当する「c=」行にマルチキャストアドレスを指定します。
Construction of each offered stream depends on whether the stream is multicast or unicast.
提供される各ストリームの構築は、ストリームがマルチキャストかユニキャストかによって異なります。
If the offerer wishes to only send media on a stream to its peer, it MUST mark the stream as sendonly with the "a=sendonly" attribute. We refer to a stream as being marked with a certain direction if a direction attribute was present as either a media stream attribute or a session attribute. If the offerer wishes to only receive media from its peer, it MUST mark the stream as recvonly. If the offerer wishes to communicate, but wishes to neither send nor receive media at this time, it MUST mark the stream with an "a=inactive" attribute. The inactive direction attribute is specified in RFC 3108 [3]. Note that in the case of the Real Time Transport Protocol (RTP) [4], RTCP is still sent and received for sendonly, recvonly, and inactive streams. That is, the directionality of the media stream has no impact on the RTCP usage. If the offerer wishes to both send and receive media with its peer, it MAY include an "a=sendrecv" attribute, or it MAY omit it, since sendrecv is the default.
オファー側がストリームで相手にメディアだけを送信する場合、「a=sendonly」属性を付けなければなりません (MUST)。メディアストリーム属性またはセッション属性のいずれかに方向属性がある場合、そのストリームには指定された方向が設定されているものとします。相手からメディアだけを受信する場合は、ストリームにsendonlyではなくrecvonlyを指定しなければなりません (MUST)。通信は希望するものの、現時点でメディアを送受信しない場合は、「a=inactive」属性を付けなければなりません (MUST)。inactive方向属性はRFC 3108 [3]で規定されています。リアルタイムトランスポートプロトコル（RTP）[4]では、sendonly、recvonly、inactiveのいずれのストリームでもRTCPの送受信は継続します。つまり、メディアストリームの方向はRTCPの使用に影響しません。相手とメディアを送受信する場合は、「a=sendrecv」属性を含めてもよく (MAY)、省略してもよいです (MAY)。sendrecvが既定値です。
For recvonly and sendrecv streams, the port number and address in the offer indicate where the offerer would like to receive the media stream. For sendonly RTP streams, the address and port number indirectly indicate where the offerer wants to receive RTCP reports. Unless there is an explicit indication otherwise, reports are sent to the port number one higher than the number indicated. The IP address and port present in the offer indicate nothing about the source IP address and source port of RTP and RTCP packets that will be sent by the offerer. A port number of zero in the offer indicates that the stream is offered but MUST NOT be used. This has no useful semantics in an initial offer, but is allowed for reasons of completeness, since the answer can contain a zero port indicating a rejected stream (Section 6). Furthermore, existing streams can be terminated by setting the port to zero (Section 8). In general, a port number of zero indicates that the media stream is not wanted.
recvonlyおよびsendrecvストリームでは、オファー内のアドレスとポート番号が、オファー側がメディアストリームを受信したい場所を示します。sendonlyのRTPストリームでは、アドレスとポート番号から、オファー側がRTCPレポートを受信したい場所が間接的に分かります。明示的な指定がなければ、レポートは指定された番号より1大きいポート番号に送信されます。オファー内のIPアドレスとポート番号は、オファー側が送信するRTPおよびRTCPパケットの送信元IPアドレスや送信元ポートを示すものではありません。オファー内のポート番号が0の場合、ストリームは提示されていますが、使用してはなりません (MUST NOT)。初期オファーでは実用上の意味はありませんが、アンサーでポート番号0を使ってストリームを拒否できるよう、仕様の完全性のために認められています（Section 6）。既存ストリームもポート番号を0にすることで終了できます（Section 8）。一般に、ポート番号0はそのメディアストリームが不要であることを示します。
The list of media formats for each media stream conveys two pieces of information, namely the set of formats (codecs and any parameters associated with the codec, in the case of RTP) that the offerer is capable of sending and/or receiving (depending on the direction attributes), and, in the case of RTP, the RTP payload type numbers used to identify those formats. If multiple formats are listed, it means that the offerer is capable of making use of any of those formats during the session. In other words, the answerer MAY change formats in the middle of the session, making use of any of the formats listed, without sending a new offer. For a sendonly stream, the offer SHOULD indicate those formats the offerer is willing to send for this stream. For a recvonly stream, the offer SHOULD indicate those formats the offerer is willing to receive for this stream. For a sendrecv stream, the offer SHOULD indicate those codecs that the offerer is willing to send and receive with.
各メディアストリームのメディア形式一覧は、2つの情報を伝えます。1つは、方向属性に応じてオファー側が送信または受信できる形式の集合（RTPの場合はコーデックと関連パラメーター）であり、もう1つは、RTPの場合に各形式を識別するRTPペイロードタイプ番号です。複数の形式が列挙されていれば、オファー側はセッション中にそのいずれの形式も使用できます。つまり、アンサー側は新しいオファーを送信せずに、列挙された形式のいずれかへセッション途中で切り替えてもよいです (MAY)。sendonlyストリームでは、オファー側がそのストリームで送信する意思のある形式を示すべきです (SHOULD)。recvonlyストリームでは、受信する意思のある形式を示すべきです (SHOULD)。sendrecvストリームでは、送受信する意思のあるコーデックを示すべきです (SHOULD)。
For recvonly RTP streams, the payload type numbers indicate the value of the payload type field in RTP packets the offerer is expecting to receive for that codec. For sendonly RTP streams, the payload type numbers indicate the value of the payload type field in RTP packets the offerer is planning to send for that codec. For sendrecv RTP streams, the payload type numbers indicate the value of the payload type field the offerer expects to receive, and would prefer to send. However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer.
recvonlyのRTPストリームでは、ペイロードタイプ番号は、オファー側がそのコーデックの受信時に想定するRTPパケットのペイロードタイプフィールドの値を示します。sendonlyのRTPストリームでは、オファー側がそのコーデックの送信に使う予定の値を示します。sendrecvのRTPストリームでは、受信時に想定する値と、送信時に優先して使う値を示します。ただし、sendonlyおよびsendrecvストリームでは、アンサーが同じコーデックに異なるペイロードタイプ番号を指定する場合があります。その場合、オファー側はアンサーに記載されたペイロードタイプ番号を使って送信しなければなりません (MUST)。
Different payload type numbers may be needed in each direction because of interoperability concerns with H.323.
H.323との相互運用性の懸念のため、各方向に異なるペイロードタイプ数が必要になる場合があります。
As per RFC 2327, fmtp parameters MAY be present to provide additional parameters of the media format.
RFC 2327に従い、メディア形式に関する追加パラメーターを示すためにfmtpパラメーターを含めてもよいです (MAY)。
In the case of RTP streams, all media descriptions SHOULD contain "a=rtpmap" mappings from RTP payload types to encodings. If there is no "a=rtpmap", the default payload type mapping, as defined by the current profile in use (for example, RFC 1890 [5]) is to be used.
RTPストリームの場合、すべてのメディアの説明には、RTPペイロードタイプからエンコーディングへの「a=rtpmap」マッピングを含めるべきです (SHOULD)。「a=rtpmap」がない場合、使用中の現在のプロファイル（たとえば、RFC 1890 [5]）で定義されているデフォルトのペイロードタイプマッピングが使用されます。
This allows easier migration away from static payload types.
これにより、静的なペイロードタイプから簡単に移行できます。
In all cases, the formats in the "m=" line MUST be listed in order of preference, with the first format listed being preferred. In this case, preferred means that the recipient of the offer SHOULD use the format with the highest preference that is acceptable to it.
いずれの場合も、「m=」行の形式は優先順位順に列挙し、最初の形式を最優先にしなければなりません (MUST)。ここでいう優先とは、オファーの受信者が受け入れ可能な形式のうち、最も優先順位の高いものを使用すべきであることを意味します (SHOULD)。
If the ptime attribute is present for a stream, it indicates the desired packetization interval that the offerer would like to receive. The ptime attribute MUST be greater than zero.
ストリームにptime属性がある場合、その値はオファー側が受信したいパケット化間隔を示します。ptime属性の値は0より大きくなければなりません (MUST)。
If the bandwidth attribute is present for a stream, it indicates the desired bandwidth that the offerer would like to receive. A value of zero is allowed, but discouraged. It indicates that no media should be sent. In the case of RTP, it would also disable all RTCP.
ストリームに帯域幅属性がある場合、その値はオファー側が受信したい帯域幅を示します。値0も認められますが、推奨されません。値0はメディアを送信しないことを示し、RTPの場合はすべてのRTCPも無効にします。
If multiple media streams of different types are present, it means that the offerer wishes to use those streams at the same time. A typical case is an audio and a video stream as part of a videoconference.
異なるタイプの複数のメディアストリームが存在する場合、それは提供者がそれらのストリームを同時に使用したいことを意味します。典型的なケースは、ビデオ会議の一部としてのオーディオとビデオストリームです。
If multiple media streams of the same type are present in an offer, it means that the offerer wishes to send (and/or receive) multiple streams of that type at the same time. When sending multiple streams of the same type, it is a matter of local policy as to how each media source of that type (for example, a video camera and VCR in the case of video) is mapped to each stream. When a user has a single source for a particular media type, only one policy makes sense: the source is sent to each stream of the same type. Each stream MAY use different encodings. When receiving multiple streams of the same type, it is a matter of local policy as to how each stream is mapped to the various media sinks for that particular type (for example, speakers or a recording device in the case of audio). There are a few constraints on the policies, however. First, when receiving multiple streams of the same type, each stream MUST be mapped to at least one sink for the purpose of presentation to the user. In other words, the intent of receiving multiple streams of the same type is that they should all be presented in parallel, rather than choosing just one. Another constraint is that when multiple streams are received and sent to the same sink, they MUST be combined in some media specific way. For example, in the case of two audio streams, the received media from each might be mapped to the speakers. In that case, the combining operation would be to mix them. In the case of multiple instant messaging streams, where the sink is the screen, the combining operation would be to present all of them to the user interface. The third constraint is that if multiple sources are mapped to the same stream, those sources MUST be combined in some media specific way before they are sent on the stream. Although policies beyond these constraints are flexible, an agent won't generally want a policy that will copy media from its sinks to its sources unless it is a conference server (i.e., don't copy received media on one stream to another stream).
オファーに同じ種類のメディアストリームが複数含まれる場合、オファー側はその種類のストリームを同時に複数送信または受信することを希望しています。同じ種類のストリームを複数送信するとき、各メディアソース（映像の場合はカメラやビデオデッキなど）を各ストリームに割り当てる方法はローカルポリシーで決めます。特定のメディア種類についてソースが1つしかない場合、そのソースを同じ種類の各ストリームに送信する方法が適切です。各ストリームで異なる符号化方式を使ってもよいです (MAY)。同じ種類のストリームを複数受信するとき、各ストリームをその種類のメディア出力先（音声の場合はスピーカーや録音装置など）にどう割り当てるかもローカルポリシーで決めます。ただし、いくつか制約があります。第一に、同じ種類のストリームを複数受信する場合、ユーザーに提示するため、各ストリームを少なくとも1つの出力先に割り当てなければなりません (MUST)。つまり、1つだけを選ぶのではなく、すべてのストリームを並行して提示することを意図しています。第二に、複数のストリームを同じ出力先に送る場合、メディアの種類に応じた方法でそれらを結合しなければなりません (MUST)。たとえば、2つの音声ストリームなら、両方の受信音声をスピーカーに割り当ててミキシングします。複数のインスタントメッセージストリームを画面に出力する場合は、すべてをユーザーインターフェイスに表示します。第三に、複数のソースを同じストリームに割り当てる場合、送信前にメディアの種類に応じた方法でソースを結合しなければなりません (MUST)。これらの制約以外のポリシーは柔軟ですが、会議サーバーでないエージェントが通常、出力先から入力元へメディアをコピーすることは望ましくありません（つまり、あるストリームで受信したメディアを別のストリームへコピーしないようにします）。
A typical usage example for multiple media streams of the same type is a pre-paid calling card application, where the user can press and hold the pound ("#") key at any time during a call to hangup and make a new call on the same card. This requires media from the user to two destinations - the remote gateway, and the DTMF processing application which looks for the pound. This could be accomplished with two media streams, one sendrecv to the gateway, and the other sendonly (from the perspective of the user) to the DTMF application.
同じ種類のメディアストリームを複数使う典型例は、プリペイド通話カードです。通話中、ユーザーはいつでも「#」キーを長押しして通話を終了し、同じカードで新しい通話を開始できます。そのため、ユーザーのメディアをリモートゲートウェイと、#キーを検出するDTMF処理アプリケーションの2つの宛先へ送る必要があります。これは、ゲートウェイ向けのsendrecvストリームと、ユーザー側から見てDTMFアプリケーション向けのsendonlyストリームを使って実現できます。
Once the offerer has sent the offer, it MUST be prepared to receive media for any recvonly streams described by that offer. It MUST be prepared to send and receive media for any sendrecv streams in the offer, and send media for any sendonly streams in the offer (of course, it cannot actually send until the peer provides an answer with the needed address and port information). In the case of RTP, even though it may receive media before the answer arrives, it will not be able to send RTCP receiver reports until the answer arrives.
オファー側はオファーを送信した時点で、そのオファーに記述されたrecvonlyストリームのメディアを受信できる状態でなければなりません (MUST)。また、オファー内のsendrecvストリームではメディアを送受信でき、sendonlyストリームではメディアを送信できる状態でなければなりません (MUST)。ただし、必要なアドレスとポート情報を含むアンサーを相手から受け取るまでは、実際に送信できません。RTPの場合、アンサーの到着前にメディアを受信することはあっても、アンサーを受け取るまではRTCP受信レポートを送信できません。
If a session description contains a multicast media stream which is listed as receive (send) only, it means that the participants, including the offerer and answerer, can only receive (send) on that stream. This differs from the unicast view, where the directionality refers to the flow of media between offerer and answerer.
セッション記述に受信専用（または送信専用）として示されたマルチキャストメディアストリームが含まれる場合、オファー側とアンサー側を含む全参加者が、そのストリームについて受信（または送信）だけを行えることを意味します。これは、方向がオファー側とアンサー側の間のメディアの流れを表すユニキャストとは異なります。
Beyond that clarification, the semantics of an offered multicast stream are exactly as described in RFC 2327 [1].
その明確化を超えて、提供されたマルチキャストストリームのセマンティクスは、RFC 2327 [1]で説明されているとおりです。
The answer to an offered session description is based on the offered session description. If the answer is different from the offer in any way (different IP addresses, ports, etc.), the origin line MUST be different in the answer, since the answer is generated by a different entity. In that case, the version number in the "o=" line of the answer is unrelated to the version number in the o line of the offer.
提示されたセッション記述へのアンサーは、そのオファーに基づいて作成します。IPアドレスやポートなど、何らかの点でアンサーがオファーと異なる場合、別のエンティティがアンサーを生成するため、アンサーのオリジン行はオファーのものと異ならなければなりません (MUST)。この場合、アンサーの「o=」行のバージョン番号は、オファーの「o=」行のバージョン番号とは無関係です。
For each "m=" line in the offer, there MUST be a corresponding "m=" line in the answer. The answer MUST contain exactly the same number of "m=" lines as the offer. This allows for streams to be matched up based on their order. This implies that if the offer contained zero "m=" lines, the answer MUST contain zero "m=" lines.
オファー内の各「m=」行に対応する「m=」行を、アンサーに含めなければなりません (MUST)。アンサーには、オファーとまったく同じ数の「m=」行を含めなければなりません (MUST)。これにより、行の順序に基づいてストリームを対応付けられます。したがって、オファーに「m=」行が0個の場合、アンサーにも0個含めなければなりません (MUST)。
The "t=" line in the answer MUST equal that of the offer. The time of the session cannot be negotiated.
アンサーの「t=」行は、オファーの「t=」行と等しくなければなりません (MUST)。セッションの時間は交渉できません。
An offered stream MAY be rejected in the answer, for any reason. If a stream is rejected, the offerer and answerer MUST NOT generate media (or RTCP packets) for that stream. To reject an offered stream, the port number in the corresponding stream in the answer MUST be set to zero. Any media formats listed are ignored. At least one MUST be present, as specified by SDP.
どのような理由であっても、アンサーでオファーされたストリームを拒否してもよいです (MAY)。ストリームを拒否した場合、オファー側とアンサー側は、そのストリームのメディア（またはRTCPパケット）を生成してはなりません (MUST NOT)。拒否するには、アンサー内の対応するストリームのポート番号を0に設定しなければなりません (MUST)。列挙されたメディア形式は無視します。SDPの規定に従い、少なくとも1つの形式を含めなければなりません (MUST)。
Constructing an answer for each offered stream differs for unicast and multicast.
提供される各ストリームの回答を構築することは、ユニキャストとマルチキャストの場合は異なります。
If a stream is offered with a unicast address, the answer for that stream MUST contain a unicast address. The media type of the stream in the answer MUST match that of the offer.
ストリームがユニキャストアドレスで提示された場合、そのストリームへのアンサーにもユニキャストアドレスを含めなければなりません (MUST)。アンサー内のストリームのメディア種類は、オファーのものと一致しなければなりません (MUST)。
If a stream is offered as sendonly, the corresponding stream MUST be marked as recvonly or inactive in the answer. If a media stream is listed as recvonly in the offer, the answer MUST be marked as sendonly or inactive in the answer. If an offered media stream is listed as sendrecv (or if there is no direction attribute at the media or session level, in which case the stream is sendrecv by default), the corresponding stream in the answer MAY be marked as sendonly, recvonly, sendrecv, or inactive. If an offered media stream is listed as inactive, it MUST be marked as inactive in the answer.
ストリームがsendonlyとして提示された場合、アンサーでは対応するストリームをrecvonlyまたはinactiveにしなければなりません (MUST)。オファーのメディアストリームがrecvonlyの場合、アンサーでは対応するストリームをsendonlyまたはinactiveにしなければなりません (MUST)。オファーのメディアストリームがsendrecvの場合（メディアレベルにもセッションレベルにも方向属性がなければ、既定でsendrecvです）、アンサーでは対応するストリームをsendonly、recvonly、sendrecv、またはinactiveにしてもよいです (MAY)。オファーのメディアストリームがinactiveの場合、アンサーでもinactiveにしなければなりません (MUST)。
For streams marked as recvonly in the answer, the "m=" line MUST contain at least one media format the answerer is willing to receive with from amongst those listed in the offer. The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to receive. For streams marked as sendonly in the answer, the "m=" line MUST contain at least one media format the answerer is willing to send from amongst those listed in the offer. For streams marked as sendrecv in the answer, the "m=" line MUST contain at least one codec the answerer is willing to both send and receive, from amongst those listed in the offer. The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive (of course, it will not be able to send them at this time, since it was not listed in the offer). For streams marked as inactive in the answer, the list of media formats is constructed based on the offer. If the offer was sendonly, the list is constructed as if the answer were recvonly. Similarly, if the offer was recvonly, the list is constructed as if the answer were sendonly, and if the offer was sendrecv, the list is constructed as if the answer were sendrecv. If the offer was inactive, the list is constructed as if the offer were actually sendrecv and the answer were sendrecv.
アンサーでrecvonlyとしたストリームでは、「m=」行に、オファーに列挙された形式のうちアンサー側が受信を希望するものを少なくとも1つ含めなければなりません (MUST)。オファーの対応するストリームにない形式でも、アンサー側が受信を希望するものを追加で示してもよいです (MAY)。sendonlyとしたストリームでは、「m=」行に、オファーに列挙された形式のうちアンサー側が送信を希望するものを少なくとも1つ含めなければなりません (MUST)。sendrecvとしたストリームでは、「m=」行に、オファーに列挙されたコーデックのうちアンサー側が送受信を希望するものを少なくとも1つ含めなければなりません (MUST)。また、アンサーの対応ストリームにない形式でも、送信または受信を希望するものを追加で示してもよいです (MAY)。ただし、オファーに含まれていない形式は、この時点では送信できません。アンサーでinactiveとしたストリームのメディア形式一覧はオファーに基づいて作成します。オファーがsendonlyならアンサーをrecvonlyとした場合と同様に、オファーがrecvonlyならアンサーをsendonlyとした場合と同様に、オファーがsendrecvならアンサーもsendrecvとした場合と同様に一覧を作成します。オファーがinactiveなら、オファーとアンサーの両方をsendrecvとした場合と同様に一覧を作成します。
The connection address and port in the answer indicate the address where the answerer wishes to receive media (in the case of RTP, RTCP will be received on the port which is one higher unless there is an explicit indication otherwise). This address and port MUST be present even for sendonly streams; in the case of RTP, the port one higher is still used to receive RTCP.
アンサーの接続アドレスとポート番号は、アンサー側がメディアを受信したいアドレスを示します。RTPの場合、明示的な指定がなければ、RTCPはそのポート番号より1大きいポートで受信します。このアドレスとポート番号はsendonlyストリームでも指定しなければなりません (MUST)。RTPでは、その場合も1つ大きいポート番号をRTCP受信用に使います。
In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer. Even if the same payload type number is used, the answer MUST contain rtpmap attributes to define the payload type mappings for dynamic payload types, and SHOULD contain mappings for static payload types. The media formats in the "m=" line MUST be listed in order of preference, with the first format listed being preferred. In this case, preferred means that the offerer SHOULD use the format with the highest preference from the answer.
RTPの場合、オファーで特定のコーデックが特定のペイロードタイプ番号で参照されていた場合、アンサーでもそのコーデックに同じペイロードタイプ番号を使用すべきです (SHOULD)。同じペイロードタイプ番号を使用する場合でも、アンサーには、動的ペイロードタイプのペイロードタイプマッピングを定義するrtpmap属性を含めなければならず (MUST)、静的ペイロードタイプのマッピングも含めるべきです (SHOULD)。「m=」行のメディア形式は優先順に列挙しなければならず (MUST)、最初に列挙された形式が最も優先されます。この場合の優先とは、オファー側がアンサーの中で最も優先度の高い形式を使用すべき (SHOULD) であることを意味します。
Although the answerer MAY list the formats in their desired order of preference, it is RECOMMENDED that unless there is a specific reason, the answerer list formats in the same relative order they were present in the offer. In other words, if a stream in the offer lists audio codecs 8, 22 and 48, in that order, and the answerer only supports codecs 8 and 48, it is RECOMMENDED that, if the answerer has no reason to change it, the ordering of codecs in the answer be 8, 48, and not 48, 8. This helps assure that the same codec is used in both directions.
アンサー側は、希望する優先順位で形式を列挙してもよいです (MAY)。ただし、特別な理由がない限り、オファーと同じ相対順で列挙することが推奨されます (SHOULD)。たとえば、オファーが音声コーデック8、22、48をこの順に列挙し、アンサー側が8と48だけをサポートする場合、順序を変える理由がなければ、48、8ではなく8、48の順にすることが推奨されます (SHOULD)。これにより、両方向で同じコーデックを使いやすくなります。
The interpretation of fmtp parameters in an offer depends on the parameters. In many cases, those parameters describe specific configurations of the media format, and should therefore be processed as the media format value itself would be. This means that the same fmtp parameters with the same values MUST be present in the answer if the media format they describe is present in the answer. Other fmtp parameters are more like parameters, for which it is perfectly acceptable for each agent to use different values. In that case, the answer MAY contain fmtp parameters, and those MAY have the same values as those in the offer, or they MAY be different. SDP extensions that define new parameters SHOULD specify the proper interpretation in offer/answer.
オファー内のfmtpパラメーターの解釈は、そのパラメーターの種類によって異なります。多くの場合、パラメーターはメディア形式の具体的な構成を記述するため、メディア形式の値そのものと同様に処理します。その場合、対象のメディア形式がアンサーに含まれるなら、同じ値を持つ同じfmtpパラメーターをアンサーにも含めなければなりません (MUST)。一方、各エージェントが異なる値を使っても問題のないパラメーターもあります。その場合、アンサーにfmtpパラメーターを含めてもよく (MAY)、その値はオファーと同じでもよく (MAY)、異なっていてもよいです (MAY)。新しいパラメーターを定義するSDP拡張では、オファー/アンサーでの適切な解釈を規定すべきです (SHOULD)。
The answerer MAY include a non-zero ptime attribute for any media stream; this indicates the packetization interval that the answerer would like to receive. There is no requirement that the packetization interval be the same in each direction for a particular stream.
アンサー側は、任意のメディアストリームに0以外のptime属性を含めてもよいです (MAY)。これは、アンサー側が受信したいパケット化間隔を示します。特定のストリームで、送信方向と受信方向のパケット化間隔を同じにする必要はありません。
The answerer MAY include a bandwidth attribute for any media stream; this indicates the bandwidth that the answerer would like the offerer to use when sending media. The value of zero is allowed, interpreted as described in Section 5.
アンサー側は、任意のメディアストリームに帯域幅属性を含めてもよいです (MAY)。これは、アンサー側がメディア送信時にオファー側へ使ってほしい帯域幅を示します。値0も認められ、その解釈はSection 5で説明したとおりです。
If the answerer has no media formats in common for a particular offered stream, the answerer MUST reject that media stream by setting the port to zero.
応答者に特定の提供されたストリームについて共通のメディア形式がない場合、回答者はポートをゼロに設定することにより、そのメディアストリームを拒否しなければなりません (MUST)。
If there are no media formats in common for all streams, the entire offered session is rejected.
すべてのストリームに共通のメディア形式がない場合、提供されたセッション全体が拒否されます。
Once the answerer has sent the answer, it MUST be prepared to receive media for any recvonly streams described by that answer. It MUST be prepared to send and receive media for any sendrecv streams in the answer, and it MAY send media immediately. The answerer MUST be prepared to receive media for recvonly or sendrecv streams using any media formats listed for those streams in the answer, and it MAY send media immediately. When sending media, it SHOULD use a packetization interval equal to the value of the ptime attribute in the offer, if any was present. It SHOULD send media using a bandwidth no higher than the value of the bandwidth attribute in the offer, if any was present. The answerer MUST send using a media format in the offer that is also listed in the answer, and SHOULD send using the most preferred media format in the offer that is also listed in the answer. In the case of RTP, it MUST use the payload type numbers from the offer, even if they differ from those in the answer.
アンサー側は、アンサーを送信した後、そのアンサーで記述されたすべてのrecvonlyストリームについてメディアを受信できるよう準備しなければなりません (MUST)。アンサー内のすべてのsendrecvストリームについてメディアを送受信できるよう準備しなければならず (MUST)、直ちにメディアを送信してもよいです (MAY)。アンサー側は、アンサー内でrecvonlyまたはsendrecvストリームに対して列挙されたいずれのメディア形式を使用したメディアも受信できるよう準備しなければならず (MUST)、直ちにメディアを送信してもよいです (MAY)。メディアを送信する際、オファーにptime属性が存在した場合は、その値に等しいパケット化間隔を使用すべきです (SHOULD)。オファーに帯域幅属性が存在した場合は、その値を超えない帯域幅でメディアを送信すべきです (SHOULD)。アンサー側は、オファー内のメディア形式のうち、アンサーにも列挙されている形式を使用して送信しなければならず (MUST)、アンサーにも列挙されている形式のうちオファーで最も優先度の高いメディア形式を使用して送信すべきです (SHOULD)。RTPの場合、アンサー内のものと異なる場合でも、オファーのペイロードタイプ番号を使用しなければなりません (MUST)。
Unlike unicast, where there is a two-sided view of the stream, there is only a single view of the stream for multicast. As such, generating an answer to a multicast offer generally involves modifying a limited set of aspects of the stream.
ユニキャストではストリームを両者の視点から捉えますが、マルチキャストではストリームの視点は1つだけです。そのため、マルチキャストオファーへのアンサーでは、通常、ストリームの限られた側面だけを変更します。
If a multicast stream is accepted, the address and port information in the answer MUST match that of the offer. Similarly, the directionality information in the answer (sendonly, recvonly, or sendrecv) MUST equal that of the offer. This is because all participants in a multicast session need to have equivalent views of the parameters of the session, an underlying assumption of the multicast bias of RFC 2327.
マルチキャストストリームを受け入れる場合、アンサーのアドレスとポート情報はオファーのものと一致しなければなりません (MUST)。同様に、アンサーの方向情報（sendonly、recvonly、sendrecv）もオファーのものと一致しなければなりません (MUST)。これは、マルチキャストセッションの全参加者がセッションパラメーターについて同じ認識を持つ必要があるためです。これはRFC 2327がマルチキャストを前提としていることの根本にあります。
The set of media formats in the answer MUST be equal to or be a subset of those in the offer. Removing a format is a way for the answerer to indicate that the format is not supported.
アンサーのメディア形式の集合は、オファーの集合と等しいか、その部分集合でなければなりません (MUST)。形式を削除することで、アンサー側はその形式をサポートしていないことを示せます。
The ptime and bandwidth attributes in the answer MUST equal the ones in the offer, if present. If not present, a non-zero ptime MAY be added to the answer.
アンサーにptime属性または帯域幅属性がある場合、その値はオファーの値と等しくなければなりません (MUST)。オファーにptime属性がない場合は、0以外の値をアンサーに追加してもよいです (MAY)。
When the offerer receives the answer, it MAY send media on the accepted stream(s) (assuming it is listed as sendrecv or recvonly in the answer). It MUST send using a media format listed in the answer, and it SHOULD use the first media format listed in the answer when it does send.
アンサーを受信したオファー側は、受け入れられたストリーム（アンサーでsendrecvまたはrecvonlyと指定されたもの）でメディアを送信してもよいです (MAY)。送信する場合、アンサーに列挙されたメディア形式を使わなければならず (MUST)、アンサーで最初に列挙された形式を使うべきです (SHOULD)。
The reason this is a SHOULD, and not a MUST (its also a SHOULD, and not a MUST, for the answerer), is because there will oftentimes be a need to change codecs on the fly. For example, during silence periods, an agent might like to switch to a comfort noise codec. Or, if the user presses a number on the keypad, the agent might like to send that using RFC 2833 [9]. Congestion control might necessitate changing to a lower rate codec based on feedback.
この形式をMUSTではなくSHOULDとしているのは、アンサー側についても同じですが、コーデックを状況に応じて変更する必要が生じることが多いためです。たとえば、無音期間中にエージェントがコンフォートノイズ用コーデックへ切り替えることがあります。ユーザーがキーパッドの数字を押した場合、エージェントがRFC 2833 [9]を使ってその信号を送信することもあります。輻輳制御では、フィードバックに応じてより低ビットレートのコーデックへの切り替えが必要になることがあります。
The offerer SHOULD send media according to the value of any ptime and bandwidth attribute in the answer.
オファー側は、アンサー内のptime属性および帯域幅属性の値に従ってメディアを送信すべきです (SHOULD)。
The offerer MAY immediately cease listening for media formats that were listed in the initial offer, but not present in the answer.
オファー側は、初期オファーに列挙されていてアンサーには含まれないメディア形式の受信待ちを、直ちに終了してもよいです (MAY)。
At any point during the session, either participant MAY issue a new offer to modify characteristics of the session. It is fundamental to the operation of the offer/answer model that the exact same offer/answer procedure defined above is used for modifying parameters of an existing session.
セッション中のいつでも、どちらの参加者もセッションの特性を変更する新しいオファーを発行してもよいです (MAY)。オファー/アンサーモデルでは、既存セッションのパラメーター変更にも、前述のものとまったく同じ手順を使うことが基本です。
The offer MAY be identical to the last SDP provided to the other party (which may have been provided in an offer or an answer), or it MAY be different. We refer to the last SDP provided as the "previous SDP". If the offer is the same, the answer MAY be the same as the previous SDP from the answerer, or it MAY be different. If the offered SDP is different from the previous SDP, some constraints are placed on its construction, discussed below.
オファーは、相手に最後に渡したSDP（オファーまたはアンサーとして渡したもの）と同一でもよく (MAY)、異なっていてもよいです (MAY)。最後に渡したSDPを「以前のSDP」と呼びます。オファーが以前のSDPと同一の場合、アンサーもアンサー側が以前に渡したSDPと同一でもよく (MAY)、異なっていてもよいです (MAY)。オファーされたSDPが以前のSDPと異なる場合、その構成には以下で説明する制約が適用されます。
Nearly all aspects of the session can be modified. New streams can be added, existing streams can be deleted, and parameters of existing streams can change. When issuing an offer that modifies the session, the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. The answerer MUST be prepared to receive an offer that contains SDP with a version that has not changed; this is effectively a no-op. However, the answerer MUST generate a valid answer (which MAY be the same as the previous SDP from the answerer, or MAY be different), according to the procedures defined in Section 6.
セッションのほぼすべての特性を変更できます。新しいストリームの追加、既存ストリームの削除、既存ストリームのパラメーター変更が可能です。セッションを変更するオファーを発行する場合、新しいSDPの「o=」行は以前のSDPのものと同一でなければなりません (MUST)。ただし、originフィールドのバージョン番号は以前のSDPから1増やさなければなりません (MUST)。origin行のバージョン番号を増やさない場合、SDPはそのバージョン番号を持つ以前のSDPと同一でなければなりません (MUST)。アンサー側は、バージョン番号が変わっていないSDPを含むオファーも受信できるよう準備しなければなりません (MUST)。これは実質的に何もしない操作です。それでもアンサー側は、Section 6の手順に従って有効なアンサーを生成しなければなりません (MUST)。そのアンサーは、アンサー側が以前に送ったSDPと同一でもよく (MAY)、異なっていてもよいです (MAY)。
If an SDP is offered, which is different from the previous SDP, the new SDP MUST have a matching media stream for each media stream in the previous SDP. In other words, if the previous SDP had N "m=" lines, the new SDP MUST have at least N "m=" lines. The i-th media stream in the previous SDP, counting from the top, matches the i-th media stream in the new SDP, counting from the top. This matching is necessary in order for the answerer to determine which stream in the new SDP corresponds to a stream in the previous SDP. Because of these requirements, the number of "m=" lines in a stream never decreases, but either stays the same or increases. Deleted media streams from a previous SDP MUST NOT be removed in a new SDP; however, attributes for these streams need not be present.
以前のSDPと異なるSDPをオファーする場合、新しいSDPには以前のSDPの各メディアストリームに対応するストリームを含めなければなりません (MUST)。つまり、以前のSDPに「m=」行がN個あるなら、新しいSDPには少なくともN個の「m=」行を含めなければなりません (MUST)。上から数えた以前のSDPのi番目のメディアストリームは、新しいSDPのi番目のメディアストリームに対応します。アンサー側が新しいSDPのどのストリームが以前のSDPのどのストリームに対応するか判定するには、この対応付けが必要です。したがって、ストリーム内の「m=」行の数は減らず、同じ数を維持するか増加します。以前のSDPから削除したメディアストリームを新しいSDPから取り除いてはなりません (MUST NOT)。ただし、それらのストリームの属性は省略できます。
New media streams are created by new additional media descriptions below the existing ones, or by reusing the "slot" used by an old media stream which had been disabled by setting its port to zero.
新しいメディアストリームは、既存のメディア記述の後ろに新しいメディア記述を追加するか、ポート番号を0にして無効化した古いメディアストリームの「スロット」を再利用することで作成します。
Reusing its slot means that the new media description replaces the old one, but retains its positioning relative to other media descriptions in the SDP. New media descriptions MUST appear below any existing media sections. The rules for formatting these media descriptions are identical to those described in Section 5.
スロットの再利用とは、新しいメディア記述で古い記述を置き換えながら、SDP内の他のメディア記述に対する位置を維持することです。新しいメディア記述は既存のすべてのメディアセクションより後ろに置かなければなりません (MUST)。記述の形式はSection 5で説明したものと同じです。
When the answerer receives an SDP with more media descriptions than the previous SDP from the offerer, or it receives an SDP with a media stream in a slot where the port was previously zero, the answerer knows that new media streams are being added. These can be rejected or accepted by placing an appropriately structured media description in the answer. The procedures for constructing the new media description in the answer are described in Section 6.
アンサー側が、オファー側から以前に受信したSDPより多くのメディア記述を含むSDPを受信した場合、またはポート番号が以前0だったスロットにメディアストリームを含むSDPを受信した場合、新しいメディアストリームが追加されたと分かります。適切な形式のメディア記述をアンサーに含めることで、新しいストリームを拒否または受け入れられます。アンサー内で新しいメディア記述を作成する手順はSection 6で説明します。
Existing media streams are removed by creating a new SDP with the port number for that stream set to zero. The stream description MAY omit all attributes present previously, and MAY list just a single media format.
既存のメディアストリームを削除するには、そのストリームのポート番号を0にした新しいSDPを作成します。ストリーム記述では、以前の属性をすべて省略してもよく (MAY)、メディア形式を1つだけ列挙してもよいです (MAY)。
A stream that is offered with a port of zero MUST be marked with port zero in the answer. Like the offer, the answer MAY omit all attributes present previously, and MAY list just a single media format from amongst those in the offer.
ポート番号0で提示されたストリームは、アンサーでもポート番号0にしなければなりません (MUST)。オファーと同様に、アンサーでは以前の属性をすべて省略してもよく (MAY)、オファーに含まれる形式のうち1つだけを列挙してもよいです (MAY)。
Removal of a media stream implies that media is no longer sent for that stream, and any media that is received is discarded. In the case of RTP, RTCP transmission also ceases, as does processing of any received RTCP packets. Any resources associated with it can be released. The user interface might indicate that the stream has terminated, by closing the associated window on a PC, for example.
メディアストリームを削除すると、そのストリームのメディアは送信されなくなり、受信したメディアは破棄されます。RTPの場合、RTCPの送信と、受信したRTCPパケットの処理も停止します。関連するリソースは解放できます。たとえば、PC上のユーザーインターフェイスでは、関連ウィンドウを閉じてストリームの終了を示すことがあります。
Nearly all characteristics of a media stream can be modified.
メディアストリームのほぼすべての特性を変更できます。
The port number for a stream MAY be changed. To do this, the offerer creates a new media description, with the port number in the m line different from the corresponding stream in the previous SDP. If only the port number is to be changed, the rest of the media stream description SHOULD remain unchanged. The offerer MUST be prepared to receive media on both the old and new ports as soon as the offer is sent. The offerer SHOULD NOT cease listening for media on the old port until the answer is received and media arrives on the new port. Doing so could result in loss of media during the transition.
ストリームのポート番号を変更してもよいです (MAY)。その場合、オファー側は新しいメディア記述を作成し、「m=」行のポート番号を以前のSDP内の対応するストリームと異なる値にします。ポート番号だけを変更する場合、メディアストリーム記述の他の部分は変更しないことが推奨されます (SHOULD)。オファー側は、オファーを送信した時点から旧ポートと新ポートの両方でメディアを受信できる状態でなければなりません (MUST)。アンサーを受信し、新ポートにメディアが到着するまでは、旧ポートでの受信待ちを終了すべきではありません (SHOULD NOT)。早く終了すると、切り替え中にメディアが失われるおそれがあります。
Received, in this case, means that the media is passed to a media sink. This means that if there is a playout buffer, the agent would continue to listen on the old port until the media on the new port reached the top of the playout buffer. At that time, it MAY cease listening for media on the old port.
ここでいう「受信」とは、メディアがメディア出力先に渡されることです。プレイアウトバッファがある場合、新ポートから受信したメディアがバッファの先頭に達するまで、エージェントは旧ポートでの受信を続けます。その時点で旧ポートでの受信待ちを終了してもよいです (MAY)。
The corresponding media stream in the answer MAY be the same as the stream in the previous SDP from the answerer, or it MAY be different. If the updated stream is accepted by the answerer, the answerer SHOULD begin sending traffic for that stream to the new port immediately. If the answerer changes the port from the previous SDP, it MUST be prepared to receive media on both the old and new ports as soon as the answer is sent. The answerer MUST NOT cease listening for media on the old port until media arrives on the new port. At that time, it MAY cease listening for media on the old port. The same is true for an offerer that sends an updated offer with a new port; it MUST NOT cease listening for media on the old port until media arrives on the new port.
アンサー内の対応するメディアストリームは、アンサー側が以前に送信したSDP内のストリームと同一でもよく (MAY)、異なっていてもよいです (MAY)。更新されたストリームが受け入れられた場合、アンサー側はそのストリームのトラフィックを直ちに新ポートへ送信し始めるべきです (SHOULD)。アンサー側が以前のSDPからポート番号を変更した場合、アンサーを送信した時点から旧ポートと新ポートの両方でメディアを受信できる状態でなければなりません (MUST)。新ポートにメディアが到着するまでは、旧ポートでの受信待ちを終了してはなりません (MUST NOT)。到着後は旧ポートでの受信待ちを終了してもよいです (MAY)。新しいポート番号で更新オファーを送信するオファー側についても同様で、新ポートにメディアが到着するまでは旧ポートでの受信待ちを終了してはなりません (MUST NOT)。
Of course, if the offered stream is rejected, the offerer can cease being prepared to receive using the new port as soon as the rejection is received.
もちろん、提示したストリームが拒否された場合、拒否を受信した時点で、オファー側は新ポートで受信できる状態を解除できます。
To change the IP address where media is sent to, the same procedure is followed for changing the port number. The only difference is that the connection line is updated, not the port number.
メディアの送信先IPアドレスを変更する場合も、ポート番号の変更と同じ手順を使います。異なるのは、ポート番号ではなく接続行を更新する点だけです。
The transport for a stream MAY be changed. The process for doing this is identical to changing the port, except the transport is updated, not the port.
ストリームのトランスポートを変更してもよいです (MAY)。手順はポート番号の変更と同じですが、ポート番号ではなくトランスポートを更新します。
The list of media formats used in the session MAY be changed. To do this, the offerer creates a new media description, with the list of media formats in the "m=" line different from the corresponding media stream in the previous SDP. This list MAY include new formats, and MAY remove formats present from the previous SDP. However, in the case of RTP, the mapping from a particular dynamic payload type number to a particular codec within that media stream MUST NOT change for the duration of a session. For example, if A generates an offer with G.711 assigned to dynamic payload type number 46, payload type number 46 MUST refer to G.711 from that point forward in any offers or answers for that media stream within the session. However, it is acceptable for multiple payload type numbers to be mapped to the same codec, so that an updated offer could also use payload type number 72 for G.711.
セッションで使用するメディア形式の一覧を変更してもよいです (MAY)。その場合、オファー側は新しいメディア記述を作成し、「m=」行の一覧を以前のSDP内の対応するストリームと異なるものにします。この一覧には新しい形式を含めてもよく (MAY)、以前のSDPにあった形式を削除してもよいです (MAY)。ただしRTPでは、特定の動的ペイロードタイプ番号と、そのメディアストリーム内の特定コーデックとの対応を、セッション中に変更してはなりません (MUST NOT)。たとえば、Aが動的ペイロードタイプ番号46をG.711に割り当ててオファーを生成した場合、その後の当該セッション内の同じメディアストリームに関するオファーおよびアンサーでは、ペイロードタイプ番号46をG.711に対応させなければなりません (MUST)。ただし、複数のペイロードタイプ番号を同じコーデックに対応させることは許容されるため、更新オファーでG.711に番号72を使うこともできます。
The mappings need to remain fixed for the duration of the session because of the loose synchronization between signaling exchanges of SDP and the media stream.
この対応付けをセッション中に固定する必要があるのは、SDPのシグナリング交換とメディアストリームとの同期が緩やかだからです。
The corresponding media stream in the answer is formulated as described in Section 6, and may result in a change in media formats as well. Similarly, as described in Section 6, as soon as it sends its answer, the answerer MUST begin sending media using any formats in the offer that were also present in the answer, and SHOULD use the most preferred format in the offer that was also listed in the answer (assuming the stream allows for sending), and MUST NOT send using any formats that are not in the offer, even if they were present in a previous SDP from the peer. Similarly, when the offerer receives the answer, it MUST begin sending media using any formats in the answer, and SHOULD use the most preferred one (assuming the stream allows for sending), and MUST NOT send using any formats that are not in the answer, even if they were present in a previous SDP from the peer.
アンサー内の対応するメディアストリームはSection 6の手順で作成し、メディア形式も変更される場合があります。同節の説明どおり、アンサー側はアンサーを送信したらすぐに、オファーとアンサーの両方に含まれる形式を使ってメディアを送信し始めなければなりません (MUST)。送信可能なストリームであれば、オファーとアンサーの両方に含まれる形式のうち最も優先度の高いものを使うべきです (SHOULD)。以前のSDPに含まれていても、オファーにない形式を使って送信してはなりません (MUST NOT)。同様に、オファー側はアンサーを受信したらすぐに、アンサーに含まれる形式でメディアを送信し始めなければなりません (MUST)。送信可能なストリームであれば、最も優先度の高い形式を使うべきです (SHOULD)。以前のSDPに含まれていても、アンサーにない形式を使って送信してはなりません (MUST NOT)。
When an agent ceases using a media format (by not listing that format in an offer or answer, even though it was in a previous SDP) the agent will still need to be prepared to receive media with that format for a brief time. How does it know when it can be prepared to stop receiving with that format? If it needs to know, there are three techniques that can be applied. First, the agent can change ports in addition to changing formats. When media arrives on the new port, it knows that the peer has ceased sending with the old format, and it can cease being prepared to receive with it. This approach has the benefit of being media format independent. However, changes in ports may require changes in resource reservation or rekeying of security protocols. The second approach is to use a totally new set of dynamic payload types for all codecs when one is discarded. When media is received with one of the new payload types, the agent knows that the peer has ceased sending with the old format. This approach doesn't affect reservations or security contexts, but it is RTP specific and wasteful of a very small payload type space. A third approach is to use a timer. When the SDP from the peer is received, the timer is set. When it fires, the agent can cease being prepared to receive with the old format. A value of one minute would typically be more than sufficient. In some cases, an agent may not care, and thus continually be prepared to receive with the old formats. Nothing need be done in this case.
エージェントが以前のSDPに含まれていた形式をオファーやアンサーに列挙せず、その形式を使わなくなった場合でも、しばらくはその形式のメディアを受信できる状態を保つ必要があります。いつ受信待ちを終了できるかを知る必要がある場合、次の3つの方法があります。第一に、形式の変更と同時にポートを変更します。新ポートにメディアが届けば、相手が旧形式での送信を停止したと分かるため、旧形式で受信できる状態を解除できます。この方法はメディア形式に依存しません。ただし、ポートの変更により、リソース予約やセキュリティプロトコルの鍵更新が必要になることがあります。第二に、あるコーデックを廃止するとき、すべてのコーデックに対して動的ペイロードタイプ番号を新しいものにします。新しい番号のいずれかでメディアを受信すれば、相手が旧形式での送信を停止したと分かります。この方法は予約やセキュリティコンテキストに影響しませんが、RTPに限られ、もともと非常に少ないペイロードタイプ番号の空間を浪費します。第三に、タイマーを使います。相手からSDPを受信した時点でタイマーを設定し、満了したら旧形式で受信できる状態を解除します。通常は1分あれば十分です。旧形式を受信できる状態を保っても差し支えない場合は、そのままにして構いません。その場合、特別な処理は不要です。
Of course, if the offered stream is rejected, the offer can cease being prepared to receive using any new formats as soon as the rejection is received.
もちろん、提示したストリームが拒否された場合、拒否を受信した時点で、オファー側は新しい形式で受信できる状態を解除できます。
The media type (audio, video, etc.) for a stream MAY be changed. It is RECOMMENDED that the media type be changed (as opposed to adding a new stream), when the same logical data is being conveyed, but just in a different media format. This is particularly useful for changing between voiceband fax and fax in a single stream, which are both separate media types. To do this, the offerer creates a new media description, with a new media type, in place of the description in the previous SDP which is to be changed.
ストリームのメディア種類（audio、videoなど）を変更してもよいです (MAY)。同じ論理データを別のメディア形式で伝える場合、新しいストリームを追加するのではなく、メディア種類を変更することが推奨されます (SHOULD)。これは、どちらも別々のメディア種類である音声帯域FAXとFAXを1つのストリーム内で切り替える場合に特に有用です。その場合、オファー側は以前のSDPにある変更対象の記述を、新しいメディア種類を含むメディア記述に置き換えます。
The corresponding media stream in the answer is formulated as described in Section 6. Assuming the stream is acceptable, the answerer SHOULD begin sending with the new media type and formats as soon as it receives the offer. The offerer MUST be prepared to receive media with both the old and new types until the answer is received, and media with the new type is received and reaches the top of the playout buffer.
アンサー内の対応するメディアストリームはSection 6の手順で作成します。ストリームが受け入れ可能であれば、アンサー側はオファーを受信したらすぐに、新しいメディア種類と形式で送信を始めるべきです (SHOULD)。オファー側は、アンサーを受信し、新しい種類のメディアを受信して、それがプレイアウトバッファの先頭に達するまで、旧種類と新種類の両方のメディアを受信できる状態でなければなりません (MUST)。
Any other attributes in a media description MAY be updated in an offer or answer. Generally, an agent MUST send media (if the directionality of the stream allows) using the new parameters once the SDP with the change is received.
メディア記述内の他の属性もオファーまたはアンサーで更新してもよいです (MAY)。一般に、変更を含むSDPを受信したら、ストリームの方向が許す限り、新しいパラメーターを使ってメディアを送信しなければなりません (MUST)。
If a party in a call wants to put the other party "on hold", i.e., request that it temporarily stops sending one or more unicast media streams, a party offers the other an updated SDP.
通話の一方の当事者が相手側を「保留」にしたい場合、つまり1つ以上のユニキャストメディアストリームの送信を一時的に停止するよう要求する場合、その当事者は相手方に更新されたSDPを提供（オファー）します。
If the stream to be placed on hold was previously a sendrecv media stream, it is placed on hold by marking it as sendonly. If the stream to be placed on hold was previously a recvonly media stream, it is placed on hold by marking it inactive.
保留にするストリームが以前sendrecvだった場合、sendonlyに設定して保留にします。以前recvonlyだった場合は、inactiveに設定して保留にします。
This means that a stream is placed "on hold" separately in each direction. Each stream is placed "on hold" independently. The recipient of an offer for a stream on-hold SHOULD NOT automatically return an answer with the corresponding stream on hold. An SDP with all streams "on hold" is referred to as held SDP.
つまり、ストリームは各方向で個別に保留されます。各ストリームもそれぞれ独立して保留されます。保留中のストリームを含むオファーの受信側は、対応するストリームも保留にしたアンサーを自動的に返すべきではありません (SHOULD NOT)。すべてのストリームを保留にしたSDPを「保留SDP」と呼びます。
Certain third party call control scenarios do not work when an answerer responds to held SDP with held SDP.
特定のサードパーティのコールコントロールシナリオは、回答者が保持されたSDPを使用して保持されたSDPに応答する場合、機能しません。
Typically, when a user "presses" hold, the agent will generate an offer with all streams in the SDP indicating a direction of sendonly, and it will also locally mute, so that no media is sent to the far end, and no media is played out.
通常、ユーザーが「保留」を押すと、エージェントはSDP内のすべてのストリームをsendonlyにしたオファーを生成します。また、ローカルで音声をミュートし、相手側へのメディア送信と再生の両方を停止します。
RFC 2543 [10] specified that placing a user on hold was accomplished by setting the connection address to 0.0.0.0. Its usage for putting a call on hold is no longer recommended, since it doesn't allow for RTCP to be used with held streams, doesn't work with IPv6, and breaks with connection oriented media. However, it can be useful in an initial offer when the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and ports at the time of the offer. Of course, when used, the port number MUST NOT be zero, which would specify that the stream has been disabled. An agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer.
RFC 2543 [10]では、接続アドレスを0.0.0.0に設定してユーザーを保留にする方法を規定していました。この方法は、保留中のストリームでRTCPを使えず、IPv6で動作せず、コネクション型メディアでも問題が生じるため、通話の保留には現在推奨されません。ただし、オファー側が使用するメディアストリームと形式を決めている一方、オファー時点ではアドレスやポートが分からない場合、初期オファーでは有用です。この方法を使う場合、ポート番号を0にしてはなりません (MUST NOT)。0はストリームが無効であることを示すためです。エージェントは接続アドレスが0.0.0.0のSDPを受信できなければなりません (MUST)。この場合、RTPもRTCPも相手に送信しないことを意味します。
Before an agent sends an offer, it is helpful to know if the media formats in that offer would be acceptable to the answerer. Certain protocols, like SIP, provide a means to query for such capabilities. SDP can be used in responses to such queries to indicate capabilities. This section describes how such an SDP message is formatted. Since SDP has no way to indicate that the message is for the purpose of capability indication, this is determined from the context of the higher layer protocol. The ability of baseline SDP to indicate capabilities is very limited. It cannot express allowed parameter ranges or values, and can not be done in parallel with an offer/answer itself. Extensions might address such limitations in the future.
エージェントがオファーを送信する前に、そこに含めるメディア形式をアンサー側が受け入れられるか分かると便利です。SIPなどのプロトコルは、そのような能力を問い合わせる手段を提供します。SDPを問い合わせへの応答に使い、能力を示すことができます。本節では、そのようなSDPメッセージの形式を説明します。SDP自体には、メッセージが能力の提示を目的とすることを示す方法がないため、その判断は上位層プロトコルのコンテキストに依存します。基本SDPで示せる能力は限られています。許容されるパラメーターの範囲や値を表現できず、オファー/アンサー交換と並行して能力を示すこともできません。将来の拡張でこうした制約に対処できる可能性があります。
An SDP constructed to indicate media capabilities is structured as follows. It MUST be a valid SDP, except that it MAY omit both "e=" and "p=" lines. The "t=" line MUST be equal to "0 0". For each media type supported by the agent, there MUST be a corresponding media description of that type. The session ID in the origin field MUST be unique for each SDP constructed to indicate media capabilities. The port MUST be set to zero, but the connection address is arbitrary. The usage of port zero makes sure that an SDP formatted for capabilities does not cause media streams to be established if it is interpreted as an offer or answer.
メディア能力を示すSDPは、次の構成にします。有効なSDPでなければなりません (MUST)。ただし、「e=」行と「p=」行は両方とも省略してもよいです (MAY)。「t=」行は「0 0」でなければなりません (MUST)。エージェントがサポートするメディア種類ごとに、その種類のメディア記述を含めなければなりません (MUST)。originフィールドのセッションIDは、能力提示用に作成するSDPごとに一意でなければなりません (MUST)。ポート番号は0に設定しなければなりません (MUST)。接続アドレスは任意です。ポート番号を0にすることで、能力提示用SDPがオファーまたはアンサーとして解釈されても、メディアストリームが確立されないようにします。
The transport component of the "m=" line indicates the transport for that media type. For each media format of that type supported by the agent, there SHOULD be a media format listed in the "m=" line. In the case of RTP, if dynamic payload types are used, an rtpmap attribute MUST be present to bind the type to a specific format. There is no way to indicate constraints, such as how many simultaneous streams can be supported for a particular codec, and so on.
「m=」行のトランスポート要素は、そのメディア種類に使うトランスポートを示します。エージェントがサポートするその種類の各メディア形式を、「m=」行に列挙すべきです (SHOULD)。RTPで動的ペイロードタイプを使う場合、タイプを具体的な形式に対応付けるrtpmap属性を含めなければなりません (MUST)。特定のコーデックで同時にサポートできるストリーム数などの制約を示す方法はありません。
v=0
o=carol 28908764872 28908764872 IN IP4 100.3.6.6
s=-
t=0 0
c=IN IP4 192.0.2.4
m=audio 0 RTP/AVP 0 1 3
a=rtpmap:0 PCMU/8000
a=rtpmap:1 1016/8000
a=rtpmap:3 GSM/8000
m=video 0 RTP/AVP 31 34
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000
Figure 1: SDP Indicating Capabilities
図1: 能力を示すSDP
The SDP of Figure 1 indicates that the agent can support three audio codecs (PCMU, 1016, and GSM) and two video codecs (H.261 and H.263).
図1のSDPは、このエージェントが3つの音声コーデック（PCMU、1016、GSM）と2つの映像コーデック（H.261、H.263）をサポートできることを示します。
This section provides example offer/answer exchanges.
このセクションでは、オファー/回答の例を示しています。
Assume that the caller, Alice, has included the following description in her offer. It includes a bidirectional audio stream and two bidirectional video streams, using H.261 (payload type 31) and MPEG (payload type 32). The offered SDP is:
発信者のAliceが、次の記述をオファーに含めたとします。そこには双方向音声ストリームが1つと、H.261（ペイロードタイプ31）およびMPEG（ペイロードタイプ32）を使う双方向映像ストリームが2つ含まれています。オファーSDPは次のとおりです。
v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 51372 RTP/AVP 31 a=rtpmap:31 H261/90000 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000
The callee, Bob, does not want to receive or send the first video stream, so he returns the SDP below as the answer:
着信側のBobは最初の映像ストリームの送受信を希望しないため、次のSDPをアンサーとして返します。
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
At some point later, Bob decides to change the port where he will receive the audio stream (from 49920 to 65422), and at the same time, add an additional audio stream as receive only, using the RTP payload format for events [9]. Bob offers the following SDP in the offer:
しばらくしてBobは、音声ストリームの受信ポートを49920から65422に変更するとともに、イベント用RTPペイロード形式[9]を使う受信専用の音声ストリームを追加することにしました。Bobは次のSDPをオファーとして送信します。
v=0 o=bob 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 65422 RTP/AVP 0 a=rtpmap:0 PCMU/8000 m=video 0 RTP/AVP 31 m=video 53000 RTP/AVP 32 a=rtpmap:32 MPV/90000 m=audio 51434 RTP/AVP 110 a=rtpmap:110 telephone-events/8000 a=recvonly
Alice accepts the additional media stream, and so generates the following answer:
Aliceは追加のメディアストリームを受け入れ、次のアンサーを生成します。
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 53122 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=sendonly
A common occurrence in embedded phones is that the Digital Signal Processor (DSP) used for compression can support multiple codecs at a time, but once that codec is selected, it cannot be readily changed on the fly. This example shows how a session can be set up using an initial offer/answer exchange, followed immediately by a second one to lock down the set of codecs.
組み込み型電話機では、圧縮に使うデジタル信号プロセッサー（DSP）が複数のコーデックを同時にサポートできても、コーデックを一度選ぶと、その場で切り替えられない場合があります。この例では、最初のオファー/アンサー交換でセッションを設定し、その直後に2回目の交換を行って使用するコーデックを1つに確定する方法を示します。
The initial offer from Alice to Bob indicates a single audio stream with the three audio codecs that are available in the DSP. The stream is marked as inactive, since media cannot be received until a codec is locked down:
AliceからBobへの初期オファーには、DSPで利用できる3つの音声コーデックを含む音声ストリームが1つ示されています。コーデックを確定するまでメディアを受信できないため、このストリームはinactiveに設定されています。
v=0 o=alice 2890844526 2890844526 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 62986 RTP/AVP 0 4 18 a=rtpmap:0 PCMU/8000 a=rtpmap:4 G723/8000 a=rtpmap:18 G729/8000 a=inactive
Bob can support dynamic switching between PCMU and G.723. So, he sends the following answer:
BobはPCMUとG.723の間で動的に切り替えられるため、次のアンサーを送信します。
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=inactive
Alice can then select any one of these two codecs. So, she sends an updated offer with a sendrecv stream:
その後、Aliceはこの2つのコーデックから1つを選びます。そこで、sendrecvストリームを含む更新オファーを送信します。
v=0 o=alice 2890844526 2890844527 IN IP4 host.anywhere.com s= c=IN IP4 host.anywhere.com t=0 0 m=audio 62986 RTP/AVP 4 a=rtpmap:4 G723/8000 a=sendrecv
Bob accepts the single codec:
Bobはそのコーデックを受け入れます。
v=0 o=bob 2890844730 2890844732 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=audio 54344 RTP/AVP 4 a=rtpmap:4 G723/8000 a=sendrecv
If the answerer (Bob), was only capable of supporting one-of-N codecs, Bob would select one of the codecs from the offer, and place that in his answer. In this case, Alice would do a re-INVITE to activate that stream with that codec.
アンサー側（Bob）がN個の候補コーデックのうち1つしか同時にサポートできない場合、Bobはオファーに含まれるコーデックから1つを選び、アンサーに記載します。この場合、Aliceはそのコーデックを使ってストリームを有効にするre-INVITEを送信します。
As an alternative to using "a=inactive" in the first exchange, Alice can list all codecs, and as soon as she receives media from Bob, generate an updated offer locking down the codec to the one just received. Of course, if Bob only supports one-of-N codecs, there would only be one codec in his answer, and in this case, there is no need for a re-INVITE to lock down to a single codec.
最初の交換で「a=inactive」を使う代わりに、Aliceはすべてのコーデックを列挙しておき、Bobからメディアを受信したら、そのコーデックに使用形式を固定する更新オファーを生成することもできます。BobがN個の候補のうち1つしかサポートできない場合、アンサーに含まれるコーデックは1つだけなので、単一のコーデックに固定するre-INVITEは不要です。
There are numerous attacks possible if an attacker can modify offers or answers in transit. Generally, these include diversion of media streams (enabling eavesdropping), disabling of calls, and injection of unwanted media streams. If a passive listener can construct fake offers, and inject those into an exchange, similar attacks are possible. Even if an attacker can simply observe offers and answers, they can inject media streams into an existing conversation.
攻撃者が転送中のオファーまたはアンサーを変更できると、さまざまな攻撃が可能になります。たとえば、メディアストリームを迂回して盗聴したり、通話を妨害したり、望まれないメディアストリームを注入したりできます。受動的な盗聴者が偽のオファーを作成して交換に挿入できる場合も、同様の攻撃が可能です。攻撃者がオファーとアンサーを観察できるだけでも、既存の会話にメディアストリームを注入できます。
Offer/answer relies on transport within an application signaling protocol, such as SIP. It also relies on that protocol for security capabilities. Because of the attacks described above, that protocol MUST provide a means for end-to-end authentication and integrity protection of offers and answers. It SHOULD offer encryption of bodies to prevent eavesdropping. However, media injection attacks can alternatively be resolved through authenticated media exchange, and therefore the encryption requirement is a SHOULD instead of a MUST.
オファー/アンサーは、SIPなどのアプリケーションシグナリングプロトコルによる伝送に依存します。また、セキュリティ機能もそのプロトコルに依存します。前述の攻撃を防ぐため、そのプロトコルはオファーとアンサーのエンドツーエンド認証および完全性保護の手段を提供しなければなりません (MUST)。盗聴を防ぐため、本文の暗号化を提供すべきです (SHOULD)。ただし、メディア注入攻撃は認証済みメディア交換でも防止できるため、暗号化の要件はMUSTではなくSHOULDです。
Replay attacks are also problematic. An attacker can replay an old offer, perhaps one that had put media on hold, and thus disable media streams in a conversation. Therefore, the application protocol MUST provide a secure way to sequence offers and answers, and to detect and reject old offers or answers.
リプレイ攻撃も問題になります。攻撃者は、メディアを保留状態にした古いオファーなどを再送し、会話中のメディアストリームを停止させる可能性があります。そのため、アプリケーションプロトコルはオファーとアンサーを安全に順序付け、古いオファーやアンサーを検出して拒否する手段を提供しなければなりません (MUST)。
SIP [7] meets all of these requirements.
SIP [7]は、これらすべての要件を満たしています。
There are no IANA considerations with this specification.
この仕様にはIANAの考慮事項はありません。
The authors would like to thank Allison Mankin, Rohan Mahy, Joerg Ott, and Flemming Andreasen for their detailed comments.
著者らは、詳細なコメントを寄せてくださった Allison Mankin、Rohan Mahy、Joerg Ott、Flemming Andreasen に感謝します。
[1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Kumar, R. and M. Mostafa, "Conventions For the Use of The Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, May 2001.
[3] Kumar, R. and M. Mostafa, "Conventions For the Use of The Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, May 2001.
[4] Schulzrinne, H., Casner, S, Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[4] Schulzrinne, H., Casner, S, Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[5] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
[5] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
[6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[7] 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.
[7] 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.
[8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[10] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[10] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 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.
上記の条件に従う限り、本書およびその翻訳を複製して他者に提供できます。また、本書について論評・説明する派生物や、本書の実装を支援する派生物を、全部または一部について制限なく作成、複製、公開、配布できます。ただし、すべての複製物および派生物に、上記の著作権表示と本段落を含めなければなりません。本書自体は、著作権表示やInternet Societyその他のインターネット組織への言及を削除するなど、いかなる方法でも変更できません。ただし、インターネット標準を策定するために必要な場合はInternet Standards Processで定める著作権手続きに従うものとし、英語以外の言語へ翻訳するために必要な変更は認められます。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限定的な許諾は永続的であり、Internet Society、その後継者または譲受人によって取り消されません。
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.
本書およびここに含まれる情報は「現状有姿」で提供されます。INTERNET SOCIETYおよびINTERNET ENGINEERING TASK FORCEは、明示または黙示を問わず一切の保証を否認します。これには、本情報の使用が権利を侵害しないこと、商品性、または特定目的への適合性に関する黙示の保証が含まれますが、これらに限定されません。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。