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.
著作権（C）インターネット協会（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）の使用は、それらの間のマルチメディアセッションの共通のビューに到達するようにすることができるメカニズムを定義します。モデルでは、一人の参加者は、彼らの視点から希望のセッションの他の記述、及びその観点から目的のセッションで他の参加者の回答を提供しています。このオファー/アンサーモデルは、両方の参加者からの情報は、セッションの完全なビューのために必要とされるユニキャストセッションで最も有用です。オファー/アンサーモデルは、セッション開始プロトコル（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.
一例として、マルチキャストセッションは、特定のメディアストリームのための単一のマルチキャストアドレスを搬送する必要があります。しかし、ユニキャストセッションのために、二つのアドレスが必要とされている - 各参加者の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アドレスおよびポートと共に、使用したいコーデックをサポートします。オファーは回答と呼ばれ、他の参加者に搬送されます。回答は、提供者によって提供されるオファーに応答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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" 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.
オファー側：セッションを作成または変更するために、セッション記述を生成し、エージェント。
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.
1つのエージェントが別のエージェントに最初のオファーを送信するときにプロトコルの動作が開始されます。それは、既に上位層プロトコルを介して確立されている可能性のあるコンテキストの外にある場合はオファーが初期です。より高い層のプロトコルは、様々な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.
任意の時点で、いずれかの薬剤は、セッションを更新し、新たなプランを生成してもよいです。それはそれはまだ答えまたは拒否していないのオファーを受けている場合しかし、それは新しいプランを生成してはなりません。それはそれはまだ答えまたは拒否を受けなかったため前のオファーを生成した場合はさらに、それは新しいプランを生成してはなりません。エージェントが1を送った後の申し出を受けた場合、それに対する回答を受信する前に、これは「グレア」の状態と考えられています。
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.
RFC 2327によって定義されるオファー（及び回答）は、一つの例外を除いて、[1]に、有効なSDPメッセージでなければなりません。 E又はPラインのいずれかが、SDPメッセージ内に存在しているRFC 2327義務付け。この仕様は、その制約を緩和します。オファー/アンサーアプリケーションのために処方SDPは、電子とpラインの両方を省略することができます。 O線にセッション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」の値を有するべきです。
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 =」行とそれに関連する属性によって記述されています）。ゼロメディアストリームは、申出が通信することを望むが、セッションのストリームを修正オファーを介して後で追加されることを意味します。ストリームはユニキャストとマルチキャストの混合であってよいです。後者は明らかに関連する「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.
オファー側が唯一のピアにストリーム上でメディアを送信したい場合は、それは同様sendonlyで「A = sendonlyで」属性を持つストリームをマークしなければなりません。私たちは、方向属性は、メディア・ストリームの属性またはセッション属性のいずれかとして存在していた場合には、特定の方向でマークされているものとしてストリームを参照してください。オファー側がピアからメディアをのみ受信したい場合は、それががrecvonlyとしてストリームをマークしなければなりません。オファー側が通信したいが、送信しないでも、この時点でメディアを受信どちらを希望する場合は、「A =非アクティブ」属性を持つストリームをマークしなければなりません。アクティブでない方向属性は、RFC 3108で指定されている[3]。 recvonlyで、リアルタイムトランスポートプロトコル（RTP）の場合には、[4]、RTCPはまだ送信され、sendonlyのために受信したことに注意してください、および不活性ストリーム。すなわち、メディア・ストリームの方向は、RTCPの使用に影響を及ぼさない、です。オファー側がピアとのメディアを送受信するには、両方たい場合は、「=のsendrecv」属性を含んでいてもよいし、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アドレスと送信元ポートについては何も示していません。提供中のゼロのポート番号は、ストリームが提供されていますが、使用してはならないことを示しています。これは最初のオファーには有益な意味を持っていませんが、答えは拒否されたストリーム（第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.
各メディアストリームのメディアフォーマットのリストは、申出を送信及び/又は受信することが可能であること（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つだけ選択するよりも、並行して提示されなければならないということです。別の制約は、複数のストリームを受信し、同じシンクに送信されたとき、彼らはいくつかのメディアの特定の方法で結合しなければならないことです。例えば、2つのオーディオストリームの場合には、それぞれの受信されたメディアは、スピーカーにマッピングされるかもしれません。その場合には、結合動作は、それらを混ぜることであろう。シンクが画面で複数のインスタントメッセージングストリームの場合には、結合動作は、ユーザインタフェースにそれらの全てを提示するであろう。第三の制約は、複数のソースが同じストリームにマッピングされる場合、それらは、ストリーム上で送信される前に、これらのソースは、いくつかのメディアの特定の方法で結合しなければならないことです。これらの制約を超えた政策は柔軟ですが、薬は一般的に、それは会議サーバ（すなわち、別のストリームに一つのストリームで受信したメディアをコピーしていない）でない限り、そのソースにそのシンクからメディアをコピーする方針を望んでいます。
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つの宛先へのメディアが必要です。これは、DTMFアプリケーションに（ユーザの観点から）sendonlyの2つのメディアストリーム、ゲートウェイへの1つのsendrecv、およびその他を用いて達成することができます。
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 =」行は、オファーのそれと等しくなければなりません。セッションの時間を交渉することができません。
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によって指定されるように、少なくとも一方が存在しなければなりません。
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または非アクティブな答えでマークする必要があります。メディアストリームを提供中がrecvonlyとしてリストされている場合、答えは答えでsendonlyでまたは非アクティブとしてマークされなければなりません。提供メディアストリームはSENDRECVとしてリストされている（またはストリームは、デフォルトでSENDRECVされた場合には、メディアまたはセッションレベルでは、方向属性は、存在しない場合）、答えにおける対応するストリームはrecvonlyで、SENDRECV、などsendonlyでマークされる場合、または非アクティブ。提供メディアストリームが非アクティブとして表示されている場合、それは答えで非アクティブとしてマークされなければなりません。
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つのオファーに列挙されたものの中から、回答を送信および受信するために、両方の意思があるコーデック含まなければなりません。ストリームは、回答は、それがに記載されていなかったので、（もちろん、この時点でそれらを送信することはできません送信または受信する意思があることを、提供の対応するストリームに表示されていない、別のメディアフォーマットを示している可能性があり提供）。答えで非アクティブとしてマークされたストリームの場合、メディア形式のリストが提供に基づいて構築されます。オファーがsendonlyでいた場合は答えががrecvonlyであるかのように、リストが構築されます。同様にオファーががrecvonlyた場合の答えが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は、一つ高いポートで受信されます）。このアドレスとポートはさえsendonlyの流れのために存在しなければなりません。 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の場合には、特定のコーデックが同じペイロードタイプ番号が回答に、そのコーデックのために使用されるべきであることを、提供中の特定ペイロードタイプ番号で参照された場合。同じペイロードタイプ番号を使用しても、答えはダイナミックペイロードタイプのためのペイロードタイプのマッピングを定義する属性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.
回答が優先それらの所望の順序でフォーマットを列挙してもよいが、特別な理由がない限り、同じ相対順序で回答リストフォーマットは、彼らが提供中に存在していることが推奨されます。言い換えれば、提供中のストリームが、そのためには、8、22と48のオーディオコーデックを示しています、と回答のみのコーデック8および48をサポートしている場合、それが推奨され、その回答は、順序をそれを変更する理由がない場合答えでコーデックが8、48、および48ではない、8にすることでこれは、同じコーデックが両方向で使用されることを保証するのに役立ちます。
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かのsendrecvストリームのメディアを受信するために準備しなければなりません、そして、それはすぐにメディアを送信することができます。メディアを送信する際にいずれかが存在していた場合、それは、提供中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.
多くの場合、その場でのコーデックを変更する必要があるでしょうので、これはMUST（アンサーためのそのまたSHOULD、としてはならない、）SHOULDではなく、その理由は、あります。例えば、沈黙期間中、エージェントは、快適雑音コーデックに切り替えたい場合があります。ユーザーがキーパッドの番号を押した場合は、エージェントが[9] RFC 2833を使用していることを送りたいかもしれません。輻輳制御は、フィードバックに基づいて、より低いレートのコーデックに変更する必要があります。
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から1インクリメントしなければならないことを除いて、前のSDPのものと同一でなければなりません。起源ラインのバージョンがインクリメントされない場合は、SDPは、そのバージョン番号を持つSDPと同じでなければなりません。回答が変更されていないバージョンにSDPが含まれているオファーを受信するように準備しなければなりません。これは事実上何もしません。しかし、回答はセクション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は、新しいSDPは、「M =」行を少なくともNでなければならず、「M =」行をNを有していました。前のSDPのi番目のメディアストリームは、上から数えて、上から数えて、新しいSDPのi番目のメディアストリームと一致します。このマッチングは、前の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を作成することによって除去されます。ストリーム記述は、すべての属性が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.
ゼロのポートで提供されたストリームは、答えにポートがゼロでマークされなければなりません。申し出のように、答えはすべての属性が提供中のものの中から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.
メディアストリームの除去は、メディアは、もはやそのストリームのために送られ、受信されたすべてのメディアが破棄されることを意味しません。任意のRTCPパケットを受信する処理を行うようにRTPの場合には、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.
ストリームのポート番号を変更してもよいです。これを行うために、提供者は、以前のSDPにおける対応するストリームとは異なるm個の行のポート番号を用いて、新たなメディア記述を作成します。唯一のポート番号を変更する場合は、メディアストリームの記述の残りの部分は変更されないまますべきです。オファー側は、すぐにオファーが送られるよう、新旧両方のポートでメディアを受信するために準備しなければなりません。オファー側は返事を受信し、メディアが新しいポートに到着するまで古いポートにメディアのリスニングを中止すべきではありません。そうすることで、遷移時のメディアの損失につながる可能性があります。
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内のストリームと同じであってもよいし、異なっていてもよいです。更新ストリームは回答によって受理された場合、回答はすぐに新しいポートにそのストリームのためのトラフィックの送信を開始する必要があります。回答は、前回の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の特定と非常に小さいペイロードタイプスペースの無駄です。第三のアプローチは、タイマーを使用することです。ピアから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.
ストリームのメディアタイプ（オーディオ、ビデオなど）を変更することがあります。同じ論理データがちょうど異なるメディア形式で、搬送されている場合、（新しいストリームを追加することとは対照的に）、メディアタイプを変更することが推奨されます。これは、両方の別々のメディアタイプであり、単一のストリームに音声帯域ファックスとファックス間で変化するために特に有用です。これを行うには、オファー側が変更される前の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.
通話中に当事者がすなわち、「hold」に相手方を置くしたい場合は、当事者が他の更新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メディアストリームだった場合、それが非アクティブにマークすることによって保留にされています。
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.
これは、ストリームが各方向に別々に「保留」に置かれることを意味します。各ストリームは、独立して「hold」に置かれています。保留ストリームのオファーの受信者は自動的に保留に対応するストリームで答えを返すべきではありません。 「保留」のすべてのストリームと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.
ユーザが保持する「押した」場合、通常、エージェントがsendonlyでの方向を示すSDP内のすべてのストリームとのオファーを生成し、そしていかなる媒体は遠端に送信されない、とされているように、それはまた、局所的にミュート、いかなるメディアはないであろうプレイアウト。
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、および接続指向のメディアとの休憩では動作しません。オファー側は、それがメディアストリームとフォーマットの特定のセットを使用したい知っているが、オファーの時点でアドレスとポートを知らない場合しかし、それは最初のオファーに有用であることができます。使用された場合もちろん、ポート番号は、ストリームが無効になっていることを指定することになる、ゼロであってはなりません。エージェントは、RTPもRTCPもピアに送信されなければならないことを意味する場合には、0.0.0.0の接続アドレスでSDPを受信することができなければなりません。
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」に等しくなければなりません。エージェントによってサポートされるメディアタイプごとに、そのタイプの対応するメディア記述がなければなりません。各SDPはメディア機能を示すために構築するために、原点フィールドに、セッションIDは一意でなければなりません。ポートは、ゼロに設定しなければなりませんが、接続アドレスは任意です。ポートゼロの使用状況は、それが提供または回答として解釈されている場合機能用にフォーマット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
V = 0 0 = IP4 100.3.6.6 S = INキャロル28908764872 28908764872 - Tは、IP4の192.0.2.4のM IN = 0のC = = 0オーディオRTP / AVP 0 1 3 A = rtpmap：0 PCMU / 8000 = rtpmap：1 1016/8000 = rtpmap：3 GSM / 8000メートル=ビデオ0 RTP / AVP 31 34 = rtpmap：31 H261 / 90000 = 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
V = 0 0 =アリス2890844526 2890844526 IN IP4 host.anywhere.com S = C = IN IP4 host.anywhere.com T = 0、M =オーディオ49170 RTP / AVP 0 A = rtpmap：0 PCMU / 8000メートル=ビデオ51372 RTP / AVP 31 = rtpmap：31 H261 / 90000 M =ビデオ53000 RTP / AVP 32 = 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:
呼び出し先、ボブは、最初のビデオストリームを受信または送信したくないので、彼は答えとして、以下の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
V = 0 0 =ボブ2890844730 2890844730 IN IP4 host.example.com S = C = IN IP4 host.example.com T = 0、M =オーディオ49920 RTP / AVP 0 A = rtpmap：0 PCMU / 8000メートル= 0ビデオRTP / AVP 31メートル=ビデオ53000 RTP / AVP 32 = 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
V = 0 0 =ボブ2890844730 2890844731 IN IP4 host.example.com S = C = IN IP4 host.example.com T = 0、M =オーディオ65422 RTP / AVP 0 A = rtpmap：0 PCMU / 8000メートル= 0ビデオRTP / AVP 31メートル=ビデオ53000 RTP / AVP 32 = rtpmap：32 MPV /9万メートル=オーディオ51434 RTP / AVP 110 = rtpmap：110電話イベント/ 8000 = recvonlyで
Alice accepts the additional media stream, and so generates the following answer:
アリスは、追加のメディアストリームを受け入れ、そしてその次の応答を生成します。
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
V = 0 0 =アリス2890844526 2890844527 IN IP4 host.anywhere.com S = C = IN IP4 host.anywhere.com T = 0、M =オーディオ49170 RTP / AVP 0 A = rtpmap：0 PCMU / 8000メートル= 0ビデオRTP / AVP 31 = rtpmap：31 H261 /9万メートル=ビデオ53000 RTP / AVP 32 = rtpmap：32 MPV /9万メートル=オーディオ53122 RTP / AVP 110 = rtpmap：110電話イベント/ 8000 = 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:
アリスからボブへの最初のオファーは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
V = 0 0 =アリス2890844526 2890844526 IN IP4 host.anywhere.com S = C = IN IP4 host.anywhere.com T = 0、M =オーディオ62986 RTP / AVP 0 4 18 = rtpmap：0 PCMU / 8000 = rtpmap：4 G723 / 8000 = rtpmap：18 G729 / 8000 =非アクティブ
Bob can support dynamic switching between PCMU and G.723. So, he sends the following answer:
ボブは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
V = 0 0 =ボブ2890844730 2890844731 IN IP4 host.example.com S = C = IN IP4 host.example.com T = 0、M =オーディオ54344 RTP / AVP 0 4 A = rtpmap：0 PCMU / 8000 = rtpmap ：4 G723 / 8000、A =非アクティブ
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 0 =アリス2890844526 2890844527 IN IP4 host.anywhere.com S = C = IN IP4 host.anywhere.com T = 0、M =オーディオ62986 RTP / AVP 4 A = rtpmap：4 G723 / 8000 = SENDRECV
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 0 =ボブ2890844730 2890844732 IN IP4 host.example.com S = C = IN IP4 host.example.com T = 0、M =オーディオ54344 RTP / AVP 4 A = rtpmap：4 G723 / 8000 = 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.
回答（ボブ）は、一の-Nのコーデックをサポートするだけで可能であった場合は、ボブが提供からコーデックのいずれかを選択し、彼の答えであることを置きます。この場合、アリスは、そのコーデックでその流れをアクティブにするために再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 =非アクティブ」を使用する代わりに、アリスは、すべてのコーデックをリスト、とすぐに、彼女はボブからメディアを受信すると、受信したばかりの1にコーデックをロックダウン更新のオファーを生成することができます。もちろん、ボブは一つだけ-の-Nのコーデックをサポートしている場合、唯一の彼の答えであるコーデックが存在することになるが、この場合には、単一のコーデックをロックダウンする再INVITEのための必要はありません。
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などのプロトコルを、シグナリングアプリケーション内輸送に依存しています。また、セキュリティ機能のためにそのプロトコルに依存しています。そのため、上記の攻撃で、そのプロトコルは、オファーとアンサーのエンド・ツー・エンドの認証と完全性保護のための手段を提供しなければなりません。これは、盗聴を防ぐために、本体の暗号化を提供する必要があります。しかし、メディアインジェクション攻撃は、代替的に認証されたメディア交換によって解決することができ、したがって、暗号化の要件ではなくMUSTにすべきです。
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.
リプレイ攻撃も問題があります。攻撃者は古い申し出、おそらく保留にメディアを入れていた1、および会話の中でこれを無効にメディアストリームを再生することができます。そのため、アプリケーションプロトコルは、オファーとアンサーを配列決定する安全な方法を提供しなければならない、と古いオファーや答えを検出および拒絶します。
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]ハンドレー、M.および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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]クマー、R.及びM.モスタファ、 "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、フレデリック、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]ハンドレー、M.、パーキンス、C.およびE.ウィーラン、 "セッション告知プロトコル"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[8] SchulzrinneとH.とラオと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. 2000 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]ハンドレー、M.、Schulzrinneと、H.、学生はE.およびJ.ローゼンバーグ、 "SIP：セッション開始プロトコル"、RFC 2543、1999年3月。
16 Authors' Addresses
16本の著者のアドレス
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
72イーグルロックアベニューまず階イーストハノーバー、NJ 07936 dynamicsoftジョナサン・ローゼンバーグ
EMail: jdrosen@dynamicsoft.com
メールアドレス：jdrosen@dynamicsoft.com
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenueニューヨークのヘニングSchulzrinneと部長、NY 10027 USA
EMail: schulzrinne@cs.columbia.edu
メールアドレス：schulzrinne@cs.columbia.edu
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。