RFC4317 日本語訳
4317 Session Description Protocol (SDP) Offer/Answer Examples. A.Johnston, R. Sparks. December 2005. (Format: TXT=32262 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Johnston
Request for Comments: 4317 Tello Corporation
Category: Informational R. Sparks
Estacado Systems
December 2005
コメントを求めるワーキンググループA.ジョンストン要求をネットワークでつないでください: 4317年のテーヨ社のCategory: 情報のR.はエスタカードシステム2005年12月にスパークします。
Session Description Protocol (SDP)
Offer/Answer Examples
セッション記述プロトコル(SDP)申し出/答えの例
Status of this Memo
この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)インターネット協会(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.
このドキュメントはSession記述プロトコル(SDP)申し出/答え交換に関する例を出します。 例は、コーデック交渉と選択を含んで、成立して、再開します、そして、メディアの添加と削除は流れます。例はマルチメディアタイプを示しています、双方向です、単方向、不活発な流れ、そして、ダイナミックなペイロードがタイプされます。 また、一般的なThirdパーティCall Control(3pcc)の例は出されます。
Johnston & Sparks Informational [Page 1] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[1ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
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
1. 概観…3 2. コーデック交渉と選択…3 2.1. オーディオとビデオ1…3 2.2. オーディオとビデオ2…4 2.3. オーディオとビデオ3…5 2.4. 2オーディオは流れます…6 2.5. オーディオとビデオ4…7 2.6. オーディオ、1だけ…8 2.7. オーディオとビデオ5…9 2.8. オーディオとビデオ6…10 3. シナリオを保持して、再開してください…12 3.1. 保持とUnhold1…12 3.2. 2つの流れに賛成してください…13 4. メディアの添加と削除は流れます…15 4.1. 加えられた2番目のオーディオストリーム…15 4.2. オーディオ、当時のVideo Added…16 4.3. 削除されたオーディオとビデオ、当時のビデオ…17 5. 第三者呼び出しコントロール(3pcc)…19 5.1. メディアがない、当時のオーディオは加えました…19 5.2. 保持とUnhold2…20 5.3. 保持とUnhold3…21 6. セキュリティ問題…22 7. 有益な参照…22
Johnston & Sparks Informational [Page 2] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[2ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
1. Overview
1. 概観
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].
このドキュメントはRFC3264[1]に基づくSession記述プロトコル(SDP)に関する申し出/答えの例について説明します。 これらの例のSDPはRFC2327[2]によって定義されます。 Session Initiationプロトコル(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.
例は、コーデック交渉と選択を含んで、成立して、再開します、そして、メディアの添加と削除は流れます。例はマルチメディアタイプを示しています、双方向です、単方向、不活発な流れ、そして、ダイナミックなペイロードがタイプされます。 また、一般的なThirdパーティCall Control(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.
以下のセクションは2回のパーティー(アリスとボブ)がいくつかの場合SDP申し出、答え、追加申し出、および答えを交換する例を含みます。 件名(s=)がシングルスペースキャラクタを含むことに注意してください。
2. Codec Negotiation and Selection
2. コーデック交渉と選択
2.1. Audio and Video 1
2.1. オーディオとビデオ1
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
0 0IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com t=mがオーディオの49170RTP/AVPと等しい、0 8、97a=rtpmap、: 0PCMU/8000a=rtpmap: 8PCMA/8000a=rtpmap: 97iLBC/8000mはビデオ51372RTP/AVP31 32a=rtpmap: 31H261/90000 a=rtpmap: 32MPV/90000と等しいです。
Johnston & Sparks Informational [Page 3] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[3ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
[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
INボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com tは0 0m=オーディオの49174RTP/AVP0a=rtpmapと等しいです: 0PCMU/8000mはビデオ49170RTP/AVP32a=rtpmap: 32MPV/90000と等しいです。
2.2. Audio and Video 2
2.2. オーディオとビデオ2
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.
アリスは同時に、1以上ではなく、PCMU、PCMA、およびiLBCコーデックを支持できます。 アリスはうまくいっている交換の機会を最大にするためにすべての3を提供します、そして、ボブはそれらの2つを受け入れます。 オーディオだけセッションはアリスとボブの間の初期の交換に確立されます、PCMUかPCMAコーデックのどちらかを使用して(RTPパケットのペイロードタイプは、どれが使用されているかを言います)。 アリスが一度に1つのオーディオコーデックしか支持しないので、それで2番目の申し出をする、コーデック、コーデック選択をちょうど1つに制限します。
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メッセージで増加されます。 この交換の後に、アリスとボブとのメディアセッションに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
0 0IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com t=mがオーディオの49170RTP/AVPと等しい、0 8、97a=rtpmap、: 0PCMU/8000a=rtpmap: 8PCMA/8000a=rtpmap: 97iLBC/8000mはビデオ51372RTP/AVP31 32a=rtpmap: 31H261/90000 a=rtpmap: 32MPV/90000と等しいです。
Johnston & Sparks Informational [Page 4] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[4ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
[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
INボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com tは0 0m=オーディオの49172RTP/AVP0 8a=rtpmapと等しいです: 0PCMU/8000a=rtpmap: 8PCMA/8000mはビデオ0RTP/AVP31a=rtpmap: 31H261/90000と等しいです。
[Second-Offer]
[第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 51372 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
IN v=0 o=alice2890844526 2890844527IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com tは0 0m=オーディオの51372RTP/AVP0a=rtpmapと等しいです: 0PCMU/8000mはビデオ0RTP/AVP31a=rtpmap: 31H261/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
INボブの2808844564 2808844565IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com tは0 0m=オーディオの49172RTP/AVP0a=rtpmapと等しいです: 0PCMU/8000mはビデオ0RTP/AVP31a=rtpmap: 31H261/90000と等しいです。
2.3. Audio and Video 3
2.3. オーディオとビデオ3
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つのビデオコーデックを提供します、ボブはただ一つのオーディオとビデオコーデックで受け入れますが。この交換の結果、ボブとアリスはオーディオのための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までの変化はOKです。
Johnston & Sparks Informational [Page 5] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[5ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
[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
0 0IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com t=mがオーディオの49170RTP/AVPと等しい、0 8、97a=rtpmap、: 0PCMU/8000a=rtpmap: 8PCMA/8000a=rtpmap: 97iLBC/8000mはビデオ51372RTP/AVP31 32a=rtpmap: 31H261/90000 a=rtpmap: 32MPV/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ボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com tは0 0m=オーディオの49172RTP/AVP99a=rtpmapと等しいです: 99iLBC/8000mはビデオ51374RTP/AVP31a=rtpmap: 31H261/90000と等しいです。
2.4. Two Audio Streams
2.4. 2つのオーディオストリーム
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つのコーデックともう片方と共にRFC2833[4]トーン(DTMFのための)で2つの別々の流れ、1個のオーディオを提供します。 ボブはiLBCコーデックを選ぶオーディオストリームと電話出来事の両方を受け入れます。
Johnston & Sparks Informational [Page 6] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[6ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
[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
0 0IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com t=mがオーディオの49170RTP/AVPと等しい、0、97a=rtpmap、: 0PCMU/8000a=rtpmap: 97iLBC/8000m=オーディオの49172RTP/AVP98a=rtpmap: 98電話出来事/8000a=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
0 0INボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com t=m=オーディオの49172RTP/AVP97a=rtpmap: 97iLBC/8000m=オーディオの49174RTP/AVP98a=rtpmap: 98電話出来事/8000a=recvonly
2.5. Audio and Video 4
2.5. オーディオとビデオ4
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
IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com tは0 0m=オーディオの49170RTP/AVP97a=rtpmapと等しいです: 97iLBC/8000mはビデオ51372RTP/AVP31a=rtpmap: 31H261/90000と等しいです。
Johnston & Sparks Informational [Page 7] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[7ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
[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
INボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com tは0 0m=オーディオの49174RTP/AVP97a=rtpmapと等しいです: 97iLBC/8000mはビデオ49170RTP/AVP31a=rtpmap: 31H261/90000と等しいです。
[Second-Offer]
[第2申し出]
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
INボブの2808844564 2808844565IN v=0o=IP4 host.biloxi.example.com s=c=IP4 newhost.biloxi.example.com tは0 0m=オーディオの49178RTP/AVP97a=rtpmapと等しいです: 97iLBC/8000mはビデオ49188RTP/AVP31a=rtpmap: 31H261/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
IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com tは0 0m=オーディオの49170RTP/AVP97a=rtpmapと等しいです: 97iLBC/8000mはビデオ51372RTP/AVP31a=rtpmap: 31H261/90000と等しいです。
2.6. Audio Only 1
2.6. オーディオ、1だけ
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.
同時に、RFC2833トーンと共にPCMUコーデックかiLBCコーデックのどちらかを使用するボブとのオーディオセッションを確立しますが、アリスはともに確立したがっていません。 申し出はこれらの2つのメディアの流れを含んでいます。ボブは、最初のものを傾けて、2番目のものを受け入れます。 両方のメディア小川を受け入れたなら、アリスは1秒に流れの1つを傾けさせたでしょうに、セクション4.3に示されるように。
Johnston & Sparks Informational [Page 8] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[8ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
[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
IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com tは0 0m=オーディオの49170RTP/AVP0a=rtpmapと等しいです: 0PCMU/8000mがオーディオの51372RTP/AVPと等しい、97、101a=rtpmap、: 97iLBC/8000a=rtpmap: 101電話出来事/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
INボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com tは0 0m=オーディオの0RTP/AVP0a=rtpmapと等しいです: 0PCMU/8000mがオーディオの49170RTP/AVPと等しい、97、101a=rtpmap、: 97iLBC/8000a=rtpmap: 101電話出来事/8000
2.7. Audio and Video 5
2.7. オーディオとビデオ5
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
IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com tは0 0m=オーディオの49170RTP/AVP99a=rtpmapと等しいです: 99iLBC/8000mはビデオ51372RTP/AVP31a=rtpmap: 31H261/90000と等しいです。
Johnston & Sparks Informational [Page 9] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[9ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
[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ボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com tは0 0m=オーディオの49172RTP/AVP99a=rtpmapと等しいです: 99iLBC/8000mはビデオ51374RTP/AVP31a=rtpmap: 31H261/90000と等しいです。
[Second-Offer]
[第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 99
a=rtpmap:99 iLBC/8000
m=video 51372 RTP/AVP 31 32
a=rtpmap:31 H261/90000
a=rtpmap:32 MPV/90000
IN v=0 o=alice2890844526 2890844527IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com tは0 0m=オーディオの49170RTP/AVP99a=rtpmapと等しいです: 99iLBC/8000mはビデオ51372RTP/AVP31 32a=rtpmap: 31H261/90000 a=rtpmap: 32MPV/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
INボブの2808844564 2808844565IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com tは0 0m=オーディオの49172RTP/AVP99a=rtpmapと等しいです: 99iLBC/8000mはビデオ51374RTP/AVP31 32a=rtpmap: 31H261/90000 a=rtpmap: 32MPV/90000と等しいです。
2.8. Audio and Video 6
2.8. オーディオとビデオ6
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.
受け入れられる申し出をオーディオとビデオに示しますが、この例はオーディオのものよりビデオが異なったアドレスに送った必需品をanswererに示しています。 これはビデオとオーディオの混合が異なったサーバを利用する会議で共通したシナリオです。 この例では、アリスはオーディオとビデオを提供します、そして、ボブは受け入れます。
Johnston & Sparks Informational [Page 10] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[10ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
[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
0 0IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com t=mがオーディオの49170RTP/AVPと等しい、0 8、97a=rtpmap、: 0PCMU/8000a=rtpmap: 8PCMA/8000a=rtpmap: 97iLBC/8000mはビデオ51372RTP/AVP31 32a=rtpmap: 31H261/90000 a=rtpmap: 32MPV/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
INボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com tは0 0m=オーディオの49174RTP/AVP0a=rtpmapと等しいです: 0PCMU/8000mがビデオ49172RTP/AVPと等しい、32、c、=IN IP4 otherhost.biloxi.example.com a=rtpmap: 32MPV/90000
Johnston & Sparks Informational [Page 11] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[11ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
3. Hold and Resume Scenarios
3. シナリオを保持して、再開してください。
3.1. Hold and Unhold 1
3.1. 保持とUnhold1
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
0 0IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com t=mがオーディオの49170RTP/AVPと等しい、0、97a=rtpmap、: 0PCMU/8000a=rtpmap: 97iLBC/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
0 0INボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 placeholder.biloxi.example.com t=m=オーディオの49172RTP/AVP97a=rtpmap: 97iLBC/8000a=sendonly
[Second-Offer]
[第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 49170 RTP/AVP 97
a=rtpmap:97 iLBC/8000
0 0INボブの2808844564 2808844565IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com t=m=オーディオの49170RTP/AVP97a=rtpmap: 97iLBC/8000
Johnston & Sparks Informational [Page 12] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[12ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
[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
0 0IN v=0 o=alice2890844526 2890844527IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com t=m=オーディオの49178RTP/AVP97a=rtpmap: 97iLBC/8000
3.2. Hold with Two Streams
3.2. 2つの流れに賛成してください。
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つのメディアの流れ、双方向のオーディオストリーム、およびaを提供する、発信、-単に、電話イベントストリーム。 ボブは両方の流れを受け入れます。次に、ボブはアリスのオーディオストリームをトーンストリームではなく、保持に置きます。 アリスは同じ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
0 0IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com t=mがオーディオの49170RTP/AVPと等しい、0、97a=rtpmap、: 0PCMU/8000a=rtpmap: 97iLBC/8000m=オーディオの49172RTP/AVP98a=rtpmap: 98電話出来事/8000a=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
0 0INボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com t=m=オーディオの49172RTP/AVP97a=rtpmap: 97iLBC/8000m=オーディオの49174RTP/AVP98a=rtpmap: 98電話出来事/8000a=recvonly
Johnston & Sparks Informational [Page 13] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[13ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
[Second-Offer]
[第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
a=sendonly
m=audio 49174 RTP/AVP 98
a=rtpmap:98 telephone-event/8000
a=recvonly
0 0INボブの2808844564 2808844565IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com t=m=オーディオの49172RTP/AVP97a=rtpmap: 97iLBC/8000a=sendonly m=オーディオの49174RTP/AVP98a=rtpmap: 98電話出来事/8000a=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
0 0IN v=0 o=alice2890844526 2890844527IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com t=mがオーディオの49170RTP/AVPと等しい、0、97a=rtpmap、: 0PCMU/8000a=rtpmap: 97iLBC/8000m=オーディオの49172RTP/AVP98a=rtpmap: 98電話出来事/8000a=sendonly
Johnston & Sparks Informational [Page 14] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[14ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
4. Addition and Deletion of Media Streams
4. メディアの流れの添加と削除
This section shows addition and deletion of media streams.
このセクションはメディアの流れの添加と削除を示しています。
4.1. Second Audio Stream Added
4.1. 加えられた2番目のオーディオストリーム
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番目の流れは加えられて、アリスからのRFC2833電話出来事(通常、DTMFケタ)を受けます。 アリスは受け入れます。 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
0 0IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com t=mがオーディオの49170RTP/AVPと等しい、0、97a=rtpmap、: 0PCMU/8000a=rtpmap: 97iLBC/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
0 0INボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com t=m=オーディオの49170RTP/AVP97a=rtpmap: 97iLBC/8000
Johnston & Sparks Informational [Page 15] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[15ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
[Second-Offer]
[第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 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
INボブの2808844564 2808844565IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com tは0 0m=オーディオの49170RTP/AVP97a=rtpmapと等しいです: 97iLBC/8000mがオーディオの48282RTP/AVPと等しい、98、c、=IN IP4 mediaserver.biloxi.example.com a=rtpmap: 98電話出来事/8000a=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
IN v=0 o=alice2890844526 2890844527IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com tは0 0m=オーディオの49170RTP/AVP97a=rtpmapと等しいです: 97iLBC/8000mがオーディオの49172RTP/AVPと等しい、98、c、=IN IP4 host.atlanta.example.com a=rtpmap: 98電話出来事/8000a=sendonly
4.2. Audio, then Video Added
4.2. オーディオ、当時のVideo Added
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
0 0IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com t=m=オーディオの49170RTP/AVP0a=rtpmap: 0PCMU/8000
Johnston & Sparks Informational [Page 16] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[16ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
[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
0 0INボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com t=m=オーディオの49172RTP/AVP0a=rtpmap: 0PCMU/8000
[Second-Offer]
[第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
a=rtpmap:0 PCMU/8000
m=video 49172 RTP/AVP 31
a=rtpmap:31 H261/90000
IN v=0 o=alice2890844526 2890844527IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com tは0 0m=オーディオの49170RTP/AVP0a=rtpmapと等しいです: 0PCMU/8000mはビデオ49172RTP/AVP31a=rtpmap: 31H261/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
INボブの2808844564 2808844565IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com tは0 0m=オーディオの49172RTP/AVP0a=rtpmapと等しいです: 0PCMU/8000mはビデオ49168RTP/AVP31a=rtpmap: 31H261/90000と等しいです。
4.3. Audio and Video, Then Video Deleted
4.3. 削除されたオーディオとビデオ、当時のビデオ
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番目の交換では、オーディオだけセッションのときになって、ボブはビデオセッションを削除します。
Johnston & Sparks Informational [Page 17] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[17ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
[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
IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com tは0 0m=オーディオの49170RTP/AVP97a=rtpmapと等しいです: 97iLBC/8000mはビデオ51372RTP/AVP31a=rtpmap: 31H261/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
INボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com tは0 0m=オーディオの49174RTP/AVP97a=rtpmapと等しいです: 97iLBC/8000mはビデオ49170RTP/AVP31a=rtpmap: 31H261/90000と等しいです。
[Second-Offer]
[第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 49174 RTP/AVP 97
a=rtpmap:97 iLBC/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
INボブの2808844564 2808844565IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com tは0 0m=オーディオの49174RTP/AVP97a=rtpmapと等しいです: 97iLBC/8000mはビデオ0RTP/AVP31a=rtpmap: 31H261/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
IN v=0 o=alice2890844526 2890844527IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com tは0 0m=オーディオの49170RTP/AVP97a=rtpmapと等しいです: 97iLBC/8000mはビデオ0RTP/AVP31a=rtpmap: 31H261/90000と等しいです。
Johnston & Sparks Informational [Page 18] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[18ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
5. Third Party Call Control (3pcc)
5. 第三者呼び出しコントロール(3pcc)
This section shows examples common in Third Party Call Control (3pcc) flows [5]. Call hold and resume flows are also common in 3pcc.
このセクションはThirdパーティCall Control(3pcc)流れ[5]で一般的な例を示しています。 また、呼び出し保持と履歴書流れも3pccで一般的です。
5.1. No Media, Then Audio Added
5.1. メディアがない、加えられた当時のオーディオ
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
IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=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
INボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com tは0 0と等しいです。
[Second-Offer]
[第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
0 0IN v=0 o=alice2890844526 2890844527IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com t=m=オーディオの49170RTP/AVP97a=rtpmap: 97iLBC/8000
[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
0 0INボブの2808844564 2808844565IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com t=m=オーディオの49172RTP/AVP97a=rtpmap: 97iLBC/8000
Johnston & Sparks Informational [Page 19] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[19ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
5.2. Hold and Unhold 2
5.2. 保持とUnhold2
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
0 0c=IN IP4 0.0.0.0v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=t=m=オーディオの23442RTP/AVP97a=rtpmap: 97iLBC/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
0 0INボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com t=m=オーディオの49170RTP/AVP97a=rtpmap: 97iLBC/8000
[Second-Offer]
[第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
0 0IN v=0 o=alice2890844526 2890844527IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com t=m=オーディオの49170RTP/AVP97a=rtpmap: 97iLBC/8000
[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
0 0INボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com t=m=オーディオの49170RTP/AVP97a=rtpmap: 97iLBC/8000
Johnston & Sparks Informational [Page 20] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[20ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
5.3. Hold and Unhold 3
5.3. 保持とUnhold3
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、そして、無作為のポートナンバー。(そのポートナンバーは、アリスがボブ(メディアの流れは、「黒は掘った」か、"bh"である)にメディアを送ることができないことを意味します)。 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
0 0IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com t=m=オーディオの49170RTP/AVP97a=rtpmap: 97iLBC/8000
[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
0 0c=IN IP4 0.0.0.0ボブの2808844564 2808844564IN v=0o=IP4 host.biloxi.example.com s=t=m=オーディオの9322RTP/AVP97a=rtpmap: 97iLBC/8000
[Second-Offer]
[第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
0 0INボブの2808844564 2808844565IN v=0o=IP4 host.biloxi.example.com s=c=IP4 host.biloxi.example.com t=m=オーディオの49172RTP/AVP97a=rtpmap: 97iLBC/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
0 0IN v=0 o=alice2890844526 2890844526IN IP4 host.atlanta.example.com s=c=IP4 host.atlanta.example.com t=m=オーディオの49170RTP/AVP97a=rtpmap: 97iLBC/8000
Johnston & Sparks Informational [Page 21] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[21ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
6. Security Considerations
6. セキュリティ問題
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に関しては、これは、SDPメッセージボディーのTLS輸送、そして/または、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申し出と答えメッセージが適切に認証されて、認可されるのは、重要です。 SIPメカニズムに関する例はSIP Digest、本命、および暗号で確かめられたSIPのアイデンティティを含んでいます。
7. Informative References
7. 有益な参照
[1] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[1] ローゼンバーグとJ.とH.Schulzrinne、「セッション記述プロトコル(SDP)がある申し出/答えモデル」、RFC3264、2002年6月。
[2] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[2] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、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] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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有効搭載量」、RFC2833)は2000がそうするかもしれません。
[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] ローゼンバーグ、J.、ピーターソン、J.、Schulzrinne、H.、およびG.キャマリロ、「セッション開始という第三者呼び出しコントロール(3pcc)のための最も良い現在の実務は(一口)について議定書の中で述べます」、BCP85、RFC3725、2004年4月。
[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.とS.アンダーセン、「インターネットLow Bit Rate Codec(iLBC)スピーチのためのリアルタイムのTransportプロトコル(RTP)有効搭載量Format」、RFC3952、2004年12月。
Johnston & Sparks Informational [Page 22] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[22ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
Authors' Addresses
作者のアドレス
Alan Johnston Tello Corporation 999 Baker Way, Suite 250 San Mateo, CA 94404
サンマテオ、Suite250カリフォルニア アランジョンストンテーヨ社999のベイカーWay、94404
EMail: ajohnston@tello.com
メール: ajohnston@tello.com
Robert J. Sparks Estacado Systems
ロバートJ.はエスタカードシステムをかきたてます。
EMail: rjsparks@estacado.net
メール: rjsparks@estacado.net
Johnston & Sparks Informational [Page 23] RFC 4317 SDP Offer/Answer Examples December 2005
ジョンストンとスパークス情報[23ページ]のRFC4317SDPは例の2005年12月に提供するか、または答えます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Johnston & Sparks Informational [Page 24]
ジョンストンとスパークスInformationalです。[24ページ]
一覧
スポンサーリンク
