[要約] RFC 3264は、SDPを使用したOffer/Answerモデルに関する規格であり、セッションの開始と終了を説明するためのプロトコルです。このRFCの目的は、セッションの確立と制御を効果的に行うための標準化を提供することです。
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
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）を利用して、それらの間のマルチメディアセッションの共通のビューに到達できるメカニズムを定義します。モデルでは、1人の参加者が他の参加者に目的のセッションの説明を彼らの観点から提供し、もう1人の参加者は彼らの観点から望ましいセッションに答えます。このオファー/回答モデルは、セッションの完全なビューに両方の参加者からの情報が必要なユニキャストセッションで最も役立ちます。オファー/回答モデルは、セッション開始プロトコル（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
1 Introduction
1はじめに
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.
例として、マルチキャストセッションでは、特定のメディアストリームに対して単一のマルチキャストアドレスを伝える必要があります。ただし、ユニキャストセッションの場合、2つのアドレスが必要です。1つは参加者ごとに1つです。別の例として、マルチキャストセッションでは、セッションでどのコーデックが使用されるかを示す必要があります。ただし、ユニキャストの場合、各参加者がサポートするセットでオーバーラップを見つけることにより、コーデックのセットを決定する必要があります。
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に基づいて簡単なオファー/回答モデルを定義することにより、それを改善します。このモデルでは、セッションの1人の参加者が、オファーを構成するSDPメッセージを生成します。オファーが使用を希望するメディアストリームとコーデック、およびオファーがメディアを受け取るために使用したいIPアドレスとポートとともに。オファーは、andawnerと呼ばれる他の参加者に伝えられます。Answererは回答を生成します。これは、提供者が提供するオファーに応答する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.
また、マルチキャストセッションがユニキャストのセッションと同様に機能する可能性もあります。そのパラメーターは、ユニキャストの場合と同様に、一対のユーザー間で交渉されますが、双方はユニキャストのアドレスではなく、同じマルチキャストアドレスにパケットを送信します。このドキュメントでは、マルチキャストストリームへのオファー/回答モデルの適用についても説明します。
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]で使用される必須ベースラインメカニズムです。
2 Terminology
2用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant implementations.
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"RFC 2119 [2]で説明されているように解釈され、準拠した実装の要件レベルを示します。
3 Definitions
3つの定義
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.
エージェント：エージェントは、オファー/回答の交換に関与するプロトコルの実装です。オファー/回答の交換には2つのエージェントが関与しています。
Answer: An SDP message sent by an answerer in response to an offer received from an offerer.
回答：提供者から受け取った申し出に応じて、応答者から送信された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.
回答者：希望するメディアコミュニケーションの側面を説明する別のエージェントからセッションの説明を受信し、独自のセッションの説明で応答するエージェント。
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.
メディアストリーム：RTSP [8]から、メディアストリームは単一のメディアインスタンスです。たとえば、オーディオストリームやビデオストリーム、単一のホワイトボードまたは共有アプリケーショングループです。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：セッションを作成または変更するためにセッションの説明を生成するエージェント。
4 Protocol Operation
4プロトコル操作
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).
オファーを受け取ったエージェントは、回答を生成するか、申し出を拒否する場合があります。オファーを拒否する手段は、高層プロトコルに依存します。申し出/回答交換は原子です。答えが拒否された場合、セッションはオファーの前に州に戻ります（セッションがない可能性があります）。
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.
いつでも、いずれかのエージェントがセッションを更新する新しいオファーを生成する場合があります。ただし、まだ回答しておらず、拒否されていないオファーを受け取った場合、新しいオファーを生成してはなりません。さらに、まだ回答や拒否を受け取っていない以前のオファーを生成した場合、新しいオファーを生成してはなりません。エージェントが送信した後にオファーを受け取ったが、それに対する回答を受ける前に、これは「まぶしさ」状態と見なされます。
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.
グレアという用語は、もともと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]。
5 Generating the Initial Offer
5初期オファーを生成します
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メッセージでなければなりません。RFC 2327は、eまたはp行のいずれかがSDPメッセージに存在することを義務付けています。この仕様はその制約を緩和します。オファー/回答アプリケーション用に処方されたSDPは、EラインとPラインの両方を省略する場合があります。O LineのセッションIDとバージョンの数値は、64ビット署名された整数で表現できる必要があります。ロールオーバーを避けるために、バージョンの初期値は（2 ** 62）-1未満でなければなりません。SDP仕様により、複数のセッションの説明を一緒に大きなSDPメッセージに連結することができますが、オファー/回答モデルで使用されるSDPメッセージには、正確に1つのセッションの説明を含める必要があります。
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）またはダッシュ（ - ）で構成することをお勧めします。
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」の値を持つ必要があります。
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).
オファーにはゼロ以上のメディアストリームが含まれます（各メディアストリームには、「m =」行と関連する属性によって説明されます）。Zero Media Streamsは、提供者が通信を望んでいることを意味しますが、セッションのストリームは、変更されたオファーを通じて後で追加されることを意味します。ストリームは、ユニキャストとマルチキャストの組み合わせ用である場合があります。後者は明らかに、関連する「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」属性でストリームをセンドリーとしてマークする必要があります。メディアストリーム属性またはセッション属性のいずれかとして方向属性が存在する場合、ストリームは特定の方向でマークされていると呼びます。オファーがピアからメディアのみを受け取ることを希望する場合、ストリームをRecvonlyとしてマークする必要があります。オファーがコミュニケーションを希望し、現時点でメディアを送信したり受け取ったりしない場合は、「a = a = hisactive」属性でストリームをマークする必要があります。非アクティブ方向属性は、RFC 3108 [3]で指定されています。リアルタイムトランスポートプロトコル（RTP）[4]の場合、RTCPはまだ送信され、Sendonly、Recvonly、および非アクティブなストリームのために受信されていることに注意してください。つまり、メディアストリームの方向性は、RTCPの使用に影響を与えません。Offererがピアでメディアを送信して受信することを望む場合、sendrecvがデフォルトであるため、「a = 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レポートを受信したい場所を間接的に示します。明示的な兆候がない場合を除き、レポートは、示されている数よりも高いポートナンバーワンに送信されます。オファーに存在するIPアドレスとポートは、RTPのソースIPアドレスとソースポートと、提供者によって送信されるRTCPパケットについて何も示していません。オファーのポート番号ゼロは、ストリームが提供されているが使用してはならないことを示しています。これには、最初のオファーには有用なセマンティクスがありませんが、回答には拒否されたストリームを示すゼロポートが含まれる可能性があるため、完全性の理由で許可されています（セクション6）。さらに、既存のストリームは、ポートをゼロに設定することで終了できます（セクション8）。一般に、ゼロのポート数は、メディアストリームが必要でないことを示します。
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つの情報、つまり、提供者が送信および/または受信できる（RTPの場合、コーデックとコーデックに関連するパラメーター）のセット（コーデックとコーデックに関連するパラメーター）を伝えています。方向属性）、およびRTPの場合、それらの形式を識別するために使用されるRTPペイロードタイプ番号。複数の形式がリストされている場合、オファーはセッション中にこれらの形式のいずれかを利用できることを意味します。言い換えれば、応答者はセッションの途中でフォーマットを変更し、新しいオファーを送信することなく、リストされている形式のいずれかを利用する場合があります。Sendonlyストリームの場合、オファーはこれらのフォーマットを、オファーがこのストリームに喜んで送信することを示している必要があります。Recvonlyストリームの場合、オファーは、このストリームに対して受け取る意思のある形式を示す必要があります。SendRecvストリームの場合、オファーは、提供者が喜んで送信して受け取ることを望んでいるコーデックを示す必要があります。
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ストリームの場合、ペイロードタイプの数値は、RTPパケットのペイロードタイプフィールドの値を示しています。SendRecv RTPストリームの場合、ペイロードタイプの数値は、提供者が受信すると予想されるペイロードタイプフィールドの値を示し、送信を好みます。ただし、SendonlyおよびSendRecvストリームの場合、答えは同じコーデックの異なるペイロードタイプ番号を示している可能性があります。その場合、オファーは回答からペイロードタイプ番号を送信する必要があります。
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パラメーターが存在する場合があります。
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」マッピングを含める必要があります。「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 =」行の形式を優先順にリストする必要があり、最初の形式が推奨されます。この場合、優先されることは、オファーの受信者が、それを受け入れられる最高の選好でフォーマットを使用する必要があることを意味します。
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属性はゼロより大きくなければなりません。
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.
帯域幅の属性がストリームに存在する場合、それはオファーが受け取りたい望ましい帯域幅を示します。ゼロの値は許可されていますが、落胆します。メディアを送信しないでください。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).
同じタイプの複数のメディアストリームがオファーに存在する場合、それは、提供者がそのタイプの複数のストリームを同時に送信（および/または受信する）ことを望んでいることを意味します。同じタイプの複数のストリームを送信する場合、そのタイプの各メディアソース（たとえば、ビデオの場合のビデオカメラとVCR）が各ストリームにマッピングされる方法に関するローカルポリシーの問題です。ユーザーが特定のメディアタイプの単一のソースを持っている場合、1つのポリシーのみが理にかなっています。ソースは同じタイプの各ストリームに送信されます。各ストリームは、異なるエンコーディングを使用する場合があります。同じタイプの複数のストリームを受信する場合、各ストリームがその特定のタイプのさまざまなメディアシンクにどのようにマッピングされるかについてのローカルポリシーの問題です（たとえば、オーディオの場合のスピーカーや録音デバイス）。ただし、ポリシーにはいくつかの制約があります。まず、同じタイプの複数のストリームを受信する場合、各ストリームは、ユーザーへのプレゼンテーションを目的として、少なくとも1つのシンクにマッピングする必要があります。言い換えれば、同じタイプの複数のストリームを受信する意図は、それらがすべて1つだけを選択するのではなく、並行して提示する必要があるということです。別の制約は、複数のストリームを受信して同じシンクに送信すると、メディア固有の方法で結合する必要があるということです。たとえば、2つのオーディオストリームの場合、それぞれから受信されたメディアがスピーカーにマッピングされる場合があります。その場合、結合操作はそれらを混合することです。シンクが画面である複数のインスタントメッセージングストリームの場合、結合操作はそれらすべてをユーザーインターフェイスに提示することです。3番目の制約は、複数のソースが同じストリームにマッピングされている場合、それらのソースをストリームに送信する前に、ある程度のメディア固有の方法で結合する必要があることです。これらの制約を超えたポリシーは柔軟ですが、エージェントは一般に、会議サーバーでない限り、メディアをシンクからソースにコピーするポリシーを望まない（つまり、あるストリームで受信したメディアを別のストリームにコピーしないでください）。
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.
同じタイプの複数のメディアストリームの典型的な使用例は、プリペイドのコーリングカードアプリケーションです。ここで、ユーザーはハングアップへの呼び出し中にいつでもポンド（ "＃"）キーを押して、新しい電話をかけることができます。同じカード。これには、ユーザーから2つの宛先（リモートゲートウェイ）とポンドを探すDTMF処理アプリケーションへのメディアが必要です。これは、2つのメディアストリーム、1つはゲートウェイに送信され、もう1つは（ユーザーの観点から）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ストリームのメディアを受け取る準備をする必要があります。オファーのSendRecvストリームのメディアを送信および受信し、オファーのSendonlyストリームのメディアを送信する準備をする必要があります（もちろん、ピアが必要なアドレスとポート情報で回答を提供するまで実際に送信することはできません）。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]で説明されているとおりです。
6 Generating the Answer
6答えを生成します
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アドレス、ポートなど）、答えは異なるエンティティによって生成されるため、回答では起源の行が異なる必要があります。その場合、回答の「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 =」行が必要です。答えには、オファーとまったく同じ数の「m =」行が含まれている必要があります。これにより、注文に基づいてストリームを一致させることができます。これは、オファーにゼロ "m ="行が含まれている場合、答えにゼロ "m ="行が含まれている必要があることを意味します。
The "t=" line in the answer MUST equal that of the offer. The time of the session cannot be negotiated.
答えの「t =」行は、オファーの「t =」という線に等しくなければなりません。セッションの時間を交渉することはできません。
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.
何らかの理由で、提供されたストリームが答えで拒否される場合があります。ストリームが拒否された場合、提供者と回答者は、そのストリームのメディア（またはRTCPパケット）を生成してはなりません。提供されたストリームを拒否するには、回答の対応するストリームのポート番号をゼロに設定する必要があります。リストされているメディア形式は無視されます。SDPで指定されているように、少なくとも1つは存在する必要があります。
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.
ユニキャストアドレスでストリームが提供されている場合、そのストリームに対する答えにはユニキャストアドレスが含まれている必要があります。答えのストリームのメディアタイプは、オファーのメディアタイプと一致する必要があります。
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または非アクティブとしてマークされなければなりません。メディアストリームがオファーにecvonlyとしてリストされている場合、答えは、回答のSendonlyまたは非アクティブとしてマークされなければなりません。提供されたメディアストリームがsendrecvとしてリストされている場合（または、メディアまたはセッションレベルに方向属性がない場合、その場合、ストリームはデフォルトでsendrecvです）、回答の対応するストリームは、sendonly、recvonly、sendrecvとしてマークされる場合があります、または非アクティブ。提供されたメディアストリームが非アクティブとしてリストされている場合、答えは非アクティブとしてマークする必要があります。
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つのメディア形式が含まれている必要があります。ストリームは、応募者が受け取る意思があるオファーの対応するストリームにリストされていない追加のメディア形式を示している場合があります。回答でSendonlyとしてマークされたストリームの場合、「M =」行には、応募者がオファーにリストされているものの中から送信することをいとわない少なくとも1つのメディア形式を含める必要があります。回答でsendrecvとしてマークされたストリームの場合、「m =」行には、応答に記載されているものの中で、応答者が送信して受け取ることをいとわないコードを少なくとも1つ含める必要があります。ストリームは、応答の対応するストリームにリストされていない追加のメディア形式を示している場合があります。これは、回答者が送信または受信することをいとわないことです（もちろん、現時点では送信できません。オファー）。回答では非アクティブであるとマークされたストリームの場合、メディア形式のリストはオファーに基づいて構築されます。オファーがセンドリーである場合、リストは回答がcovonlyであるかのように構築されます。同様に、オファーが繰り返される場合、リストは回答がsendonlyであるかのように構築され、オファーがsendrecvである場合、リストは回答がsendrecvであるかのように構築されます。オファーが非アクティブである場合、リストは実際にsendrecvであり、答えが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ストリームでも存在する必要があります。RTPの場合、RTCPの受信にはまだポート1つが使用されています。
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の場合、特定のコーデックがオファーに特定のペイロードタイプ番号で参照された場合、そのコードにはそのコードに使用される必要があります。同じペイロードタイプ番号が使用されている場合でも、回答には、動的ペイロードタイプのペイロードタイプマッピングを定義するためにRTPMAP属性を含める必要があり、静的ペイロードタイプのマッピングを含める必要があります。「m =」行のメディア形式は、優先度の高い順にリストする必要があり、最初の形式が優先されます。この場合、優先されることは、オファーが回答から最高の優先度を持つ形式を使用する必要があることを意味します。
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.
Answererは、希望する好みの順序でフォーマットをリストする場合がありますが、特定の理由がない限り、応答に存在する同じ相対順序のAsherserリスト形式は推奨されます。言い換えれば、オファー内のストリームがオーディオコーデック8、22、48をその順序でリストし、回答者がコーデック8と48のみをサポートする場合、応答者に変更する理由がない場合は、順序付けをお勧めします回答のコーデックの8、48、48、8ではなく8、48、これにより、同じコーデックが両方向に使用されることを保証するのに役立ちます。
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パラメーターが答えに存在する必要があることを意味します。他のFMTPパラメーターはパラメーターに似ており、各エージェントが異なる値を使用することは完全に受け入れられます。その場合、答えにはFMTPパラメーターが含まれている場合があり、それらはオファーの値と同じ値を持っているか、異なる場合があります。新しいパラメーターを定義するSDP拡張機能は、提供/回答の適切な解釈を指定する必要があります。
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.
応答者には、メディアストリームのゼロ以外のPTIME属性が含まれる場合があります。これは、回答者が受け取りたいパケット化間隔を示します。特定のストリームのパケット化間隔が各方向で同じであるという要件はありません。
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.
応答者には、メディアストリームの帯域幅属性が含まれる場合があります。これは、応答者がメディアを送信するときに提供者に使用することを望んでいる帯域幅を示しています。セクション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.
応答者に特定の提供されたストリームについて共通のメディア形式がない場合、回答者はポートをゼロに設定することにより、そのメディアストリームを拒否する必要があります。
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ストリームのメディアを受信する準備をする必要があります。回答のSendRecvストリームのためにメディアを送信および受信する準備をする必要があり、すぐにメディアを送信する場合があります。回答者は、Recvonly用のメディアを受信するか、回答のこれらのストリームにリストされているメディア形式を使用してRecvストリームを送信する準備をする必要があり、すぐにメディアを送信する場合があります。メディアを送信するときは、存在する場合は、オファーのPTIME属性の値に等しいパケット化間隔を使用する必要があります。帯域幅を使用してメディアを送信する必要があります。回答者は、回答にもリストされているオファーにメディア形式を使用して送信する必要があり、回答にもリストされているオファーで最も優先されるメディア形式を使用して送信する必要があります。RTPの場合、回答のものとは異なる場合でも、オファーのペイロードタイプ番号を使用する必要があります。
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.
ストリームの両面ビューがあるユニキャストとは異なり、マルチキャスト用のストリームには単一のビューしかありません。そのため、マルチキャストオファーに対する回答を生成するには、一般に、ストリームの限られた一連の側面を変更することが含まれます。
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.
マルチキャストストリームが受け入れられた場合、回答のアドレスとポート情報は、オファーのアドレスとポート情報と一致する必要があります。同様に、回答の方向性情報（Sendonly、Recvonly、またはSendRecv）は、オファーの方向性に等しくなければなりません。これは、マルチキャストセッションのすべての参加者が、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.
回答のメディア形式のセットは、オファーのサブセットに等しいか、またはサブセットでなければなりません。フォーマットを削除することは、回答者がフォーマットがサポートされていないことを示す方法です。
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属性と帯域幅の属性は、存在する場合は、オファーのものと等しくなければなりません。存在しない場合は、ゼロ以外のPTIMEを回答に追加できます。
7 Offerer Processing of the Answer
7回答の提供者処理
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としてリストされていると仮定します）。回答にリストされているメディア形式を使用して送信する必要があり、回答が送信されたときにリストされている最初のメディア形式を使用する必要があります。
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.
これが必要ではなく、必須ではない理由（回答者にとっても必須ではなく、必須ではありません）は、しばしばその場でコーデックを変更する必要があるからです。たとえば、沈黙期間中、エージェントはコンフォートノイズコーデックに切り替えたいと思うかもしれません。または、ユーザーがキーパッドで数値を押した場合、エージェントはRFC 2833を使用してそれを送信したい場合があります[9]。輻輳制御は、フィードバックに基づいてより低いレートコーデックに変更する必要がある場合があります。
The offerer SHOULD send media according to the value of any ptime and bandwidth attribute in the answer.
オファーは、回答のPTIMEおよび帯域幅の属性の値に従ってメディアを送信する必要があります。
The offerer MAY immediately cease listening for media formats that were listed in the initial offer, but not present in the answer.
オファーは、最初のオファーにリストされていたが、答えには存在しないメディア形式のリスニングをすぐにやめることができます。
8 Modifying the Session
8セッションの変更
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.
セッション中の任意の時点で、どちらの参加者もセッションの特性を変更するための新しいオファーを発行することができます。上記で定義されたまったく同じオファー/回答手順が既存のセッションのパラメーターを変更するために使用されることは、オファー/回答モデルの操作の基本です。
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（オファーや回答で提供されている可能性があります）と同一である場合があります。提供された最後のSDPを「以前のSDP」と呼びます。オファーが同じ場合、答えは回答者の以前のSDPと同じであるか、異なる場合があります。提供された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の「O =」行と同一でなければなりませんが、Originフィールドのバージョンは以前のSDPから1つずつ増加する必要があります。Origin Lineのバージョンが増加しない場合、SDPはそのバージョン番号でSDPと同一でなければなりません。回答者は、変更されていないバージョンを含むSDPを含むオファーを受け取る準備をする必要があります。これは事実上、No-opです。ただし、セクション6で定義されている手順に従って、回答者は有効な回答を生成する必要があります（これは、回答者からの以前のSDPと同じ、または異なる場合があります）。
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の各メディアストリームにマッチングメディアストリームが必要です。言い換えれば、以前のSDPにn "m ="ラインがある場合、新しいSDPには少なくともn "m ="ラインが必要です。上からカウントされる前のSDPのIthメディアストリームは、新しいSDPのIthメディアストリームと一致し、上からカウントされます。このマッチングは、応答者が新しいSDPのどのストリームが以前のSDPのストリームに対応するかを決定するために必要です。これらの要件のため、ストリーム内の「m =」行の数は減少することはありませんが、同じままであるか、増加します。以前のSDPから削除されたメディアストリームを新しいSDPで削除してはなりません。ただし、これらのストリームの属性は存在する必要はありません。
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.
新しいメディアストリームは、既存のものの下の新しい追加メディアの説明によって作成され、ポートをゼロに設定することで無効になっていた古いメディアストリームで使用される「スロット」を再利用することによって作成されます。
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の他のメディアの説明と比較して位置を保持することを意味します。新しいメディアの説明は、既存のメディアセクションの下に表示する必要があります。これらのメディアの説明をフォーマットするためのルールは、セクション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を受信したり、ポートが以前にゼロだったスロットにメディアストリームを備えたSDPを受け取ったりすると、応答者は新しいメディアストリームが追加されていることを知っています。これらは、答えに適切に構造化されたメディアの説明を配置することにより、拒否または受け入れることができます。回答で新しいメディアの説明を構築する手順は、セクション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.
既存のメディアストリームは、そのストリームがゼロに設定されたポート番号を備えた新しいSDPを作成することにより削除されます。ストリームの説明には、以前に存在するすべての属性を省略する場合があり、単一のメディア形式のみをリストする場合があります。
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.
ゼロのポートで提供されるストリームは、答えにポートゼロをマークする必要があります。オファーと同様に、答えは以前に存在するすべての属性を省略する可能性があり、オファーのメディア形式から単一のメディア形式をリストする場合があります。
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.
ストリームのポート番号が変更される場合があります。これを行うために、オファーは新しいメディアの説明を作成します。M行のポート番号は、以前のSDPの対応するストリームとは異なります。ポート番号のみが変更される場合、メディアストリームの残りの説明は変更されていません。オファーは、オファーが送信されるとすぐに、古いポートと新しいポートの両方でメディアを受信する準備をする必要があります。オファーは、回答が受信され、メディアが新しいポートに到着するまで、古いポートでメディアのリスニングをやめるべきではありません。そうすることで、移行中にメディアが失われる可能性があります。
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.
この場合、受信したことは、メディアがメディアシンクに渡されることを意味します。これは、プレイアウトバッファーがある場合、新しいポートのメディアがプレイアウトバッファの上部に到達するまで、エージェントは古いポートで聞き続けることを意味します。当時、古い港でメディアを聞くのをやめるかもしれません。
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のストリームと同じであるか、異なる場合があります。更新されたストリームが応答者によって受け入れられている場合、Answererはそのストリームのトラフィックの送信をすぐに新しいポートに送信し始める必要があります。回答者が以前のSDPからポートを変更した場合、回答が送信されるとすぐに、古いポートと新しいポートの両方でメディアを受信する準備をする必要があります。応答者は、メディアが新しいポートに到着するまで、古いポートでメディアを聞くのをやめてはなりません。当時、古い港でメディアを聞くのをやめるかもしれません。同じことが、新しいポートで更新されたオファーを送信する提供者にも当てはまります。メディアが新しいポートに到着するまで、古い港でメディアを聞くのをやめてはなりません。
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.
ストリームの輸送は変更される場合があります。これを行うプロセスは、ポートではなく輸送が更新されることを除いて、ポートを変更するのと同じです。
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.
セッションで使用されるメディア形式のリストは変更される場合があります。これを行うために、オファーは新しいメディアの説明を作成し、以前のSDPの対応するメディアストリームとは異なる「m =」行のメディア形式のリストを作成します。このリストには新しい形式が含まれている場合があり、以前のSDPから存在する形式を削除する場合があります。ただし、RTPの場合、特定の動的なペイロードタイプ番号からそのメディアストリーム内の特定のコーデックへのマッピングは、セッション中に変更されてはなりません。たとえば、Aが動的なペイロードタイプ番号46に割り当てられたG.711でオファーを生成する場合、ペイロードタイプ番号46は、セッション内のそのメディアストリームのオファーまたは回答でその時点からG.711を参照する必要があります。ただし、複数のペイロードタイプ番号を同じコーデックにマッピングすることは許容されるため、更新されたオファーは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.
回答の対応するメディアストリームは、セクション6で説明されているように策定されており、メディア形式の変更も発生する可能性があります。同様に、セクション6で説明されているように、回答を送信するとすぐに、回答者は、回答にも存在するオファーのフォーマットを使用してメディアの送信を開始する必要があります。回答（ストリームが送信を許可すると仮定）で、ピアからの以前のSDPに存在していたとしても、オファーにないフォーマットを使用して送信してはなりません。同様に、オファーが回答を受け取った場合、回答の任意の形式を使用してメディアの送信を開始する必要があり、最も優先されるものを使用する必要があります（ストリームを送信できると仮定します）。、たとえそれらがピアからの以前のSDPに存在していても。
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つの手法があります。まず、エージェントはフォーマットの変更に加えてポートを変更できます。メディアが新しいポートに到着すると、ピアが古い形式で送信をやめたことがわかっており、それを受け取る準備をやめることができます。このアプローチには、メディア形式が独立しているという利点があります。ただし、ポートの変更には、リソースの予約やセキュリティプロトコルの再キーイングの変更が必要になる場合があります。2番目のアプローチは、すべてのコーデックに廃棄されたときに、まったく新しい動的ペイロードタイプを使用することです。メディアが新しいペイロードタイプの1つで受信されると、エージェントはピアが古い形式で送信をやめたことを知っています。このアプローチは予約やセキュリティのコンテキストには影響しませんが、RTP固有であり、非常に小さなペイロードタイプのスペースを無駄にします。3番目のアプローチは、タイマーを使用することです。ピアからの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.
ストリームのメディアタイプ（オーディオ、ビデオなど）が変更される場合があります。同じ論理データが伝達されているが、別のメディア形式では、メディアタイプを変更することをお勧めします（新しいストリームを追加するのではなく）。これは、両方とも別々のメディアタイプである単一のストリームでVoiceBand FaxとFaxを変更するのに特に役立ちます。これを行うために、オファーは、変更される前の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.
回答の対応するメディアストリームは、セクション6で説明されているように策定されています。ストリームが許容できると仮定すると、応募者はオファーを受け取ったらすぐに新しいメディアタイプとフォーマットを送信し始める必要があります。提供者は、回答が受信されるまで古いタイプと新しいタイプの両方でメディアを受信する準備をしなければならず、新しいタイプのメディアが受信され、プレイアウトバッファの上部に到達する必要があります。
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.
メディアの説明内の他の属性は、オファーまたは回答で更新される場合があります。一般に、エージェントは、変更を受けたSDPが受信されたら、新しいパラメーターを使用して、メディア（ストリームの方向性が許可されている場合）を送信する必要があります。
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としてマークすることにより保留に配置されます。保留にするストリームが以前に登録されたメディアストリームであった場合、それは非アクティブにマークすることによって保留されます。
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.
これは、ストリームが各方向に個別に「保留」されることを意味します。各ストリームは「保留中」に配置されます。オンホールドのストリームのオファーの受信者は、対応するストリームを保留にして回答を自動的に返すべきではありません。すべてのストリームを「保留中」の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.
通常、ユーザーがHoldを「押す」と、エージェントは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.0.0.0の接続アドレスでSDPを受信できる必要があります。その場合、RTPもRTCPもピアに送信する必要はありません。
9 Indicating Capabilities
9能力を示す
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は、次のように構成されています。「e =」と「p =」の両方の行を省略することを除いて、有効なSDPでなければなりません。「t =」行は「0 0」に等しくなければなりません。エージェントがサポートする各メディアタイプについて、そのタイプの対応するメディアの説明が必要です。OriginフィールドのセッションIDは、メディア機能を示すために構築された各SDPに対して一意でなければなりません。ポートはゼロに設定する必要がありますが、接続アドレスは任意です。ポートゼロの使用により、機能用の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 =」行にリストされているメディア形式が必要です。RTPの場合、動的なペイロードタイプを使用する場合、型を特定の形式に結合するためにRTPMAP属性を存在する必要があります。特定のコーデックでサポートできる同時のストリームの数など、制約を示す方法はありません。
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）をサポートできることを示しています。
10 Example Offer/Answer Exchanges
10の例オファー/回答交換
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:
発信者のアリスが彼女の申し出に次の説明を含めたと仮定します。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:
V = 0 O = Alice 2890844526 2890844526 in ip4 host.any.com s = c = in ip4 host.any.com t = 0 0 m = audio 49170 rtp/avp 0 a = rtpmap：0 pcmu/8000 m =ビデオ51372RTP/AVP 31 A = RTPMAP：31 H261/90000 M = Video 53000 RTP/AVP 32 A = RTPMAP：32 MPV/90000ボブのカリーは、最初のビデオストリームを受信または送信したくないので、彼は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:
後である時点で、ボブはオーディオストリームを受け取るポート（49920から65422まで）を変更することを決定し、同時に、イベントのRTPペイロード形式を使用して、受信のみをオーディオストリームを追加することを決定しました[9]。ボブはオファーで次の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:
V = 0 O = BOB 2890844730 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 =ビデオ0RTP/AVP 31 M =ビデオ53000 RTP/AVP 32 A = RTPMAP：32 MPV/90000 M = Audio 51434 RTP/AVP 110 A = RTPMAP：110 Telephone-Events/8000 A = Recvonly 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番目のオファー交換を行い、コーデックのセットをロックダウンします。
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:
アリスからボブまでの最初のオファーは、DSPで利用可能な3つのオーディオコーデックを備えた単一のオーディオストリームを示しています。コーデックがロックダウンされるまでメディアを受信できないため、ストリームは非アクティブとしてマークされています。
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:
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 =非アクティブボブは、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:
アリスは、これら2つのコーデックのいずれかを選択できます。そこで、彼女は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
V = 0 O = Alice 2890844526 2890844527 in ip4 host.anywhere.com s = c = in ip4 host.any.com t = 0 0 m = audio 62986 rtp/avp 4 a = rtpmap：4 g723/8000 a = sendrecvvvv
Bob accepts the single codec:
ボブは単一のコーデックを受け入れます：
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
V = 0 O = BOB 2890844730 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 = sendrecvvvvv
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.
Answerer（Bob）がn-of-n-of-nコーデックのみをサポートできる場合、ボブはオファーからコーデックの1つを選択し、それを彼の答えに置きます。この場合、アリスはそのコーデックでそのストリームをアクティブにするために再入力を行います。
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」を使用する代わりに、アリスはすべてのコーデックをリストすることができ、ボブからメディアを受け取るとすぐに、コードを受け取ったコーデックにロックして更新されたオファーを生成します。もちろん、Bobがn-of-Nコーデックのみをサポートしている場合、彼の答えにはコーデックが1つしかありません。この場合、単一のコーデックにロックダウンする必要はありません。
11 Security Considerations
11セキュリティ上の考慮事項
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などのアプリケーションシグナリングプロトコル内の輸送に依存しています。また、セキュリティ機能のプロトコルにも依存しています。上記の攻撃のため、そのプロトコルは、オファーと回答のエンドツーエンド認証と整合性の保護の手段を提供する必要があります。盗聴を防ぐために、身体の暗号化を提供する必要があります。ただし、メディアインジェクション攻撃は、認証されたメディア交換によって別の方法で解決できます。したがって、暗号化の要件は必須ではなくそうです。
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.
リプレイ攻撃にも問題があります。攻撃者は、おそらくメディアを保留していた古いオファーを再生することができ、したがって会話でメディアのストリームを無効にすることができます。したがって、アプリケーションプロトコルは、オファーと回答をシーケンスし、古いオファーや回答を検出および拒否する安全な方法を提供する必要があります。
SIP [7] meets all of these requirements.
SIP [7]は、これらすべての要件を満たしています。
12 IANA Considerations
12 IANAの考慮事項
There are no IANA considerations with this specification.
この仕様にはIANAの考慮事項はありません。
13 Acknowledgements
13謝辞
The authors would like to thank Allison Mankin, Rohan Mahy, Joerg Ott, and Flemming Andreasen for their detailed comments.
著者は、詳細なコメントをしてくれたアリソン・マンキン、ロハン・マヒー、ジョーグ・オット、フレミング・アンドレアセンに感謝したいと思います。
14 Normative References
14規範的な参照
[1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[1] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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。およびM. Mostafa、「ATMベアラー接続のためのセッション説明プロトコル（SDP）の使用に関する規則」、RFC 3108、2001年5月。
[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。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、RFC 1889、1996年1月。
[5] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
[5] Schulzrinne、H。、「最小限のコントロールを備えたオーディオおよびビデオ会議のRTPプロファイル」、RFC 1890、1996年1月。
15 Informative References
15の有益な参照
[6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[6] Handley、M.、Perkins、C。and E. Whelan、「セッションアナウンスプロトコル」、RFC 2974、2000年10月。
[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。、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[8] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「リアルタイムストリーミングプロトコル（RTSP）」、RFC 2326、1998年4月。
[9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[9] Schulzrinne、H。およびS. Petrack、「DTMFディジット、テレフォニートーン、テレフォニーシグナルのRTPペイロード」、RFC 2833、2000年5月。
[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 INTIATION Protocol」、RFC 2543、1999年3月。
16 Authors' Addresses
16の著者のアドレス
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグダイナミクスソフト72イーグルロックアベニュー1階イーストハノーバー、ニュージャージー07936
EMail: jdrosen@dynamicsoft.com
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エディター機能の資金は現在、インターネット協会によって提供されています。