[要約] RFC 4317は、SDPオファー/アンサーの例を提供するためのプロトコルであり、SDPセッションの記述と交換を容易にすることを目的としています。
Network Working Group A. Johnston
Request for Comments: 4317 Tello Corporation
Category: Informational R. Sparks
Estacado Systems
December 2005
Session Description Protocol (SDP) Offer/Answer Examples
セッション説明プロトコル（SDP）オファー/回答の例
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
Abstract
概要
This document gives examples of Session Description Protocol (SDP) offer/answer exchanges. Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams, and dynamic payload types. Common Third Party Call Control (3pcc) examples are also given.
このドキュメントには、セッション説明プロトコル（SDP）オファー/回答交換の例を示します。例には、コーデックの交渉と選択、保留と履歴書、メディアストリームの追加と削除が含まれます。この例は、複数のメディアタイプ、双方向、単方向、非アクティブなストリーム、および動的なペイロードタイプを示しています。一般的なサードパーティコールコントロール（3PCC）の例も示しています。
Table of Contents
目次
1. Overview ........................................................3
2. Codec Negotiation and Selection .................................3
2.1. Audio and Video 1 ..........................................3
2.2. Audio and Video 2 ..........................................4
2.3. Audio and Video 3 ..........................................5
2.4. Two Audio Streams ..........................................6
2.5. Audio and Video 4 ..........................................7
2.6. Audio Only 1 ...............................................8
2.7. Audio and Video 5 ..........................................9
2.8. Audio and Video 6 .........................................10
3. Hold and Resume Scenarios ......................................12
3.1. Hold and Unhold 1 .........................................12
3.2. Hold with Two Streams .....................................13
4. Addition and Deletion of Media Streams .........................15
4.1. Second Audio Stream Added .................................15
4.2. Audio, then Video Added ...................................16
4.3. Audio and Video, Then Video Deleted .......................17
5. Third Party Call Control (3pcc) ................................19
5.1. No Media, Then Audio Added ................................19
5.2. Hold and Unhold 2 .........................................20
5.3. Hold and Unhold 3 .........................................21
6. Security Considerations ........................................22
7. Informative References .........................................22
This document describes offer/answer examples of Session Description Protocol (SDP) based on RFC 3264 [1]. The SDP in these examples is defined by RFC 2327 [2]. The offers and answers are assumed to be transported using a protocol such as Session Initiation Protocol (SIP) [3].
このドキュメントでは、RFC 3264 [1]に基づくセッション説明プロトコル（SDP）の提供/回答例について説明します。これらの例のSDPは、RFC 2327 [2]で定義されています。オファーと回答は、セッション開始プロトコル（SIP）[3]などのプロトコルを使用して輸送されると想定されています。
Examples include codec negotiation and selection, hold and resume, and addition and deletion of media streams. The examples show multiple media types, bidirectional, unidirectional, inactive streams, and dynamic payload types. Common Third Party Call Control (3pcc) [5] examples are also given.
例には、コーデックの交渉と選択、保留と履歴書、メディアストリームの追加と削除が含まれます。この例は、複数のメディアタイプ、双方向、単方向、非アクティブなストリーム、および動的なペイロードタイプを示しています。一般的なサードパーティのコールコントロール（3PCC）[5]の例も示されています。
The following sections contain examples in which two parties, Alice and Bob, exchange SDP offers, answers, and, in some cases, additional offers and answers. Note that the subject line (s=) contains a single space character.
次のセクションには、AliceとBob、SDPのオファー、回答、場合によっては追加のオファーと回答を交換する2つの当事者の2つの当事者が含まれています。件名（s =）には単一のスペース文字が含まれていることに注意してください。
This common scenario shows a video and audio session in which multiple codecs are offered but only one is accepted. As a result of the exchange shown below, Alice and Bob may send only PCMU audio and MPV video. Note: Dynamic payload type 97 is used for iLBC codec [6].
この共通のシナリオは、複数のコーデックが提供されますが、1つだけが受け入れられるビデオとオーディオセッションを示しています。以下に示す交換の結果、アリスとボブはPCMUオーディオとMPVビデオのみを送信する場合があります。注：動的ペイロードタイプ97は、ILBCコーデックに使用されます[6]。
[Offer]
[オファー]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
[Answer]
[答え]
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49174 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 49170 RTP/AVP 32
a=rtpmap:32 MPV/90000
Alice can support PCMU, PCMA, and iLBC codecs, but not more than one at the same time. Alice offers all three to maximize chances of a successful exchange, and Bob accepts two of them. An audio-only session is established in the initial exchange between Alice and Bob, using either PCMU or PCMA codecs (payload type in RTP packet tells which is being used). Since Alice only supports one audio codec at a time, a second offer is made with just that one codec, to limit the codec choice to just one.
アリスはPCMU、PCMA、およびILBCコーデックをサポートできますが、同時に1つ以下ではありません。アリスは3つすべてを提供して、成功した交換の可能性を最大化し、ボブはそのうちの2つを受け入れます。AliceとBobの最初の交換で、PCMUまたはPCMAコーデックのいずれかを使用して、オーディオのみのセッションが確立されます（RTPパケットのペイロードタイプは、どちらが使用されているかを示します）。アリスは一度に1つのオーディオコーデックのみをサポートしているため、コーデックの選択を1つだけに制限するために、1つのコーデックで2番目のオファーが行われます。
Note: the version number is incremented in both SDP messages in the second exchange. After this exchange, only the PCMU codec may be used for media session between Alice and Bob.
注：バージョン番号は、2回目の交換で両方のSDPメッセージで増加します。この交換の後、AliceとBobの間のメディアセッションにはPCMUコーデックのみが使用できます。
Note: The declined video stream still present in the second exchange of SDP with ports set to zero.
注：SDPの2回目の交換では、ポートがゼロに設定された断られたビデオストリームはまだ存在します。
[Offer]
[オファー]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
[Answer]
[答え]
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49172 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
[Second-Offer]
[セカンドオブファー]
v=0
o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
[Second-Answer]
[2番目の回答]
v=0
o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
Alice offers three audio and two video codecs, while Bob accepts with a single audio and video codec. As a result of this exchange, Bob and Alice use iLBC for audio and H261 for video.
アリスは3つのオーディオと2つのビデオコーデックを提供し、ボブは1つのオーディオとビデオコーデックで受け入れます。この交換の結果、ボブとアリスはオーディオにILBCを使用し、ビデオにはH261を使用します。
Note: change of dynamic payload type from 97 to 99 between the offer and the answer is OK since the same codec is referenced.
注：同じコーデックが参照されるため、オファーの間に動的なペイロードタイプの変更は97から99に変更されます。回答は問題ありません。
[Offer]
[オファー]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
[Answer]
[答え]
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49172 RTP/AVP 99
a=rtpmap:99 iLBC/8000
m=video 51374 RTP/AVP 31
a=rtpmap:31 H261/90000
In this example, Alice wishes to establish separate audio streams, one for normal audio and the other for telephone-events. Alice offers two separate streams, one audio with two codecs and the other with RFC 2833 [4] tones (for DTMF). Bob accepts both audio streams choosing the iLBC codec and telephone-events.
この例では、アリスは、通常のオーディオ用に、もう1つは電話イベント用の個別のオーディオストリームを確立したいと考えています。アリスは2つの別々のストリームを提供します。1つは2つのコーデックを備えたオーディオ、もう1つはRFC 2833 [4]トーン（DTMF用）を備えています。ボブは、ILBCコーデックと電話イベントを選択するオーディオストリームの両方を受け入れます。
[Offer]
[オファー]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 97
a=rtpmap:0 PCMU/8000
a=rtpmap:97 iLBC/8000
m=audio 49172 RTP/AVP 98
a=rtpmap:98 telephone-event/8000
a=sendonly
[Answer]
[答え]
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49172 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=audio 49174 RTP/AVP 98
a=rtpmap:98 telephone-event/8000
a=recvonly
Alice and Bob establish an audio and video session with a single audio and video codec. In a second exchange, Bob changes his address for media and Alice accepts with the same SDP as the initial exchange (and as a result does not increment the version number).
アリスとボブは、単一のオーディオとビデオコーデックでオーディオとビデオセッションを確立します。2回目の交換では、ボブはメディアの住所を変更し、アリスは最初の交換と同じSDPで受け入れます（その結果、バージョン番号は増加しません）。
[Offer]
[オファー]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
[Answer]
[答え]
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49174 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 49170 RTP/AVP 31
a=rtpmap:31 H261/90000
[Second-Offer]
[セカンドオブファー]
v=0
o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
s=
c=IN IP4 newhost.biloxi.example.com
t=0 0
m=audio 49178 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 49188 RTP/AVP 31
a=rtpmap:31 H261/90000
[Second-Answer]
[2番目の回答]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
Alice wishes to establish an audio session with Bob using either PCMU codec or iLBC codec with RFC2833 tones, but not both at the same time. The offer contains these two media streams. Bob declines the first one and accepts the second one. If both media streams had been accepted, Alice would have sent a second declining one of the streams, as shown in Section 4.3.
アリスは、PCMUコーデックまたはRFC2833トーンを使用してILBCコーデックのいずれかを使用してボブとオーディオセッションを確立したいと考えていますが、両方と同時にはそうではありません。このオファーには、これら2つのメディアストリームが含まれています。ボブは最初のものを辞退し、2番目のものを受け入れます。セクション4.3に示すように、両方のメディアストリームが受け入れられていた場合、アリスはストリームの1つを2番目の衰退させて送信していました。
[Offer]
[オファー]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=audio 51372 RTP/AVP 97 101
a=rtpmap:97 iLBC/8000
a=rtpmap:101 telephone-event/8000
[Answer]
[答え]
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 0 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=audio 49170 RTP/AVP 97 101
a=rtpmap:97 iLBC/8000
a=rtpmap:101 telephone-event/8000
Alice and Bob establish an audio and video session in the first exchange with a single audio and video codec. In the second exchange, Alice adds a second video codec, which Bob accepts. This allows Alice and Bob to switch between the two video codecs without another offer/answer exchange.
アリスとボブは、単一のオーディオとビデオコーデックとの最初の交換でオーディオとビデオセッションを確立します。2回目の交換では、アリスは2番目のビデオコーデックを追加します。ボブは受け入れます。これにより、アリスとボブは、別のオファー/回答交換なしで2つのビデオコーデックを切り替えることができます。
[Offer]
[オファー]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 99
a=rtpmap:99 iLBC/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
[Answer]
[答え]
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49172 RTP/AVP 99
a=rtpmap:99 iLBC/8000
m=video 51374 RTP/AVP 31
a=rtpmap:31 H261/90000
[Second-Offer]
[セカンドオブファー]
v=0
o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 99
a=rtpmap:99 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
[Second-Answer]
[2番目の回答]
v=0
o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49172 RTP/AVP 99
a=rtpmap:99 iLBC/8000
m=video 51374 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
This example shows an audio and video offer that is accepted, but the answerer wants the video sent to a different address than that of the audio. This is a common scenario in conferencing where the video and audio mixing utilizes different servers. In this example, Alice offers audio and video, and Bob accepts.
この例は、受け入れられているオーディオとビデオのオファーを示していますが、回答者はビデオをオーディオのアドレスとは異なるアドレスに送信したいと考えています。これは、ビデオとオーディオミキシングがさまざまなサーバーを利用する会議の一般的なシナリオです。この例では、アリスはオーディオとビデオを提供し、ボブは受け入れます。
[Offer]
[オファー]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
[Answer]
[答え]
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49174 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 49172 RTP/AVP 32
c=IN IP4 otherhost.biloxi.example.com
a=rtpmap:32 MPV/90000
Alice calls Bob, but when Bob answers he places Alice on hold. Bob then takes Alice off hold in the second offer. Alice changes port number in the second exchange. The media session between Alice and Bob is now active after Alice's second answer. Note that a=sendrecv could be present in both second offer and answer exchange. This is a common flow in 3pcc [5] scenarios.
アリスはボブに電話しますが、ボブが答えたとき、彼はアリスを保留にします。その後、ボブは2回目のオファーでアリスをホールドオフにします。アリスは2回目の交換でポート番号を変更します。アリスとボブの間のメディアセッションは、アリスの2番目の答えの後、現在アクティブになっています。a = sendrecvは、2回目のオファーと回答の両方の交換の両方に存在する可能性があることに注意してください。これは、3PCC [5]シナリオの一般的なフローです。
[Offer]
[オファー]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 97
a=rtpmap:0 PCMU/8000
a=rtpmap:97 iLBC/8000
[Answer]
[答え]
v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com s= c=IN IP4 placeholder.biloxi.example.com t=0 0 m=audio 49172 RTP/AVP 97 a=rtpmap:97 iLBC/8000 a=sendonly
V = 0 O = BOB 2808844564 2808844564 IN IP4 HOST.BILOXI.EXAMPLE.COM S = C = IN IP4 PLACEHOLDER.BILOXI.EXAMPLE.COM T = 0 0 M = Audio 49172 RTP/AVP 97 A = RTPMAP：97 ILBC/8000a = sendonly
[Second-Offer]
[セカンドオブファー]
v=0 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com s= c=IN IP4 host.biloxi.example.com t=0 0 m=audio 49170 RTP/AVP 97 a=rtpmap:97 iLBC/8000
V = 0 O = BOB 2808844564 2808844565 IN IP4 host.biloxi.example.com s = c = in ip4 host.biloxi.example.com t = 0 0 m = audio 49170 rtp/avp 97 a = rtpmap：97 ilbc/8000
[Second-Answer]
[2番目の回答]
v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49178 RTP/AVP 97 a=rtpmap:97 iLBC/8000
V = 0 O = Alice 2890844526 2890844527 in ip4 host.atlanta.example.com s = c = in ip4 host.atlant.example.com t = 0 0 m = audio 49178 rtp/avp 97 a = rtpmap：97 ilbc/8000000000000
In this example, two audio streams have been established in the first offer/answer exchange. In this second offer/answer exchange, one of the audio streams is placed on hold. Alice offers two media streams, a bidirectional audio stream and a send-only telephone event stream. Bob accepts both streams. Bob then puts Alice's audio stream on hold but not the tone stream. Alice responds with identical SDP to the initial offer.
この例では、最初のオファー/回答交換で2つのオーディオストリームが確立されました。この2番目のオファー/回答交換では、オーディオストリームの1つが保留されています。アリスは、2つのメディアストリーム、双方向のオーディオストリームと送信専用の電話イベントストリームを提供しています。ボブは両方のストリームを受け入れます。ボブはその後、アリスのオーディオストリームを保留にしますが、トーンストリームは保留しません。アリスは、最初のオファーに同一のSDPで応答します。
[Offer]
[オファー]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 97
a=rtpmap:0 PCMU/8000
a=rtpmap:97 iLBC/8000
m=audio 49172 RTP/AVP 98
a=rtpmap:98 telephone-event/8000
a=sendonly
[Answer]
[答え]
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49172 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=audio 49174 RTP/AVP 98
a=rtpmap:98 telephone-event/8000
a=recvonly
[Second-Offer]
[セカンドオブファー]
v=0
o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49172 RTP/AVP 97
a=rtpmap:97 iLBC/8000
a=sendonly
m=audio 49174 RTP/AVP 98
a=rtpmap:98 telephone-event/8000
a=recvonly
[Second-Answer]
[2番目の回答]
v=0
o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 97
a=rtpmap:0 PCMU/8000
a=rtpmap:97 iLBC/8000
m=audio 49172 RTP/AVP 98
a=rtpmap:98 telephone-event/8000
a=sendonly
This section shows addition and deletion of media streams.
このセクションでは、メディアストリームの追加と削除を示しています。
In this example, the first offer/answer exchange establishes a single audio stream with a single codec. The second offer/answer exchange adds a second audio stream for telephone events. The second stream is added by Bob's media server (different connection address) to receive RFC 2833 telephone-events (DTMF digits, typically) from Alice. Alice accepts. Even though the second stream is unidirectional, Alice receives RTCP packets on port 49173 from the media server.
この例では、最初のオファー/回答交換は、単一のコーデックを備えた単一のオーディオストリームを確立します。2番目のオファー/回答交換は、電話イベントに2番目のオーディオストリームを追加します。2番目のストリームは、AliceからRFC 2833電話イベント（通常はDTMF桁）を受信するために、Bobのメディアサーバー（異なる接続アドレス）によって追加されます。アリスは受け入れます。2番目のストリームは単方向ですが、アリスはメディアサーバーからポート49173でRTCPパケットを受け取ります。
[Offer]
[オファー]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0 97
a=rtpmap:0 PCMU/8000
a=rtpmap:97 iLBC/8000
[Answer]
[答え]
v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com s= c=IN IP4 host.biloxi.example.com t=0 0 m=audio 49170 RTP/AVP 97 a=rtpmap:97 iLBC/8000
V = 0 O = BOB 2808844564 2808844564 IN IP4 host.biloxi.example.com s = c = in ip4 host.biloxi.example.com t = 0 0 m = audio 49170 rtp/avp 97 a = rtpmap：97 ilbc/8000
[Second-Offer]
[セカンドオブファー]
v=0
o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=audio 48282 RTP/AVP 98
c=IN IP4 mediaserver.biloxi.example.com
a=rtpmap:98 telephone-event/8000
a=recvonly
[Second-Answer]
[2番目の回答]
v=0
o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=audio 49172 RTP/AVP 98
c=IN IP4 host.atlanta.example.com
a=rtpmap:98 telephone-event/8000
a=sendonly
An audio-only session is established in the initial exchange between Alice and Bob using PCMU codec. Alice adds a video stream that is accepted by Bob.
PCMUコーデックを使用して、アリスとボブの間の最初の交換でオーディオのみのセッションが確立されます。アリスは、ボブが受け入れたビデオストリームを追加します。
[Offer]
[オファー]
v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000
V = 0 O = Alice 2890844526 2890844526 in ip4 host.atlanta.example.com s = c = in ip4 host.atlant.example.com t = 0 0 m = audio 49170 rtp/avp 0 a = rtpmap：0 pcmu/8000
[Answer]
[答え]
v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com s= c=IN IP4 host.biloxi.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000
V = 0 O = BOB 2808844564 2808844564 IN IP4 host.biloxi.example.com s = c = in ip4 host.biloxi.example.com t = 0 0 m = audio 49172 rtp/avp 0 a = rtpmap：0 pcmu/8000000000000000000000
[Second-Offer]
[セカンドオブファー]
v=0
o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 49172 RTP/AVP 31
a=rtpmap:31 H261/90000
[Second-Answer]
[2番目の回答]
v=0
o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 49168 RTP/AVP 31
a=rtpmap:31 H261/90000
Alice and Bob establish an audio and video session. In a second exchange, Bob deletes the video session, resulting in an audio-only session.
アリスとボブはオーディオとビデオセッションを確立します。2回目の交換では、ボブはビデオセッションを削除し、オーディオのみのセッションになります。
[Offer]
[オファー]
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
[Answer]
[答え]
v=0
o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49174 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 49170 RTP/AVP 31
a=rtpmap:31 H261/90000
[Second-Offer]
[セカンドオブファー]
v=0
o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com
s=
c=IN IP4 host.biloxi.example.com
t=0 0
m=audio 49174 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
[Second-Answer]
[2番目の回答]
v=0
o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=audio 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
This section shows examples common in Third Party Call Control (3pcc) flows [5]. Call hold and resume flows are also common in 3pcc.
このセクションでは、サードパーティのコールコントロール（3PCC）フロー[5]で一般的な例を示しています。3PCCでは、コールホールドおよび履歴書のフローも一般的です。
The first offer from Alice contains no media lines, so Bob accepts with no media lines. In the second exchange, Alice adds an audio stream that Bob accepts.
アリスからの最初のオファーにはメディアラインが含まれていないため、ボブはメディアラインなしで受け入れます。2回目の交換で、アリスはボブが受け入れるオーディオストリームを追加します。
[Offer]
[オファー]
v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0
v = 0 o = Alice 2890844526 2890844526 in ip4 host.atlanta.example.com s = c = in ip4 host.atlanta.example.com t = 0 0
[Answer]
[答え]
v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com s= c=IN IP4 host.biloxi.example.com t=0 0
v = 0 o = bob 2808844564 2808844564 in ip4 host.biloxi.example.com s = c = in ip4 host.biloxi.example.com t = 0 0
[Second-Offer]
[セカンドオブファー]
v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 97 a=rtpmap:97 iLBC/8000
V = 0 O = Alice 2890844526 2890844527 in ip4 host.atlanta.example.com s = c = in ip4 host.atlanta.example.com t = 0 0 m = audio 49170 rtp/avp 97 a = rtpmap：97 ilbc/8000000000000000
[Second-Answer]
[2番目の回答]
v=0 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com s= c=IN IP4 host.biloxi.example.com t=0 0 m=audio 49172 RTP/AVP 97 a=rtpmap:97 iLBC/8000
V = 0 O = BOB 2808844564 2808844565 IN IP4 HOST.BILOXI.EXAMPLE.COM S = C = IN IP4 HOST.BILOXI.EXAMPLE.COM T = 0 0 M = Audio 49172 RTP/AVP 97 A = RTPMAP：97 ILBC/8000
The first offer from Alice contains the connection address 0.0.0.0 and a random port number, which means that Bob can not send media to Alice (the media stream is "black holed" or "bh"). Bob accepts with normal SDP. In the second exchange, Alice changes the connection address, Bob accepts, and a media session is established.
アリスからの最初のオファーには、接続アドレス0.0.0.0とランダムなポート番号が含まれています。つまり、ボブはメディアをアリスに送ることができません（メディアストリームは「ブラックホール」または「BH」です）。ボブは通常のSDPで受け入れます。2回目の交換では、アリスは接続アドレスを変更し、ボブは受け入れ、メディアセッションが確立されます。
[Offer]
[オファー]
v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 0.0.0.0 t=0 0 m=audio 23442 RTP/AVP 97 a=rtpmap:97 iLBC/8000
V = 0 O = Alice 2890844526 2890844526 in ip4 host.atlanta.example.com s = c = in ip4 0.0.0.0 t = 0 0 m = audio 23442 rtp/avp 97 a = rtpmap：97 ILBC/8000
[Answer]
[答え]
v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com s= c=IN IP4 host.biloxi.example.com t=0 0 m=audio 49170 RTP/AVP 97 a=rtpmap:97 iLBC/8000
V = 0 O = BOB 2808844564 2808844564 IN IP4 host.biloxi.example.com s = c = in ip4 host.biloxi.example.com t = 0 0 m = audio 49170 rtp/avp 97 a = rtpmap：97 ilbc/8000
[Second-Offer]
[セカンドオブファー]
v=0 o=alice 2890844526 2890844527 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 97 a=rtpmap:97 iLBC/8000
V = 0 O = Alice 2890844526 2890844527 in ip4 host.atlanta.example.com s = c = in ip4 host.atlanta.example.com t = 0 0 m = audio 49170 rtp/avp 97 a = rtpmap：97 ilbc/8000000000000000
[Second-Answer]
[2番目の回答]
v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com s= c=IN IP4 host.biloxi.example.com t=0 0 m=audio 49170 RTP/AVP 97 a=rtpmap:97 iLBC/8000
V = 0 O = BOB 2808844564 2808844564 IN IP4 host.biloxi.example.com s = c = in ip4 host.biloxi.example.com t = 0 0 m = audio 49170 rtp/avp 97 a = rtpmap：97 ilbc/8000
The first offer from Alice contains an audio stream, but the answer from Bob contains the connection address 0.0.0.0 and a random port number, which means that Alice can not send media to Bob (the media stream is "black holed" or "bh"). In the second exchange, Bob changes the connection address, Alice accepts, and a media session is established.
アリスからの最初のオファーにはオーディオストリームが含まれていますが、ボブからの答えには接続アドレス0.0.0.0とランダムなポート番号が含まれています。"）。2回目の交換では、ボブは接続アドレスを変更し、アリスは受け入れ、メディアセッションが確立されます。
[Offer]
[オファー]
v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 97 a=rtpmap:97 iLBC/8000
V = 0 O = Alice 2890844526 2890844526 in ip4 host.atlanta.example.com s = c = in ip4 host.atlanta.example.com t = 0 0 m = audio 49170 rtp/avp 97 a = rtpmap：97 ilbc/8000000000000000
[Answer]
[答え]
v=0 o=bob 2808844564 2808844564 IN IP4 host.biloxi.example.com s= c=IN IP4 0.0.0.0 t=0 0 m=audio 9322 RTP/AVP 97 a=rtpmap:97 iLBC/8000
V = 0 O = BOB 2808844564 2808844564 IN IP4 HOST.BILOXI.EXAMPLE.COM S = C = IN IP4 0.0.0.0 T = 0 0 M = Audio 9322 RTP/AVP 97 A = RTPMAP：97 ILBC/8000
[Second-Offer]
[セカンドオブファー]
v=0 o=bob 2808844564 2808844565 IN IP4 host.biloxi.example.com s= c=IN IP4 host.biloxi.example.com t=0 0 m=audio 49172 RTP/AVP 97 a=rtpmap:97 iLBC/8000
V = 0 O = BOB 2808844564 2808844565 IN IP4 HOST.BILOXI.EXAMPLE.COM S = C = IN IP4 HOST.BILOXI.EXAMPLE.COM T = 0 0 M = Audio 49172 RTP/AVP 97 A = RTPMAP：97 ILBC/8000
[Second-Answer]
[2番目の回答]
v=0 o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com s= c=IN IP4 host.atlanta.example.com t=0 0 m=audio 49170 RTP/AVP 97 a=rtpmap:97 iLBC/8000
V = 0 O = Alice 2890844526 2890844526 in ip4 host.atlanta.example.com s = c = in ip4 host.atlanta.example.com t = 0 0 m = audio 49170 rtp/avp 97 a = rtpmap：97 ilbc/8000000000000000
SDP offer and answer messages can contain private information about addresses and sessions to be established between parties. If this information needs to be kept private, some security mechanism in the protocol used to carry the offers and answers must be used. For SIP, this means using TLS transport and/or S/MIME encryption of the SDP message body.
SDPの提供および回答メッセージには、当事者間で確立される住所とセッションに関する個人情報を含めることができます。この情報をプライベートに保つ必要がある場合は、オファーを運ぶために使用されるプロトコルのセキュリティメカニズムと回答を使用する必要があります。SIPの場合、これはTLS輸送および/またはSDPメッセージ本文のS/MIME暗号化を使用することを意味します。
It is important that SDP offer and answer messages be properly authenticated and authorized before they are used to establish a media session. Examples of SIP mechanisms include SIP Digest, certs, and cryptographically-verified SIP identity.
SDPは、メディアセッションを確立するために使用される前に、SDPの提供と回答メッセージを適切に認証および承認することが重要です。SIPメカニズムの例には、SIPダイジェスト、証明書、暗号化されたSIP IDが含まれます。
[1] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[1] Rosenberg、J。およびH. Schulzrinne、「セッション説明プロトコル（SDP）を備えたオファー/回答モデル」、RFC 3264、2002年6月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[2] Handley、M。and V. Jacobson、「SDP：セッション説明プロトコル」、RFC 2327、1998年4月。
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[3] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[4] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[4] Schulzrinne、H。およびS. Petrack、「DTMFディジット、テレフォニートーン、テレフォニーシグナルのRTPペイロード」、RFC 2833、2000年5月。
[5] Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo, "Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP)", BCP 85, RFC 3725, April 2004.
[5] Rosenberg、J.、Peterson、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）における第三者コールコントロール（3PCC）の最良の現在のプラクティス」、2004年4月、RFC 3725、RFC 3725。
[6] Duric, A. and S. Andersen, "Real-time Transport Protocol (RTP) Payload Format for internet Low Bit Rate Codec (iLBC) Speech", RFC 3952, December 2004.
[6] Duric、A。and S. Andersen、「インターネットの低ビットレートコーデック（ILBC）スピーチのリアルタイムトランスポートプロトコル（RTP）ペイロード形式」、RFC 3952、2004年12月。
Authors' Addresses
著者のアドレス
Alan Johnston Tello Corporation 999 Baker Way, Suite 250 San Mateo, CA 94404
アランジョンストンテロコーポレーション999ベイカーウェイ、スイート250サンマテオ、カリフォルニア94404
EMail: ajohnston@tello.com
Robert J. Sparks Estacado Systems
ロバート・J・スパークス・エスタカド・システム
EMail: rjsparks@estacado.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
Copyright（c）The Internet Society（2005）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。