RFC3264 日本語訳
3264 An Offer/Answer Model with Session Description Protocol (SDP). J.Rosenberg, H. Schulzrinne. June 2002. (Format: TXT=60854 bytes) (Obsoletes RFC2543) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg
Request for Comments: 3264 dynamicsoft
Obsoletes: 2543 H. Schulzrinne
Category: Standards Track Columbia U.
June 2002
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 3264dynamicsoft Obsoletes: 2543時間Schulzrinneカテゴリ: 標準化過程コロンビアU.2002年6月
An Offer/Answer Model with the Session Description Protocol (SDP)
セッション記述プロトコルがある申し出/答えモデル(SDP)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP).
このドキュメントは2つの実体がそれらの間のマルチメディアセッションの共通認識に到着するのに、Session記述プロトコル(SDP)を利用できるメカニズムを定義します。 モデルでは、1人の関係者が必要なセッションと共に必要なセッションの記述をそれらの見解、および他の関与している答えからそれらの見解からもう片方に提供します。 この申し出/答えモデルはユニキャストセッションのときに両方の関係者からの情報がセッションの完全な視点に必要であるところで最も役に立ちます。 申し出/答えモデルはSession Initiationプロトコル(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
1つの序論… 2 2用語… 3 3の定義… 3 4は操作について議定書の中で述べます… 初期の申し出を発生させる4 5… 5 5.1ユニキャストは流れます… 5 5.2マルチキャストは流れます… 答えを発生させる8 6… 9 6.1ユニキャストは流れます… 9 6.2マルチキャストは流れます… 12 7 答えの申出人処理… 12 8 セッションを変更します… 13
Rosenberg & Schulzrinne Standards Track [Page 1] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[1ページ]。
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
8.1 メディアの流れを加えます… 13 8.2 メディアの流れを取り除きます… 14 8.3 メディアの流れを変更します… 14 8.3 .1 アドレス、ポートまたは輸送を変更します… 14 8.3 .2 メディア形式のセットを変えます… 15 8.3 .3 メディアを変えるのはタイプされます… 17 8.3 .4 属性を変えます… 17 ユニキャストメディアの流れを置く8.4が持ちこたえます… 17 9 能力を示します… 18 10回の例の申し出/答え交換… 19 10.1 基本的な交換… 19 10.2 Nコーデック選択の1つ… 21 11のセキュリティ問題… 23 12のIANA問題… 23 13の承認… 23 14の引用規格… 23 15の有益な参照箇所… 24 16人の作者のアドレス… 24 17の完全な著作権宣言文… 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.
Mboneでマルチキャストセッションについて説明する方法まで運んだとき、Session記述プロトコル(SDP)[1]は元々、発想されました。 Session Announcementプロトコル(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つ。 別の例として、マルチキャストセッションはコーデックがセッションのときに使用される指示を必要とします。 しかしながら、ユニキャストのために、コーデックのセットは、各関係者によって支えられたセットでオーバラップを見つけることによって決定する必要があります。
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
その結果、SDPには、ユニキャストセッションについて説明する表情の豊かさがありますが、それは実際にどう完了しているかに関する意味論と操作上の詳細を逃しています。 本書では、私たちは、SDPに基づく簡単な申し出/答えモデルを定義することによって、それを治します。 このモデルでは、セッションの1人の関係者が申し出を構成するSDPメッセージを発生させます--申出人が申出人がメディアを受け取るのに使用したがっているIPアドレスとポートと共に使用したがっているメディアの流れとコーデックのセット。 申し出はそうです。
Rosenberg & Schulzrinne Standards Track [Page 2] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[2ページ]。
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.
answererと呼ばれるもう片方の関係者まで運ばれます。 answererは答えを発生させます。(それは、申出人によって提供された申し出に応じるSDPメッセージです)。 答えには、申し出における各流れのための合っているメディアの流れがあります、小川が受け入れられるかどうかを示して、answererがメディアを受け取るのに使用したがっている使用されるコーデック、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.
また、それもマルチキャストセッションのためにユニキャスト1と同様の仕事に可能です。 パラメタはユニキャストケースのように1組のユーザの間で交渉されますが、両側はユニキャストものよりむしろ同じマルチキャストアドレスにパケットを送ります。 また、このドキュメントは申し出/答えモデルの応用についてマルチキャストの流れと議論します。
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].
このドキュメントの範囲の外に申し出と答えが伝えられる手段があります。 ここで定義された申し出/答えモデルはSession Initiationプロトコル(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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは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.
以下に答えてください。 申し出に対応してanswererによって送られたSDPメッセージは申出人から受信されました。
Answerer: An agent which receives a session description from
another agent describing aspects of desired media
communication, and then responds to that with its own session
description.
Answerer: 必要なメディアコミュニケーションの局面について説明する別のエージェントからセッション記述を受けて、次にそれ自身のセッション記述でそれに応じるエージェント。
Rosenberg & Schulzrinne Standards Track [Page 3] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[3ページ]。
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個のスイッチが同時に同じトランクの上の同じ利用可能なサーキットを捕らえるのをともに試みる状態について説明するのにサーキットの切り換えられたテレコミュニケーションネットワークに使用されました。 ここで、それは、両方のエージェントが、同時にアップデートされた申し出を送るのを試みたことを意味します。
Rosenberg & Schulzrinne Standards Track [Page 4] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[4ページ]。
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つの例外があるRFC2327[1]によって定義されるように有効なSDPメッセージであるに違いありません。 RFC2327は、eかp線のどちらかがSDPメッセージに存在しているのを強制します。 この仕様はその規制を弛緩します。 申し出/答えアプリケーションのために定式化されたSDPはeとp線の両方を省略するかもしれません。 o線における、セッションイドとバージョンの数値は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=」線はセッションの対象を伝えます。(マルチキャストのために合理的に定義されていますが、セッションはユニキャストのためにほとんど定義されていません)。 ユニキャストセッションのために、シングルスペースキャラクタ(0×20)かダッシュ(-)から成るのは、RECOMMENDEDです。
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=」線SHOULDには値がある、「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=」線とその関連属性によって説明されます)。 どんなメディアの流れも、申出人が交信したがっていますが、セッションのための流れが後で変更された申し出で加えられるのを含意しません。 流れはユニキャストとマルチキャストのミックスのためのものであるかもしれません。 後者は関連「c=」線で明らかにマルチキャストアドレスを含意します。
Construction of each offered stream depends on whether the stream is multicast or unicast.
それぞれの提供された流れの工事は流れがマルチキャストかそれともユニキャストであるかによります。
5.1 Unicast Streams
5.1 ユニキャストの流れ
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
申出人が同輩への流れにメディアを送るだけでありたいなら、それは同じくらいsendonlyに"a=sendonly"属性を流れに付けなければなりません。 または私たちが指示属性がメディアの流れが結果と考えるどちらかとして存在していたならある指示でマークされると流れを呼ぶ。
Rosenberg & Schulzrinne Standards Track [Page 5] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[5ページ]。
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.
セッション属性。 申出人が同輩からメディアを受け取るだけでありたいなら、それは、流れがrecvonlyであるとマークしなければなりません。 申出人がこのときメディアを交信することを願いますが、送付でない、受け取りたくないなら、それは「a=不活発な」属性を流れに付けなければなりません。 不活発な指示属性はRFC3108[3]で指定されます。 RTCPがレアルTime Transportプロトコル(RTP)[4]の場合では、まだ送られて、sendonlyのために受け取られることに注意してください、recvonlyであって、不活発な流れ。すなわち、メディアの流れの方向性はRTCP用法に変化も与えません。 申出人が同輩と共にメディアをともに送って、受け取りたいなら、"a=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レポートを受け取りたがっているかを間接的に示します。 そうでなければ、明白な指示がない場合、数が示したより高いポートナンバーワンにレポートを送ります。 申し出におけるIPアドレスとポートプレゼントは申出人によって送られるRTPとRTCPパケットのソースIPアドレスとソース港の周りに何も示しません。 申し出における、ゼロのポートナンバーは、流れを提供しますが、使用してはいけないのを示します。 これは、初期の申し出ではどんな役に立つ意味論も持っていませんでしたが、完全性の理由で許容されて、aを示すと、答えがaゼロポートを含むことができるので、流れ(セクション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ペイロード形式数)の場合で2つの情報、すなわち、送る、そして/または、申出人が受けることができる(指示属性に依存します)書式(RTPの場合におけるコーデックに関連しているコーデックとどんなパラメタも)のセットを運びます。 複数の形式が記載されているなら、それは、申出人がセッションの間それらの形式のどれかを利用できることを意味します。 言い換えれば、answererはセッションの途中で形式を変えるかもしれません、形式のどれかの使用を記載させて、新しい申し出を送らないで。 sendonlyの流れのために、申し出SHOULDは申出人がこの流れのために送っても構わないと思っているそれらの書式を示します。 recvonlyの流れのために、申し出SHOULDは申出人がこの流れのために受けても構わないと思っているそれらの書式を示します。 sendrecvの流れのために、申し出SHOULDは送って、申出人が受信しても構わないと思っているそれらのコーデックを示します。
For recvonly RTP streams, the payload type numbers indicate the value of the payload type field in RTP packets the offerer is expecting to receive for that codec. For sendonly RTP streams, the payload type numbers indicate the value of the payload type field in RTP packets
recvonly RTPの流れのために、ペイロード形式数は申出人がそのコーデックのために受けると予想しているRTPパケットのペイロードタイプ分野の値を示します。sendonly RTPの流れのために、ペイロード形式数はRTPパケットのペイロードタイプ分野の値を示します。
Rosenberg & Schulzrinne Standards Track [Page 6] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[6ページ]。
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.
申出人は、そのコーデックのために発信するのを計画しています。ペイロード形式数は、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.
RFC2327に従って、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の流れ、SHOULDが"a=rtpmap"マッピングを含むすべてのメディア記述の場合では、RTPペイロードはencodingsにタイプされます。 "a=rtpmap"が全くなければ、デフォルトペイロードはマッピングをタイプします、使用中の現在のプロフィールによって定義されるように。(例えば、RFC1890[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=」線における書式を記載しなければなりません、記載された都合のよいので最初の書式で。 この場合申し出SHOULDの受取人が許容できる最も高い好みがある形式を使用する都合のよい手段、それ。
If the ptime attribute is present for a stream, it indicates the desired packetization interval that the offerer would like to receive. The ptime attribute MUST be greater than zero.
ptime属性が流れのために存在しているなら、それは申出人が受けたがっている必要なpacketization間隔を示します。 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
同じタイプのマルチメディアの流れが申し出で存在しているなら、それは、申出人が同時にそのタイプの複数の流れを送りたがっていることを(受信してください)意味します。 同じタイプの複数の流れを送るとき、それはそのタイプ(例えば、ビデオの場合におけるビデオカメラとVCR)の各メディア・ソースがどう各流れに写像されるかに関するローカルの方針の問題です。 ユーザに特定のメディアタイプのための単独のソースがあるとき、1つの方針だけが理解できます: 同じタイプの各流れにソースを送ります。 各流れは異なったencodingsを使用するかもしれません。 受信倍数が同じように流れる時
Rosenberg & Schulzrinne Standards Track [Page 7] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[7ページ]。
type, it is a matter of local policy as to how each stream is mapped to the various media sinks for that particular type (for example, speakers or a recording device in the case of audio). There are a few constraints on the policies, however. First, when receiving multiple streams of the same type, each stream MUST be mapped to at least one sink for the purpose of presentation to the user. In other words, the intent of receiving multiple streams of the same type is that they should all be presented in parallel, rather than choosing just one. Another constraint is that when multiple streams are received and sent to the same sink, they MUST be combined in some media specific way. For example, in the case of two audio streams, the received media from each might be mapped to the speakers. In that case, the combining operation would be to mix them. In the case of multiple instant messaging streams, where the sink is the screen, the combining operation would be to present all of them to the user interface. The third constraint is that if multiple sources are mapped to the same stream, those sources MUST be combined in some media specific way before they are sent on the stream. Although policies beyond these constraints are flexible, an agent won't generally want a policy that will copy media from its sinks to its sources unless it is a conference server (i.e., don't copy received media on one stream to another stream).
タイプ、それは各流れがその特定のタイプ(例えば、スピーカーかオーディオの場合における録音装置)のためにどう様々なメディア流し台に写像されるかに関するローカルの方針の問題です。 しかしながら、いくつかの規制が方針にあります。同じタイプの複数の流れを受けるとき、最初に、ユーザへのプレゼンテーションの目的のために少なくとも1個の流し台に各流れを写像しなければなりません。 言い換えれば、同じタイプの複数の流れを受ける意図はそれらがちょうど1つを選ぶより平行にむしろすべて提示されるべきであるということです。 別の規制は複数の小川を同じ流し台に受け取って、送るとき、何らかのメディア詳細方法でそれらを結合しなければならないということです。 例えば、2つのオーディオストリームのケースでは、それぞれからの受け取られていているメディアはスピーカーに写像されるかもしれません。 その場合、結合操作はそれらを混ぜるだろうことです。 複数のインスタントメッセージングストリームのケースの中では、結合操作はそれらを皆、ユーザーインタフェースに提示するだろうことです。そこでは、流し台がスクリーンです。 3番目の規制は複数のソースを同じ流れに写像するなら、それらを流れに送るずっと前にいくつかのメディアで特定の状態でそれらのソースを結合しなければならないということです。 これらの規制を超えた方針はフレキシブルですが、一般に、エージェントはそれが会議サーバ(すなわち、1つの流れのときに別の流れに受け取られていているメディアをコピーしない)でないなら流し台からソースまでメディアをコピーする方針が欲しくないでしょう。
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つのメディアの流れ、ゲートウェイへの1sendrecv、および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に送ることができないでしょう。
5.2 Multicast Streams
5.2 マルチキャストの流れ
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.
セッション記述が受信するとき(発信します)記載されたマルチキャストメディアの流れだけを含んでいるなら、それは、申出人とanswererを含む関係者がその流れのときに受信できるだけであることを(発信します)意味します。 これはユニキャスト視点と異なっています。そこでは、方向性が申出人とanswererの間のメディアの流れについて言及します。
Rosenberg & Schulzrinne Standards Track [Page 8] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[8ページ]。
Beyond that clarification, the semantics of an offered multicast stream are exactly as described in RFC 2327 [1].
その明確化を超えて、提供されたマルチキャストの流れの意味論はまさにRFC2327[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.
提供された流れはどんな理由のための答えでも拒絶されるかもしれません。 流れが拒絶されるなら、申出人とanswererはその流れのためのメディア(または、RTCPパケット)を作ってはいけません。 提供された流れを拒絶するために、答えにおける対応する流れにおけるポートナンバーをゼロに設定しなければなりません。 形式が記載したどんなメディアも無視されます。 SDPによって指定されるように少なくとも存在していなければなりません。
Constructing an answer for each offered stream differs for unicast and multicast.
それぞれの提供された流れのための答えを構成するのはユニキャストとマルチキャストのために異なります。
6.1 Unicast Streams
6.1 ユニキャストの流れ
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です)、答えにおける対応する流れは、sendonlyであって、recvonlyなsendrecvとして著しいか、または不活発であるかもしれません。 提供されたメディアの流れが不活発であるとして記載されるなら、答えで不活発であるとしてそれをマークしなければなりません。
Rosenberg & Schulzrinne Standards Track [Page 9] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[9ページ]。
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=」線はanswererが申し出で記載されたものから受信しても構わないと思っている少なくとも1つのメディア形式を含まなければなりません。 流れはanswererが受けても構わないと思っている申し出における対応する流れで記載されなかった追加メディア書式を示すかもしれません。 答えでsendonlyであるとマークされた流れのために、「m=」線はanswererが申し出で記載されたものから送っても構わないと思っている少なくとも1つのメディア形式を含まなければなりません。 sendrecvとして答えでマークされた流れのために、「m=」線はともに送って、answererが受けても構わないと思っている少なくとも1つのコーデックを含まなければなりません、申し出で記載されたものから。 流れは送るか、またはanswererが受けても構わないと思っている申し出における対応する流れで記載されなかった追加メディア書式を示すかもしれません(もちろん、このときそれらを送ることができないでしょう、それが申し出で記載されなかったので)。 答えで不活発であるとしてマークされた流れにおいて、メディア形式のリストは申し出に基づいて構成されます。 申し出が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.
答えにおける接続アドレスとポートはanswererがメディアを受け取りたがっている(RTPの場合では、そうでなければ、明白な指示がない場合、より高く1であるポートの上にRTCPを受け取るでしょう)アドレスを示します。 このアドレスとポートはsendonlyの流れのためにさえ存在していなければなりません。 1つをより高く移植してください。RTPの場合に使用する、RTCPを受け取るのがまだ使用されています。
In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer. Even if the same payload type number is used, the answer MUST contain rtpmap attributes to define the payload type mappings for dynamic payload types, and SHOULD contain mappings for static payload types. The media formats in the "m=" line MUST be listed in order of preference, with the first format listed being preferred. In this case, preferred means that the offerer SHOULD use the format with the highest preference from the answer.
RTPの場合では、特定のコーデックが申し出における特定のペイロード形式数で参照をつけられて、そんなに同じペイロード形式数SHOULDであったなら答えにおけるそのコーデックに使用されてください。 同じペイロード形式数が使用されていても、答えはダイナミックなペイロードタイプのためにペイロードタイプマッピングを定義するrtpmap属性を含まなければなりません、そして、SHOULDは静的なペイロードタイプへのマッピングを含んでいます。 好みの順に「m=」線におけるメディア書式を記載しなければなりません、記載された都合のよいので最初の書式で。 この場合、好まれる、申出人SHOULDが答えから最も高い好みがある形式を使用することを意味します。
Although the answerer MAY list the formats in their desired order of preference, it is RECOMMENDED that unless there is a specific reason, the answerer list formats in the same relative order they were present in the offer. In other words, if a stream in the offer lists audio codecs 8, 22 and 48, in that order, and the answerer only supports codecs 8 and 48, it is RECOMMENDED that, if the answerer has
answererは彼らの好みの必要な注文における書式を記載するかもしれませんが、それはそこでないなら特定の理由であるRECOMMENDEDです、answererリスト形態。同じ相対オーダでは、それらは申し出で存在していました。 言い換えれば、申し出における流れがオーディオコーデック8、22、および48を記載するなら、注文してください。そうすれば、answererがコーデック8と48を支持するだけであるのでそれがRECOMMENDEDである、それ、answererはそうしました。
Rosenberg & Schulzrinne Standards Track [Page 10] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[10ページ]。
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.
いいえはそれを変えるために推論して、中のコーデックの注文は答えです。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パラメタを含むかもしれません、そして、それらの5月には、申し出におけるそれらと同じ値があるか、またはそれらは異なっているかもしれません。 新しいパラメタSHOULDを定義する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.
answererはどんなメディアの流れのための非ゼロptime属性も含むかもしれません。 これはanswererが受けたがっているpacketization間隔を示します。 packetization間隔が特定の流れのための各方向と同じであるという要件が全くありません。
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.
answererはどんなメディアの流れのための帯域幅属性も含むかもしれません。 これはanswererが、メディアを送るとき、申出人に使用して欲しい帯域幅を示します。 セクション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.
answererが特定の提供された流れのためにメディア形式が全く共通でないなら、answererは、ゼロにポートを設定することによって、そのメディアの流れを拒絶しなければなりません。
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
answererがいったん答えを送ると、その答えで説明されたどんなrecvonlyの流れのためのメディアも受け取るのは準備していなければなりません。 答えにおけるどんなsendrecvの流れのためのメディアも送って、受け取るのが準備していなければならなくて、それはすぐに、メディアを送るかもしれません。 答えにおけるそれらの流れのために記載されたどんなメディア書式も使用して、recvonlyのためのメディアかsendrecvの流れを受け取るようにanswererを準備しなければなりません、そして、それはすぐに、メディアを送るかもしれません。 メディアを送るときそれ、SHOULDは申し出における、ptime属性の値と等しいpacketization間隔を費やします、いずれか存在していたなら。 それ、SHOULDはa帯域幅を申し出における、帯域幅属性の値より高く使用しないことでメディアを送ります、いずれか存在していたなら。 また、答えで記載されている申し出にメディア形式を使用して、answererは発信しなければなりません、そして、SHOULDはまたそれが記載されている申し出で最も都合のよいメディア形式を使用することで発信します。
Rosenberg & Schulzrinne Standards Track [Page 11] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[11ページ]。
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.
答えてください。 RTPの場合では、申し出からペイロード形式数を使用しなければなりません、答えにおけるそれらと異なっても。
6.2 Multicast Streams
6.2 マルチキャストの流れ
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)における方向性情報は申し出のものと等しくなければなりません。 これはマルチキャストセッションのすべての関係者がセッションのパラメタの同等な眺めを必要とするからです、RFC2327のマルチキャスト偏見の基本的な仮定。
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.
メディアのセットは答えが等しいに違いないコネをフォーマットするか、申し出におけるそれらの部分集合になってください。 形式を取り除くのは、answererが、形式が支持されないのを示す方法です。
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として答えで記載されています)。 発信するとき、それは最初のメディア形式が答えで記載したSHOULD使用を答えで記載されたメディア書式を使用して、それに送らなければなりません。
The reason this is a SHOULD, and not a MUST (its also a SHOULD,
and not a MUST, for the answerer), is because there will
oftentimes be a need to change codecs on the fly. For example,
during silence periods, an agent might like to switch to a comfort
noise codec. Or, if the user presses a number on the keypad, the
agent might like to send that using RFC 2833 [9]. Congestion
control might necessitate changing to a lower rate codec based on
feedback.
これがaではなく、SHOULDである理由がそうしなければならない、(また、それはSHOULDです、そして、どんなaもSHOULDであってはいけません、answererのために)急いでコーデックを変える必要がしばしばあるので。 例えば、沈黙の期間、エージェントは、安らぎ雑音コーデックに切り替わるのが好きであるかもしれません。または、ユーザがキーパッドの数を押すなら、エージェントは、RFC2833[9]を使用することでそれを送るのが好きであるかもしれません。 輻輳制御は、フィードバックに基づく低料金コーデックに変化するのを必要とするかもしれません。
The offerer SHOULD send media according to the value of any ptime and bandwidth attribute in the answer.
答えにおける、どんなptimeと帯域幅属性の値に応じても、申出人SHOULDはメディアを送ります。
The offerer MAY immediately cease listening for media formats that were listed in the initial offer, but not present in the answer.
申出人は、すぐに、答えでプレゼントではなく、初期の申し出で記載されたメディア書式の聞こうとするのをやめるかもしれません。
Rosenberg & Schulzrinne Standards Track [Page 12] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[12ページ]。
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について言及します。 申し出が同じであるなら、答えがanswererからの前の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.
ほとんどセッションの全面を変更できます。 新しい流れを加えることができます、そして、既存の流れを削除できます、そして、既存の流れのパラメタは変化できます。 セッションを変更する申し出、「o=」に線を発行するときには新しいSDP MUSTが、前のSDPでそれと同じにしてください、起源分野のバージョンが前からSDPを1つ増加しなければならないのを除いて。 起源線におけるバージョンであるなら、増分、SDP MUSTはそのバージョン番号でSDPと同じではありませんか? 変化していないバージョンでSDPを含む申し出を受けるようにanswererを準備しなければなりません。 事実上、これはオプアートではありません。 しかしながら、answererは有効な答え(answererからの前のSDPと同じであるかもしれないか、または異なっているかもしれない)を発生させなければなりません、セクション6で定義された手順によると。
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 MUSTは前のSDPにそれぞれのメディアの流れのための合っているメディアの流れを持っています。 言い換えれば、前のSDPにN「m=」の線があったなら、新しいSDP MUSTには少なくともN「m=」の線があります。 i、-、メディアは前のSDPを流れます、先端から数えて、第マッチ、i、-、メディアが新しいSDPを流れます、先端から数えて第。 answererが、新しいSDPのどの流れが前のSDPの流れに対応するかを決定するのにこのマッチングが必要です。 これらの要件のために、流れにおける、「m=」線の数は、減少しますが、同じままである、または決して増加しません。 取り除かれたコネが新しいSDPであったなら前のSDP MUST NOTからメディアの流れを削除します。 しかしながら、これらの流れのための属性は存在している必要はありません。
8.1 Adding a Media Stream
8.1 メディアの流れを加えること。
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.
ニューメディアの流れは、既存のものの下における新しい追加メディア記述、またはゼロにポートを設定することによって無効にされた古いメディアの流れで使用される「スロット」を再利用することによって、作成されます。
Rosenberg & Schulzrinne Standards Track [Page 13] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[13ページ]。
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.
answererが受信されるとき、メディアの流れがポートによる以前にゼロ、answererが、ニューメディアの流れが加えられているのを知っているということであったスロットにある状態で、申出人からの前のSDP、またはそれより多くのメディア記述があるSDPはSDPを受けます。 答えにおける適切に構造化されたメディア記述を置くことによって、これらを拒絶するか、または受け入れることができます。 答えにおけるニューメディア記述を構成するための手順はセクション6で説明されます。
8.2 Removing a Media Stream
8.2 メディアの流れを取り除くこと。
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に閉じることによって終わったのを示すかもしれません。
8.3 Modifying a Media Stream
8.3 メディアの流れを変更すること。
Nearly all characteristics of a media stream can be modified.
メディアの流れのほとんどすべての特性を変更できます。
8.3.1 Modifying Address, Port or Transport
8.3.1 アドレス、ポートまたは輸送を変更すること。
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で線異なったポートナンバーで。 唯一のポートナンバーが変えることであるなら、メディアの流れの記述SHOULDの残りは変わりがありません。 申出人は申し出を送るとすぐに、両方の古くて新しいポートの上にメディアを受け取る用意ができていなければなりません。 申出人SHOULD NOTは、答えが受け取られていて、メディアが新しいポートの上で到着するまで古いポートの上でメディアの聞こうとするのをやめます。 そうするのは変遷の間、メディアの損失をもたらすかもしれません。
Rosenberg & Schulzrinne Standards Track [Page 14] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[14ページ]。
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から流れと同じであるかもしれませんか、またはそれは異なっているかもしれません。 アップデートされた小川がanswererによって受け入れられるなら、answerer SHOULDはすぐに、その流れのための交通を新しいポートに送り始めます。 answererが前のSDPからポートを変えるなら、答えを送るとすぐに、両方の古くて新しいポートの上にメディアを受け取るのは準備していなければなりません。 answererは、メディアが新しいポートの上で到着するまで古いポートの上でメディアの聞こうとするのをやめてはいけません。 その時、それは、古いポートの上でメディアの聞こうとするのをやめるかもしれません。 新しいポートによるアップデートされた申し出を送る申出人にとって、同じくらいは本当です。 それは、メディアが新しいポートの上で到着するまで古いポートの上でメディアの聞こうとするのをやめてはいけません。
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.
流れのための輸送を変えるかもしれません。 ポートではなくするためのこれは輸送を除いて、ポートを変えるのが同じである過程をアップデートします。
8.3.2 Changing the Set of Media Formats
8.3.2 メディア形式のセットを変えること。
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の場合では、そのメディアの流れの中の特定のダイナミックなペイロード形式数から特定のコーデックまでのマッピングはセッションの持続時間のために変化してはいけません。 例えば、G.711がダイナミックなペイロード形式数46に割り当てられている状態でAが申し出を発生させるなら、ペイロード形式数46はセッション中にそのメディアの流れのためのどんな申し出や答えでもそのポイントからのG.711を前方と呼ばなければなりません。 しかしながら、複数のペイロード形式数が同じコーデックに写像されるのは、許容できます、また、アップデートされた申し出がG.711のペイロード形式数72を使用できるように。
Rosenberg & Schulzrinne Standards Track [Page 15] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[15ページ]。
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で説明されるように定式化されて、また、メディア形式における変化をもたらすかもしれません。 同様に、答えを送るとすぐに、answererは、セクション6で説明されるように答えに申し出におけるどんなまた、存在している形式も使用することでメディアを送り始めなければなりません、そして、SHOULDはまた、答え(流れを仮定するのは、発信すると考慮する)で記載されて、少しの申し出中でない形式も使用して、発信してはいけない申し出で最も都合のよい形式を使用します、それらが前のSDPに同輩から存在していたとしても。 申出人が答えを受けるとき、同様に、答えにどんな形式も使用するのをメディアに送って、1つ(流れを仮定するのは、発信すると考慮する)を大部分が好んだSHOULD使用に送り始めなければならなくて、少しの答え中でない形式も使用して、発信してはいけません、それらが前の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.
もちろん、提供された流れが拒絶されるなら、申し出は受けるように準備されるのを拒絶が受け取られているとすぐに、どんな新しい形式も使用することでやめることができます。
Rosenberg & Schulzrinne Standards Track [Page 16] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[16ページ]。
8.3.3 Changing Media Types
8.3.3 メディアを変えるのはタイプされます。
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.
流れのためのメディアタイプ(オーディオ、ビデオなど)を変えるかもしれません。 メディアタイプを変えるのは(新しい流れを加えることと対照的に)、RECOMMENDEDです、しかし、同じ論理的なデータがまさしく異なったメディア形式で伝えられているとき。 これが特にvoicebandファックスとファックスの間でただ一つの流れで変化することの役に立つ、どれが両方であるかがメディアタイプを切り離します。 これをするために、申出人はニューメディア記述を作成します、ニューメディアタイプで、変えられることになっている前の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で説明されるように定式化されます。 流れが許容していると仮定して、申し出を受けるとすぐに、answerer SHOULDはニューメディアタイプと形式と共に発信し始めます。 申出人は、答えが受け取られていて、受け取られているまで新しさがあるメディアが、タイプする両方の古くて新しいタイプでメディアを受け取るように準備しなければならなくて、再生バッファの上部に着きます。
8.3.4 Changing Attributes
8.3.4 属性を変えること。
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は受け取られています。
8.4 Putting a Unicast Media Stream on Hold
8.4 ユニキャストメディアの流れを保留にすること。
If a party in a call wants to put the other party "on hold", i.e., request that it temporarily stops sending one or more unicast media streams, a party offers the other an updated SDP.
呼び出しにおけるパーティーが「保持」に相手を置きたいなら、すなわち、1つ以上のユニキャストメディアの流れを送るのを一時止めて、パーティーがアップデートされたSDPをもう片方に申し出るよう要求してください。
If the stream to be placed on hold was previously a sendrecv media stream, it is placed on hold by marking it as sendonly. If the stream to be placed on hold was previously a recvonly media stream, it is placed on hold by marking it inactive.
以前に保持に置かれるべき流れがそうであったなら、sendrecvメディアは流れて、それがsendonlyであるとマークすることによって、それは保持に置かれます。 以前に保持に置かれるべき流れがそうであったなら、recvonlyメディアは流れて、それが不活発であるとマークすることによって、それは保持に置かれます。
This means that a stream is placed "on hold" separately in each direction. Each stream is placed "on hold" independently. The recipient of an offer for a stream on-hold SHOULD NOT automatically return an answer with the corresponding stream on hold. An SDP with all streams "on hold" is referred to as held SDP.
これは、小川が別々に各指示に「保持」に置かれることを意味します。 各小川は独自に「保持」に置かれます。 対応する流れが保留にされている中に保持でのSHOULD NOTが自動的に答えを返す流れのための申し出の受取人。 すべての流れが「保持」にあるSDPは保持されたSDPと呼ばれます。
Certain third party call control scenarios do not work when an
answerer responds to held SDP with held SDP.
answererが保持されたSDPと共に保持されたSDPに応じるとき、ある第三者呼び出しコントロールシナリオは働いていません。
Rosenberg & Schulzrinne Standards Track [Page 17] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[17ページ]。
Typically, when a user "presses" hold, the agent will generate an offer with all streams in the SDP indicating a direction of sendonly, and it will also locally mute, so that no media is sent to the far end, and no media is played out.
したがって、「プレス」が保持するユーザ、エージェントがSDPのすべての流れがsendonlyの指示を示している申し出を発生させて、また、局所的に音を消すとき、通常、メディアを全く遠端にもかかわらず、メディアがないのに送らないのは使い果たされます。
RFC 2543 [10] specified that placing a user on hold was accomplished by setting the connection address to 0.0.0.0. Its usage for putting a call on hold is no longer recommended, since it doesn't allow for RTCP to be used with held streams, doesn't work with IPv6, and breaks with connection oriented media. However, it can be useful in an initial offer when the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and ports at the time of the offer. Of course, when used, the port number MUST NOT be zero, which would specify that the stream has been disabled. An agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer.
RFC2543[10]は、保持でのユーザが接続を設定しながら達成された入賞が.0に.0を0.0まで記述すると指定しました。 呼び出しを保留にするための用法はもうお勧めではありません、RTCPが保持された流れと共に使用されるのを許容しないで、IPv6と共に働かないで、接続と共に指向のメディアを破るので。 しかしながら、申出人が、メディアの流れと特定の形式を使用したいのですが、申し出時点でアドレスとポートを知らないのを知っているとき、それは初期の申し出で役に立つ場合があります。 もちろん、使用されると、ポートナンバーはゼロであるはずがありません。(そのゼロは、流れが無効にされたと指定するでしょう)。 エージェントは0.0の接続アドレスでSDPを受けることができなければなりません。.0 .0 その場合、それは、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.
エージェントが申し出を送る前に、それの形式が提供するメディアがanswererに許容できるかどうかを知るのは役立っています。 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インチ」 エージェントによって支持されたそれぞれのメディアタイプのために、そのタイプの対応するメディア記述があるに違いありません。 メディア能力を示すために組み立てられた各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
「m=」線の輸送の部品はそのメディアタイプのために輸送を示します。 そこでエージェントによって支持されたそのタイプのそれぞれのメディア形式、SHOULD、「m=」線で記載されたメディア書式になってください。 RTPに関するケース、使用されるダイナミックなペイロードタイプ、rtpmapです。
Rosenberg & Schulzrinne Standards Track [Page 18] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[18ページ]。
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.
属性は、特定の形式にタイプを縛るために存在していなければなりません。 規制を示す方法が全くありません、特定のコーデックなどのためにいくつの同時の流れを支持できるのなどように。
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
キャロル28908764872 28908764872IN IP4 100.3.6.6 s=v=0o=tが0 0c=IN IP4と等しい、192.0、.2、.4m、=オーディオの0RTP/AVP0 1 3a=rtpmap: 0 PCMU/8000a=rtpmap: 1 1016/8000a=rtpmap: 3GSM/8000mはビデオ0RTP/AVP31 34a=rtpmap: 31H261/90000 a=rtpmapと等しいです:、34H263/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.
このセクションは例の申し出/答え交換を供給します。
10.1 Basic Exchange
10.1 基本的な交換
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:
訪問者(アリス)が彼女の申し出における以下の記述を入れたと仮定してください。 それは双方向のオーディオストリームと2つの双方向のビデオストリームを含んでいます、H.261(ペイロードタイプ31)とMPEG(ペイロードタイプ32)を使用して。 提供された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
IN v=0 o=alice2890844526 2890844526IN IP4 host.anywhere.com s=c=IP4 host.anywhere.com tは0 0m=オーディオの49170RTP/AVP0a=rtpmapと等しいです: 0PCMU/8000mはビデオ51372RTP/AVP31a=rtpmapと等しいです: 31H261/90000mはビデオ53000RTP/AVP32a=rtpmap: 32MPV/90000と等しいです。
Rosenberg & Schulzrinne Standards Track [Page 19] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[19ページ]。
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
INボブの2890844730 2890844730IN v=0o=IP4 host.example.com s=c=IP4 host.example.com tは0 0m=オーディオの49920RTP/AVP0a=rtpmapと等しいです: 0PCMU/8000mは31mのビデオ0RTP/AVP=ビデオ53000RTP/AVP32a=rtpmap: 32MPV/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までの)を受けるところ、および同時にポートを変えるために、受信専用であるとして追加オーディオストリームを加えてください、出来事[9]にRTPペイロード形式を使用して。 ボブは申し出で以下の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
INボブの2890844730 2890844731IN v=0o=IP4 host.example.com s=c=IP4 host.example.com tは0 0m=オーディオの65422RTP/AVP0a=rtpmapと等しいです: 0PCMU/8000mは31mのビデオ0RTP/AVP=ビデオ53000RTP/AVP32a=rtpmap: 32MPV/90000m=オーディオの51434RTP/AVP110a=rtpmap: 110回の電話出来事/8000a=recvonlyと等しいです。
Rosenberg & Schulzrinne Standards Track [Page 20] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[20ページ]。
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
IN v=0 o=alice2890844526 2890844527IN IP4 host.anywhere.com s=c=IP4 host.anywhere.com tは0 0m=オーディオの49170RTP/AVP0a=rtpmapと等しいです: 0PCMU/8000mはビデオ0RTP/AVP31a=rtpmapと等しいです: 31H261/90000mはビデオ53000RTP/AVP32a=rtpmap: 32MPV/90000m=オーディオの53122RTP/AVP110a=rtpmap: 110回の電話出来事/8000a=sendonlyと等しいです。
10.2 One of N Codec Selection
10.2 Nコーデック選択の1つ
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:
初期のアリスからボブまでの申し出は3つのDSPで利用可能なオーディオコーデックでただ一つのオーディオストリームを示します。 流れは、コーデックが以下にロックされるまでメディアを受け取ることができないので、不活発であるとしてマークされます。
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
0 0IN v=0 o=alice2890844526 2890844526IN IP4 host.anywhere.com s=c=IP4 host.anywhere.com t=mがオーディオの62986RTP/AVPと等しい、0 4、18a=rtpmap、: 0PCMU/8000a=rtpmap: 4G723/8000 a=rtpmap: 18G729/8000a=、不活発
Rosenberg & Schulzrinne Standards Track [Page 21] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[21ページ]。
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
INボブの2890844730 2890844731IN v=0o=IP4 host.example.com s=c=IP4 host.example.com tは0 0m=オーディオの54344RTP/AVP0 4a=rtpmap: 0PCMU/8000a=rtpmap: 4G723/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
0 0IN v=0 o=alice2890844526 2890844527IN IP4 host.anywhere.com s=c=IP4 host.anywhere.com t=m=オーディオの62986RTP/AVP4a=rtpmap: 4G723/8000 a=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
0 0INボブの2890844730 2890844732IN v=0o=IP4 host.example.com s=c=IP4 host.example.com t=m=オーディオの54344RTP/AVP4a=rtpmap: 4G723/8000 a=sendrecv
If the answerer (Bob), was only capable of supporting one-of-N codecs, Bob would select one of the codecs from the offer, and place that in his answer. In this case, Alice would do a re-INVITE to activate that stream with that codec.
answerer(ボブ)がNの1つのコーデックしか支持できないなら、ボブは、申し出からコーデックの1つを選択して、彼の答えにそれを置くでしょうに。 この場合、アリスは、そのコーデックでその流れを起動するために再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=不活発な」使用に代わる手段として、アリスはすべてのコーデックを記載できます、そして、彼女がボブからメディアを受け取るとすぐに、コーデックの下側にロックされるアップデートされた申し出をただ受け取られたものに発生させてください。 もちろん、ボブがNの1つのコーデックしか支持しないなら、彼の答えには1つのコーデックしかないでしょう、そして、この場合、再INVITEが単一のコーデックまでロックする必要は全くありません。
Rosenberg & Schulzrinne Standards Track [Page 22] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[22ページ]。
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などのアプリケーションシグナリングプロトコルの中で輸送に依存します。 また、それはセキュリティ能力のためにそのプロトコルを当てにします。 上で説明された攻撃のために、そのプロトコルは申し出と答えの終わりから終わりへの認証と保全保護のための手段を提供しなければなりません。 それ、SHOULDは、盗み聞くのを防ぐためにボディーの暗号化を提供します。 しかしながら、あるいはまた、認証されたメディア交換を通してメディア注射攻撃を決議できます、そして、したがって、暗号化要件は決議されています。aの代わりにSHOULDはそうしなければなりません。
Replay attacks are also problematic. An attacker can replay an old offer, perhaps one that had put media on hold, and thus disable media streams in a conversation. Therefore, the application protocol MUST provide a secure way to sequence offers and answers, and to detect and reject old offers or answers.
また、反射攻撃も問題が多いです。 攻撃者は古い申し出を再演できて、恐らく、それがメディアを保留にして、その結果、メディアを無効にするのをさせた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.
作者は彼らの詳細なコメントについてアリソン・マンキン、Rohanマーイ、ヨルク・オット、およびフレミングAndreasenに感謝したがっています。
14 Normative References
14 標準の参照
[1] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[1] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、1998年4月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、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] クマー、R.、およびM.Mostafa、「セッション記述の使用のためのコンベンションは気圧運搬人コネクションズのために(SDP)について議定書の中で述べます」、RFC3108、2001年5月。
Rosenberg & Schulzrinne Standards Track [Page 23] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[23ページ]。
[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.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[5] Schulzrinne, H., "RTP Profile for Audio and Video Conferences
with Minimal Control", RFC 1890, January 1996.
[5]Schulzrinne、H.、「最小量のコントロールがあるオーディオとテレビ会議システムのためのRTPプロフィール」、RFC1890、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.ウィーラン、「セッション発表プロトコル」、RFC2974、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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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)」、RFC2326 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有効搭載量」、RFC2833)は2000がそうするかもしれません。
[10] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[10] ハンドレー、M.、Schulzrinne、H.、学生、E.、およびJ.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、1999年3月。
16 Authors' Addresses
16人の作者のアドレス
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
ジョナサンローゼンバーグdynamicsoft72Eagle Rock AvenueのFirst Floorの東ハノーバー王家、ニュージャージー 07936
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ニューヨーク10027ニューヨーク(米国)のヘニングSchulzrinne部
EMail: schulzrinne@cs.columbia.edu
メール: schulzrinne@cs.columbia.edu
Rosenberg & Schulzrinne Standards Track [Page 24] RFC 3264 An Offer/Answer Model Session Description Protocol June 2002
ローゼンバーグとSchulzrinne規格は申し出/答えモデルセッション記述プロトコル2002年6月にRFC3264を追跡します[24ページ]。
17. Full Copyright Statement
17. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Rosenberg & Schulzrinne Standards Track [Page 25]
ローゼンバーグとSchulzrinne標準化過程[25ページ]
一覧
スポンサーリンク
