Network Working Group A. Johnston
Request for Comments: 4317 Tello Corporation
Category: Informational R. Sparks
Estacado Systems
December 2005
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).
版权所有（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.
本文档给出了会话描述协议（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
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报价、答案以及在某些情况下交换其他报价和答案的示例。请注意，主题行（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].
此常见场景显示了一个视频和音频会话，其中提供了多个编解码器，但只接受一个编解码器。由于如下所示的交换，Alice和Bob可能只发送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
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
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.
Alice可以支持PCMU、PCMA和iLBC编解码器，但不能同时支持多个。Alice提供了这三个选项，以最大限度地提高成功交换的机会，Bob接受了其中两个选项。在Alice和Bob之间的初始交换中，使用PCMU或PCMA编解码器（RTP数据包中的有效负载类型告诉正在使用的是哪一个）建立一个纯音频会话。由于Alice一次只支持一个音频编解码器，因此第二个选项仅支持该编解码器，以将编解码器的选择限制为一个。
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.
注意：在第二次交换中，两条SDP消息中的版本号都会增加。交换之后，Alice和Bob之间的媒体会话只能使用PCMU编解码器。
Note: The declined video stream still present in the second exchange of SDP with ports set to zero.
注意：在端口设置为零的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 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
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
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
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]
[第二项答覆]
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
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.
Alice提供三个音频和两个视频编解码器，而Bob只提供一个音频和视频编解码器。作为交换的结果，Bob和Alice将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
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
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.
在本例中，Alice希望建立单独的音频流，一个用于正常音频，另一个用于电话事件。Alice提供两个独立的流，一个音频带有两个编解码器，另一个带有RFC 2833[4]音（用于DTMF）。Bob接受选择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
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
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).
Alice和Bob使用单个音频和视频编解码器建立音频和视频会话。在第二次交换中，Bob更改了他的媒体地址，Alice使用与初始交换相同的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
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
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
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]
[第二项答覆]
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
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.
Alice希望使用PCMU编解码器或带有RFC2833音调的iLBC编解码器与Bob建立音频会话，但不能同时使用两者。报价包含这两个媒体流。鲍勃拒绝第一个，接受第二个。如第4.3节所示，如果两个媒体流都被接受，Alice将发送第二个下降的流。
[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
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
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.
Alice和Bob使用单个音频和视频编解码器在第一次交换中建立音频和视频会话。在第二次交换中，Alice添加了第二个视频编解码器，Bob接受。这允许Alice和Bob在两个视频编解码器之间切换，而无需另一个提供/应答交换。
[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
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
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
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]
[第二项答覆]
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
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.
此示例显示了已接受的音频和视频报价，但应答者希望将视频发送到与音频不同的地址。这是会议中的常见场景，其中视频和音频混合使用不同的服务器。在本例中，Alice提供音频和视频，Bob接受。
[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
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
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.
爱丽丝打电话给鲍勃，但鲍勃接电话时，他让爱丽丝等着。然后，鲍勃在第二次报价中让爱丽丝不再犹豫。Alice在第二次交换中更改端口号。在Alice第二次回答后，Alice和Bob之间的媒体会话现在处于活动状态。请注意，a=sendrecv可能同时出现在第二次报价和应答交换中。这是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
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/8000
a=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]
[第二项答覆]
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.atlanta.example.com
t=0 0
m=audio 49178 RTP/AVP 97
a=rtpmap:97 iLBC/8000
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.
在此示例中，在第一次提供/应答交换中建立了两个音频流。在第二次提供/应答交换中，其中一个音频流处于保留状态。Alice提供两个媒体流，一个双向音频流和一个仅发送电话事件流。Bob接受两条流。然后，Bob将Alice的音频流置于保持状态，而不是音调流。Alice以相同的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
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
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
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]
[第二项答覆]
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
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.
在本例中，第一次提供/应答交换使用单个编解码器建立单个音频流。第二个提供/应答交换机为电话事件添加第二个音频流。第二个流由Bob的媒体服务器（不同的连接地址）添加，以从Alice接收RFC 2833电话事件（通常是DTMF数字）。爱丽丝接受了。即使第二个流是单向的，Alice也会在端口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
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
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]
[第二项答覆]
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
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.
在Alice和Bob之间使用PCMU编解码器的初始交换中建立仅音频会话。Alice添加了一个被Bob接受的视频流。
[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.atlanta.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/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 0
a=rtpmap:0 PCMU/8000
m=video 49172 RTP/AVP 31
a=rtpmap:31 H261/90000
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]
[第二项答覆]
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
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.
Alice和Bob建立了一个音频和视频会话。在第二次交换中，Bob删除视频会话，从而生成仅音频会话。
[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
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
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
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]
[第二项答覆]
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
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.
Alice的第一个报价不包含媒体线路，因此Bob接受了没有媒体线路的报价。在第二次交换中，Alice添加了Bob接受的音频流。
[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在IP4 host.atlanta.example.com中2890844526在IP4 host.atlanta.example.com中s=c=t=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在IP4 host.biloxi.example.com中2808844564在IP4 host.biloxi.example.com中s=c=t=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/8000
[Second-Answer]
[第二项答覆]
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.
Alice提供的第一个服务包含连接地址0.0.0.0和一个随机端口号，这意味着Bob无法向Alice发送媒体（媒体流为“黑洞”或“bh”）。Bob接受正常的SDP。在第二次交换中，Alice更改连接地址，Bob接受，并建立媒体会话。
[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/8000
[Second-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
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.
Alice的第一个报价包含音频流，但Bob的答复包含连接地址0.0.0.0和随机端口号，这意味着Alice无法向Bob发送媒体（媒体流为“黑洞”或“bh”）。在第二次交换中，Bob更改连接地址，Alice接受，并建立媒体会话。
[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/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
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]
[第二项答覆]
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/8000
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摘要、证书和加密验证的SIP标识。
[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.和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：会话启动协议”，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 28332000年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）的最佳当前实践”，BCP 85，RFC 37252004年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.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
EMail: ajohnston@tello.com
Robert J. Sparks Estacado Systems
Robert J.Sparks Estacado系统公司
EMail: rjsparks@estacado.net
EMail: rjsparks@estacado.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（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.
本文件受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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。