Network Working Group J. Rosenberg
Request for Comments: 3264 dynamicsoft
Obsoletes: 2543 H. Schulzrinne
Category: Standards Track Columbia U.
June 2002
Network Working Group J. Rosenberg
Request for Comments: 3264 dynamicsoft
Obsoletes: 2543 H. Schulzrinne
Category: Standards Track Columbia U.
June 2002
An Offer/Answer Model with the Session Description Protocol (SDP)
具有会话描述协议（SDP）的提供/应答模型
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document defines a mechanism by which two entities can make use of the Session Description Protocol (SDP) to arrive at a common view of a multimedia session between them. In the model, one participant offers the other a description of the desired session from their perspective, and the other participant answers with the desired session from their perspective. This offer/answer model is most useful in unicast sessions where information from both participants is needed for the complete view of the session. The offer/answer model is used by protocols like the Session Initiation Protocol (SIP).
本文档定义了一种机制，通过该机制，两个实体可以使用会话描述协议（SDP）来获得它们之间多媒体会话的共同视图。在模型中，一个参与者从他们的角度向另一个参与者提供所需会话的描述，另一个参与者从他们的角度回答所需会话。此提供/应答模型在单播会话中最有用，在单播会话中，完整查看会话需要来自两个参与者的信息。提供/应答模型由会话发起协议（SIP）等协议使用。
Table of Contents
目录
1 Introduction ........................................ 2
2 Terminology ......................................... 3
3 Definitions ......................................... 3
4 Protocol Operation .................................. 4
5 Generating the Initial Offer ........................ 5
5.1 Unicast Streams ..................................... 5
5.2 Multicast Streams ................................... 8
6 Generating the Answer ............................... 9
6.1 Unicast Streams ..................................... 9
6.2 Multicast Streams ................................... 12
7 Offerer Processing of the Answer .................... 12
8 Modifying the Session ............................... 13
1 Introduction ........................................ 2
2 Terminology ......................................... 3
3 Definitions ......................................... 3
4 Protocol Operation .................................. 4
5 Generating the Initial Offer ........................ 5
5.1 Unicast Streams ..................................... 5
5.2 Multicast Streams ................................... 8
6 Generating the Answer ............................... 9
6.1 Unicast Streams ..................................... 9
6.2 Multicast Streams ................................... 12
7 Offerer Processing of the Answer .................... 12
8 Modifying the Session ............................... 13
8.1 Adding a Media Stream ............................... 13
8.2 Removing a Media Stream ............................. 14
8.3 Modifying a Media Stream ............................ 14
8.3.1 Modifying Address, Port or Transport ................ 14
8.3.2 Changing the Set of Media Formats ................... 15
8.3.3 Changing Media Types ................................ 17
8.3.4 Changing Attributes ................................. 17
8.4 Putting a Unicast Media Stream on Hold .............. 17
9 Indicating Capabilities ............................. 18
10 Example Offer/Answer Exchanges ...................... 19
10.1 Basic Exchange ...................................... 19
10.2 One of N Codec Selection ............................ 21
11 Security Considerations ............................. 23
12 IANA Considerations ................................. 23
13 Acknowledgements .................................... 23
14 Normative References ................................ 23
15 Informative References .............................. 24
16 Authors' Addresses .................................. 24
17 Full Copyright Statement............................. 25
8.1 Adding a Media Stream ............................... 13
8.2 Removing a Media Stream ............................. 14
8.3 Modifying a Media Stream ............................ 14
8.3.1 Modifying Address, Port or Transport ................ 14
8.3.2 Changing the Set of Media Formats ................... 15
8.3.3 Changing Media Types ................................ 17
8.3.4 Changing Attributes ................................. 17
8.4 Putting a Unicast Media Stream on Hold .............. 17
9 Indicating Capabilities ............................. 18
10 Example Offer/Answer Exchanges ...................... 19
10.1 Basic Exchange ...................................... 19
10.2 One of N Codec Selection ............................ 21
11 Security Considerations ............................. 23
12 IANA Considerations ................................. 23
13 Acknowledgements .................................... 23
14 Normative References ................................ 23
15 Informative References .............................. 24
16 Authors' Addresses .................................. 24
17 Full Copyright Statement............................. 25
1 Introduction
1导言
The Session Description Protocol (SDP) [1] was originally conceived as a way to describe multicast sessions carried on the Mbone. The Session Announcement Protocol (SAP) [6] was devised as a multicast mechanism to carry SDP messages. Although the SDP specification allows for unicast operation, it is not complete. Unlike multicast, where there is a global view of the session that is used by all participants, unicast sessions involve two participants, and a complete view of the session requires information from both participants, and agreement on parameters between them.
会话描述协议（SDP）[1]最初被认为是描述Mbone上进行的多播会话的一种方式。会话公告协议（SAP）[6]被设计为一种多播机制来承载SDP消息。虽然SDP规范允许单播操作，但它并不完整。与所有参与者都使用会话的全局视图的多播不同，单播会话涉及两个参与者，而会话的完整视图需要两个参与者提供信息，并在他们之间就参数达成一致。
As an example, a multicast session requires conveying a single multicast address for a particular media stream. However, for a unicast session, two addresses are needed - one for each participant. As another example, a multicast session requires an indication of which codecs will be used in the session. However, for unicast, the set of codecs needs to be determined by finding an overlap in the set supported by each participant.
例如，多播会话要求传输特定媒体流的单个多播地址。但是，对于单播会话，需要两个地址-每个参与者一个。作为另一个示例，多播会话需要指示会话中将使用哪些编解码器。但是，对于单播，需要通过查找每个参与者支持的集合中的重叠来确定编解码器集合。
As a result, even though SDP has the expressiveness to describe unicast sessions, it is missing the semantics and operational details of how it is actually done. In this document, we remedy that by defining a simple offer/answer model based on SDP. In this model, one participant in the session generates an SDP message that constitutes the offer - the set of media streams and codecs the offerer wishes to use, along with the IP addresses and ports the offerer would like to use to receive the media. The offer is
因此，尽管SDP具有描述单播会话的表达能力，但它缺少实际操作方式的语义和操作细节。在本文中，我们通过定义一个基于SDP的简单报价/应答模型来弥补这一缺陷。在该模型中，会话中的一个参与者生成一条SDP消息，该消息构成要约——要约人希望使用的一组媒体流和编解码器，以及要约人希望用于接收媒体的IP地址和端口。报价是
conveyed to the other participant, called the answerer. The answerer generates an answer, which is an SDP message that responds to the offer provided by the offerer. The answer has a matching media stream for each stream in the offer, indicating whether the stream is accepted or not, along with the codecs that will be used and the IP addresses and ports that the answerer wants to use to receive media.
传达给另一名被称为回答者的参与者。应答者生成一个应答，该应答是一条SDP消息，用于响应报价人提供的报价。回答中的每个流都有一个匹配的媒体流，指示是否接受该流，以及将使用的编解码器以及回答者希望用于接收媒体的IP地址和端口。
It is also possible for a multicast session to work similar to a unicast one; its parameters are negotiated between a pair of users as in the unicast case, but both sides send packets to the same multicast address, rather than unicast ones. This document also discusses the application of the offer/answer model to multicast streams.
多播会话也可以类似于单播会话工作；它的参数在一对用户之间协商，就像单播情况一样，但双方都将数据包发送到相同的多播地址，而不是单播地址。本文档还讨论了提供/应答模型在多播流中的应用。
We also define guidelines for how the offer/answer model is used to update a session after an initial offer/answer exchange.
我们还定义了在初始报价/应答交换后如何使用报价/应答模型更新会话的准则。
The means by which the offers and answers are conveyed are outside the scope of this document. The offer/answer model defined here is the mandatory baseline mechanism used by the Session Initiation Protocol (SIP) [7].
报价和答复的传达方式不在本文件范围内。此处定义的提供/应答模型是会话启动协议（SIP）[7]使用的强制性基线机制。
2 Terminology
2术语
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”将按照RFC 2119[2]中的描述进行解释，并表示符合性实施的要求级别。
3 Definitions
3定义
The following terms are used throughout this document:
本文件中使用了以下术语：
Agent: An agent is the protocol implementation involved in the offer/answer exchange. There are two agents involved in an offer/answer exchange.
代理：代理是参与提供/应答交换的协议实现。有两个代理参与报价/应答交换。
Answer: An SDP message sent by an answerer in response to an offer received from an offerer.
答：应答者发送的SDP消息，用于响应从报价人处收到的报价。
Answerer: An agent which receives a session description from another agent describing aspects of desired media communication, and then responds to that with its own session description.
应答者：从另一个代理接收会话描述，描述所需媒体通信的各个方面，然后用自己的会话描述对其作出响应的代理。
Media Stream: From RTSP [8], a media stream is a single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. In SDP, a media stream is described by an "m=" line and its associated attributes.
媒体流：从RTSP[8]，媒体流是单个媒体实例，例如音频流或视频流以及单个白板或共享应用程序组。在SDP中，媒体流由“m=”行及其相关属性描述。
Offer: An SDP message sent by an offerer.
要约：要约人发送的SDP消息。
Offerer: An agent which generates a session description in order to create or modify a session.
报价人：生成会话描述以创建或修改会话的代理。
4 Protocol Operation
4协议操作
The offer/answer exchange assumes the existence of a higher layer protocol (such as SIP) which is capable of exchanging SDP for the purposes of session establishment between agents.
提供/应答交换假定存在更高层协议（如SIP），该协议能够交换SDP以在代理之间建立会话。
Protocol operation begins when one agent sends an initial offer to another agent. An offer is initial if it is outside of any context that may have already been established through the higher layer protocol. It is assumed that the higher layer protocol provides maintenance of some kind of context which allows the various SDP exchanges to be associated together.
当一个代理向另一个代理发送初始报价时，协议操作开始。如果要约不在可能已经通过高层协议建立的任何上下文范围内，则该要约为初始要约。假定高层协议提供某种上下文的维护，从而允许将各种SDP交换关联在一起。
The agent receiving the offer MAY generate an answer, or it MAY reject the offer. The means for rejecting an offer are dependent on the higher layer protocol. The offer/answer exchange is atomic; if the answer is rejected, the session reverts to the state prior to the offer (which may be absence of a session).
接受要约的代理可以生成答复，也可以拒绝要约。拒绝报价的方式取决于高层协议。提供/应答交换是原子的；如果回答被拒绝，会话将恢复到要约之前的状态（可能是没有会话）。
At any time, either agent MAY generate a new offer that updates the session. However, it MUST NOT generate a new offer if it has received an offer which it has not yet answered or rejected. Furthermore, it MUST NOT generate a new offer if it has generated a prior offer for which it has not yet received an answer or a rejection. If an agent receives an offer after having sent one, but before receiving an answer to it, this is considered a "glare" condition.
任何时候，任一代理都可以生成更新会话的新报价。但是，如果收到尚未答复或拒绝的要约，则不得生成新要约。此外，如果它已经生成了先前的报价，但尚未收到答复或拒绝，则它不得生成新报价。如果代理在发送报价后但在收到答复之前收到报价，则被视为“眩目”情况。
The term glare was originally used in circuit switched telecommunications networks to describe the condition where two switches both attempt to seize the same available circuit on the same trunk at the same time. Here, it means both agents have attempted to send an updated offer at the same time.
眩光一词最初用于电路交换电信网络，用于描述两个交换机同时试图占用同一主干上相同可用电路的情况。这里，这意味着两个代理试图同时发送更新的报价。
The higher layer protocol needs to provide a means for resolving such conditions. The higher layer protocol will need to provide a means for ordering of messages in each direction. SIP meets these requirements [7].
高层协议需要提供一种解决此类情况的方法。更高层的协议将需要提供一种在每个方向上对消息进行排序的方法。SIP符合这些要求[7]。
5 Generating the Initial Offer
5生成初始报价
The offer (and answer) MUST be a valid SDP message, as defined by RFC 2327 [1], with one exception. RFC 2327 mandates that either an e or a p line is present in the SDP message. This specification relaxes that constraint; an SDP formulated for an offer/answer application MAY omit both the e and p lines. The numeric value of the session id and version in the o line MUST be representable with a 64 bit signed integer. The initial value of the version MUST be less than (2**62)-1, to avoid rollovers. Although the SDP specification allows for multiple session descriptions to be concatenated together into a large SDP message, an SDP message used in the offer/answer model MUST contain exactly one session description.
报价（和应答）必须是RFC 2327[1]定义的有效SDP消息，但有一个例外。RFC 2327要求SDP消息中存在e或p行。该规范放松了这种约束；为报价/应答应用程序制定的SDP可以省略e行和p行。o行中会话id和版本的数值必须可以用64位有符号整数表示。版本的初始值必须小于（2**62）-1，以避免翻滚。尽管SDP规范允许将多个会话描述连接到一个大型SDP消息中，但在提供/应答模型中使用的SDP消息必须仅包含一个会话描述。
The SDP "s=" line conveys the subject of the session, which is reasonably defined for multicast, but ill defined for unicast. For unicast sessions, it is RECOMMENDED that it consist of a single space character (0x20) or a dash (-).
SDP“s=”行表示会话的主题，该主题在多播中定义合理，但在单播中定义不明确。对于单播会话，建议它由单个空格字符（0x20）或破折号（-）组成。
Unfortunately, SDP does not allow the "s=" line to be empty.
不幸的是，SDP不允许“s=”行为空。
The SDP "t=" line conveys the time of the session. Generally, streams for unicast sessions are created and destroyed through external signaling means, such as SIP. In that case, the "t=" line SHOULD have a value of "0 0".
SDP“t=”行表示会话的时间。通常，用于单播会话的流是通过外部信令手段（例如SIP）创建和销毁的。在这种情况下，“t=”行的值应为“0”。
The offer will contain zero or more media streams (each media stream is described by an "m=" line and its associated attributes). Zero media streams implies that the offerer wishes to communicate, but that the streams for the session will be added at a later time through a modified offer. The streams MAY be for a mix of unicast and multicast; the latter obviously implies a multicast address in the relevant "c=" line(s).
报价将包含零个或多个媒体流（每个媒体流由“m=”行及其相关属性描述）。零媒体流意味着发盘方希望通信，但会话的流将在稍后通过修改的发盘添加。流可用于单播和多播的混合；后者显然意味着相关“c=”行中的多播地址。
Construction of each offered stream depends on whether the stream is multicast or unicast.
每个提供流的构造取决于流是多播还是单播。
If the offerer wishes to only send media on a stream to its peer, it MUST mark the stream as sendonly with the "a=sendonly" attribute. We refer to a stream as being marked with a certain direction if a direction attribute was present as either a media stream attribute or
如果报价人希望仅向其对等方发送流上的媒体，则必须使用“a=sendonly”属性将流标记为sendonly。如果方向属性作为媒体流属性或媒体流属性存在，则我们将流称为标记有特定方向的流
a session attribute. If the offerer wishes to only receive media from its peer, it MUST mark the stream as recvonly. If the offerer wishes to communicate, but wishes to neither send nor receive media at this time, it MUST mark the stream with an "a=inactive" attribute. The inactive direction attribute is specified in RFC 3108 [3]. Note that in the case of the Real Time Transport Protocol (RTP) [4], RTCP is still sent and received for sendonly, recvonly, and inactive streams. That is, the directionality of the media stream has no impact on the RTCP usage. If the offerer wishes to both send and receive media with its peer, it MAY include an "a=sendrecv" attribute, or it MAY omit it, since sendrecv is the default.
会话属性。如果提供方希望仅从其对等方接收媒体，则必须将流标记为recvonly。如果报价人希望通信，但此时既不希望发送也不希望接收媒体，则必须使用“a=不活动”属性标记流。RFC 3108[3]中指定了非活动方向属性。注意，在实时传输协议（RTP）[4]的情况下，RTCP仍然针对仅发送、仅回复和非活动流发送和接收。也就是说，媒体流的方向性对RTCP的使用没有影响。如果报价人希望与其对等方同时发送和接收媒体，则可能会包含“a=sendrecv”属性，也可能会忽略该属性，因为sendrecv是默认值。
For recvonly and sendrecv streams, the port number and address in the offer indicate where the offerer would like to receive the media stream. For sendonly RTP streams, the address and port number indirectly indicate where the offerer wants to receive RTCP reports. Unless there is an explicit indication otherwise, reports are sent to the port number one higher than the number indicated. The IP address and port present in the offer indicate nothing about the source IP address and source port of RTP and RTCP packets that will be sent by the offerer. A port number of zero in the offer indicates that the stream is offered but MUST NOT be used. This has no useful semantics in an initial offer, but is allowed for reasons of completeness, since the answer can contain a zero port indicating a rejected stream (Section 6). Furthermore, existing streams can be terminated by setting the port to zero (Section 8). In general, a port number of zero indicates that the media stream is not wanted.
对于RecvoOnly和sendrecv流，要约中的端口号和地址指示要约人希望接收媒体流的位置。对于仅发送RTP流，地址和端口号间接指示报价人希望接收RTCP报告的位置。除非另有明确指示，否则会将报告发送到比指示的端口号高的端口号1。报价中的IP地址和端口不表示报价人将发送的RTP和RTCP数据包的源IP地址和源端口。提供中的端口号为零表示提供了流，但不能使用。这在初始报价中没有有用的语义，但出于完整性的原因，允许这样做，因为答案可以包含一个表示拒绝流的零端口（第6节）。此外，可以通过将端口设置为零来终止现有流（第8节）。通常，端口号为零表示不需要媒体流。
The list of media formats for each media stream conveys two pieces of information, namely the set of formats (codecs and any parameters associated with the codec, in the case of RTP) that the offerer is capable of sending and/or receiving (depending on the direction attributes), and, in the case of RTP, the RTP payload type numbers used to identify those formats. If multiple formats are listed, it means that the offerer is capable of making use of any of those formats during the session. In other words, the answerer MAY change formats in the middle of the session, making use of any of the formats listed, without sending a new offer. For a sendonly stream, the offer SHOULD indicate those formats the offerer is willing to send for this stream. For a recvonly stream, the offer SHOULD indicate those formats the offerer is willing to receive for this stream. For a sendrecv stream, the offer SHOULD indicate those codecs that the offerer is willing to send and receive with.
每个媒体流的媒体格式列表传送两条信息，即报价人能够发送和/或接收（取决于方向属性）的一组格式（编解码器和与编解码器相关联的任何参数，在RTP的情况下），以及在RTP的情况下，用于标识这些格式的RTP有效负载类型号。如果列出了多种格式，则表示报价人能够在会议期间使用这些格式中的任何一种。换言之，应答者可以改变会话中间的格式，利用所列出的任何格式，而不发送新的要约。对于sendonly流，报价应表明报价人愿意为此流发送的格式。对于recvonly流，报价应表明报价人愿意为此流接收的格式。对于sendrecv流，报价应指明报价人愿意发送和接收的编解码器。
For recvonly RTP streams, the payload type numbers indicate the value of the payload type field in RTP packets the offerer is expecting to receive for that codec. For sendonly RTP streams, the payload type numbers indicate the value of the payload type field in RTP packets
对于recvonly RTP流，有效负载类型编号表示报价人期望为该编解码器接收的RTP数据包中有效负载类型字段的值。对于仅发送RTP流，有效负载类型编号指示RTP数据包中有效负载类型字段的值
the offerer is planning to send for that codec. For sendrecv RTP streams, the payload type numbers indicate the value of the payload type field the offerer expects to receive, and would prefer to send. However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer.
报价人计划发送该编解码器。对于sendrecv RTP流，有效负载类型编号表示报价人希望接收并希望发送的有效负载类型字段的值。但是，对于sendonly和sendrecv流，答案可能表示相同编解码器的不同有效负载类型编号，在这种情况下，报价人必须使用答案中的有效负载类型编号进行发送。
Different payload type numbers may be needed in each direction because of interoperability concerns with H.323.
由于H.323的互操作性问题，每个方向可能需要不同的有效负载类型号。
As per RFC 2327, fmtp parameters MAY be present to provide additional parameters of the media format.
根据RFC 2327，可能存在fmtp参数以提供媒体格式的附加参数。
In the case of RTP streams, all media descriptions SHOULD contain "a=rtpmap" mappings from RTP payload types to encodings. If there is no "a=rtpmap", the default payload type mapping, as defined by the current profile in use (for example, RFC 1890 [5]) is to be used.
对于RTP流，所有媒体描述都应包含从RTP有效负载类型到编码的“a=rtpmap”映射。如果没有“a=rtpmap”，将使用当前使用的配置文件（例如RFC 1890[5]）定义的默认有效负载类型映射。
This allows easier migration away from static payload types.
这使得从静态有效负载类型迁移更容易。
In all cases, the formats in the "m=" line MUST be listed in order of preference, with the first format listed being preferred. In this case, preferred means that the recipient of the offer SHOULD use the format with the highest preference that is acceptable to it.
在所有情况下，“m=”行中的格式必须按优先顺序列出，第一种格式优先。在这种情况下，“首选”是指要约接收人应使用其可接受的具有最高首选的格式。
If the ptime attribute is present for a stream, it indicates the desired packetization interval that the offerer would like to receive. The ptime attribute MUST be greater than zero.
如果流存在ptime属性，则它表示报价人希望接收的所需打包间隔。ptime属性必须大于零。
If the bandwidth attribute is present for a stream, it indicates the desired bandwidth that the offerer would like to receive. A value of zero is allowed, but discouraged. It indicates that no media should be sent. In the case of RTP, it would also disable all RTCP.
如果流存在带宽属性，则它指示发盘方希望接收的所需带宽。允许值为零，但不鼓励使用。它表示不应发送任何媒体。在RTP的情况下，它还将禁用所有RTCP。
If multiple media streams of different types are present, it means that the offerer wishes to use those streams at the same time. A typical case is an audio and a video stream as part of a videoconference.
如果存在不同类型的多个媒体流，则表示报价人希望同时使用这些流。典型的情况是作为视频会议一部分的音频和视频流。
If multiple media streams of the same type are present in an offer, it means that the offerer wishes to send (and/or receive) multiple streams of that type at the same time. When sending multiple streams of the same type, it is a matter of local policy as to how each media source of that type (for example, a video camera and VCR in the case of video) is mapped to each stream. When a user has a single source for a particular media type, only one policy makes sense: the source is sent to each stream of the same type. Each stream MAY use different encodings. When receiving multiple streams of the same
如果要约中存在多个相同类型的媒体流，则表示要约人希望同时发送（和/或接收）多个该类型的媒体流。当发送相同类型的多个流时，如何将该类型的每个媒体源（例如，对于视频，摄像机和VCR）映射到每个流是本地策略的问题。当用户有一个特定媒体类型的单一源时，只有一个策略是有意义的：源被发送到相同类型的每个流。每个流可以使用不同的编码。当接收到多个相同的流时
type, it is a matter of local policy as to how each stream is mapped to the various media sinks for that particular type (for example, speakers or a recording device in the case of audio). There are a few constraints on the policies, however. First, when receiving multiple streams of the same type, each stream MUST be mapped to at least one sink for the purpose of presentation to the user. In other words, the intent of receiving multiple streams of the same type is that they should all be presented in parallel, rather than choosing just one. Another constraint is that when multiple streams are received and sent to the same sink, they MUST be combined in some media specific way. For example, in the case of two audio streams, the received media from each might be mapped to the speakers. In that case, the combining operation would be to mix them. In the case of multiple instant messaging streams, where the sink is the screen, the combining operation would be to present all of them to the user interface. The third constraint is that if multiple sources are mapped to the same stream, those sources MUST be combined in some media specific way before they are sent on the stream. Although policies beyond these constraints are flexible, an agent won't generally want a policy that will copy media from its sinks to its sources unless it is a conference server (i.e., don't copy received media on one stream to another stream).
类型，每个流如何映射到该特定类型的各种媒体接收器（例如，扬声器或音频情况下的记录设备）是本地策略的问题。然而，这些政策有一些限制。首先，当接收相同类型的多个流时，每个流必须映射到至少一个接收器，以便向用户呈现。换句话说，接收相同类型的多个流的目的是它们都应该并行地呈现，而不是只选择一个。另一个限制是，当多个流被接收并发送到同一个接收器时，它们必须以某种特定于媒体的方式进行组合。例如，在两个音频流的情况下，从每个音频流接收的媒体可以映射到扬声器。在这种情况下，合并操作将是混合它们。在多个即时消息流的情况下，其中接收器是屏幕，组合操作将向用户界面呈现所有即时消息流。第三个约束条件是，如果多个源映射到同一个流，那么这些源在流上发送之前必须以某种媒体特定的方式进行组合。尽管超出这些限制的策略是灵活的，但代理通常不需要将媒体从其接收器复制到其源的策略，除非它是会议服务器（即，不要将一个流上接收到的媒体复制到另一个流）。
A typical usage example for multiple media streams of the same type is a pre-paid calling card application, where the user can press and hold the pound ("#") key at any time during a call to hangup and make a new call on the same card. This requires media from the user to two destinations - the remote gateway, and the DTMF processing application which looks for the pound. This could be accomplished with two media streams, one sendrecv to the gateway, and the other sendonly (from the perspective of the user) to the DTMF application.
同一类型的多个媒体流的一个典型使用示例是预付费电话卡应用程序，用户可以在通话过程中随时按住pound（“#”）键挂断，并在同一张卡上拨打新的电话。这需要从用户到两个目的地的媒体——远程网关和寻找英镑的DTMF处理应用程序。这可以通过两个媒体流来实现，一个向网关发送RECV，另一个仅向DTMF应用程序发送（从用户的角度来看）。
Once the offerer has sent the offer, it MUST be prepared to receive media for any recvonly streams described by that offer. It MUST be prepared to send and receive media for any sendrecv streams in the offer, and send media for any sendonly streams in the offer (of course, it cannot actually send until the peer provides an answer with the needed address and port information). In the case of RTP, even though it may receive media before the answer arrives, it will not be able to send RTCP receiver reports until the answer arrives.
一旦要约人发送了要约，它必须准备接收该要约所描述的任何可接收流的媒体。它必须准备好为要约中的任何sendrecv流发送和接收媒体，并为要约中的任何sendonly流发送媒体（当然，在对等方提供带有所需地址和端口信息的应答之前，它无法实际发送）。在RTP的情况下，即使它可能在应答到达之前接收媒体，但在应答到达之前，它将无法发送RTCP接收器报告。
If a session description contains a multicast media stream which is listed as receive (send) only, it means that the participants, including the offerer and answerer, can only receive (send) on that stream. This differs from the unicast view, where the directionality refers to the flow of media between offerer and answerer.
如果会话描述包含列为仅接收（发送）的多播媒体流，则意味着参与者，包括报价人和应答人，只能在该流上接收（发送）。这与单播视图不同，单播视图中的方向性指的是提供方和应答方之间的媒体流。
Beyond that clarification, the semantics of an offered multicast stream are exactly as described in RFC 2327 [1].
除此之外，所提供的多播流的语义与RFC2327[1]中描述的完全相同。
6 Generating the Answer
6生成答案
The answer to an offered session description is based on the offered session description. If the answer is different from the offer in any way (different IP addresses, ports, etc.), the origin line MUST be different in the answer, since the answer is generated by a different entity. In that case, the version number in the "o=" line of the answer is unrelated to the version number in the o line of the offer.
提供的会话描述的答案基于提供的会话描述。如果答案在任何方面与报价不同（不同的IP地址、端口等），则答案中的起始行必须不同，因为答案是由不同的实体生成的。在这种情况下，答案“o=”行中的版本号与报价o行中的版本号无关。
For each "m=" line in the offer, there MUST be a corresponding "m=" line in the answer. The answer MUST contain exactly the same number of "m=" lines as the offer. This allows for streams to be matched up based on their order. This implies that if the offer contained zero "m=" lines, the answer MUST contain zero "m=" lines.
对于报价中的每个“m=”行，答案中必须有相应的“m=”行。答案必须包含与报价完全相同的“m=”行数。这允许根据流的顺序匹配流。这意味着如果报价包含零“m=”行，则答案必须包含零“m=”行。
The "t=" line in the answer MUST equal that of the offer. The time of the session cannot be negotiated.
答案中的“t=”行必须等于报价。会议时间无法协商。
An offered stream MAY be rejected in the answer, for any reason. If a stream is rejected, the offerer and answerer MUST NOT generate media (or RTCP packets) for that stream. To reject an offered stream, the port number in the corresponding stream in the answer MUST be set to zero. Any media formats listed are ignored. At least one MUST be present, as specified by SDP.
无论出于何种原因，应答中都可能拒绝提供的流。如果流被拒绝，则报价人和应答人不得为该流生成媒体（或RTCP数据包）。要拒绝提供的流，应答中相应流中的端口号必须设置为零。列出的任何媒体格式都将被忽略。根据SDP的规定，必须至少有一个在场。
Constructing an answer for each offered stream differs for unicast and multicast.
对于单播和多播，为每个提供的流构造应答是不同的。
If a stream is offered with a unicast address, the answer for that stream MUST contain a unicast address. The media type of the stream in the answer MUST match that of the offer.
如果流提供了单播地址，则该流的答案必须包含单播地址。答案中流的媒体类型必须与报价的媒体类型匹配。
If a stream is offered as sendonly, the corresponding stream MUST be marked as recvonly or inactive in the answer. If a media stream is listed as recvonly in the offer, the answer MUST be marked as sendonly or inactive in the answer. If an offered media stream is listed as sendrecv (or if there is no direction attribute at the media or session level, in which case the stream is sendrecv by default), the corresponding stream in the answer MAY be marked as sendonly, recvonly, sendrecv, or inactive. If an offered media stream is listed as inactive, it MUST be marked as inactive in the answer.
如果流提供为sendonly，则相应的流必须在应答中标记为RecvoOnly或inactive。如果媒体流在报价中列为RecvoOnly，则应答中必须将应答标记为sendonly或inactive。如果提供的媒体流被列为sendrecv（或者如果媒体或会话级别没有方向属性，在这种情况下，默认情况下该流为sendrecv），则应答中的相应流可能被标记为sendonly、RecVoOnly、sendrecv或inactive。如果提供的媒体流被列为非活动，则必须在应答中将其标记为非活动。
For streams marked as recvonly in the answer, the "m=" line MUST contain at least one media format the answerer is willing to receive with from amongst those listed in the offer. The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to receive. For streams marked as sendonly in the answer, the "m=" line MUST contain at least one media format the answerer is willing to send from amongst those listed in the offer. For streams marked as sendrecv in the answer, the "m=" line MUST contain at least one codec the answerer is willing to both send and receive, from amongst those listed in the offer. The stream MAY indicate additional media formats, not listed in the corresponding stream in the offer, that the answerer is willing to send or receive (of course, it will not be able to send them at this time, since it was not listed in the offer). For streams marked as inactive in the answer, the list of media formats is constructed based on the offer. If the offer was sendonly, the list is constructed as if the answer were recvonly. Similarly, if the offer was recvonly, the list is constructed as if the answer were sendonly, and if the offer was sendrecv, the list is constructed as if the answer were sendrecv. If the offer was inactive, the list is constructed as if the offer were actually sendrecv and the answer were sendrecv.
对于回答中标记为RecvoOnly的流，“m=”行必须至少包含一种回答者愿意从报价中列出的媒体格式中接收的媒体格式。该流可指示应答者愿意接收的未在要约中的对应流中列出的附加媒体格式。对于应答中标记为sendonly的流，“m=”行必须至少包含应答者愿意从报价中列出的媒体格式中发送的一种媒体格式。对于应答中标记为sendrecv的流，“m=”行必须包含应答者愿意从报价中列出的流中发送和接收的至少一个编解码器。该流可指示应答者愿意发送或接收的附加媒体格式（未在要约中的相应流中列出）（当然，此时应答者将无法发送它们，因为它未在要约中列出）。对于应答中标记为非活动的流，媒体格式列表是基于报价构建的。如果要约是仅发送的，则列表的构造方式就好像回答是仅发送一样。类似地，如果要约是RecvoOnly，则列表的构造方式与答案是sendonly一样；如果要约是sendrecv，则列表的构造方式与答案是sendrecv一样。如果要约处于非活动状态，则列表的构造方式就好像要约实际上是sendrecv，而答案是sendrecv。
The connection address and port in the answer indicate the address where the answerer wishes to receive media (in the case of RTP, RTCP will be received on the port which is one higher unless there is an explicit indication otherwise). This address and port MUST be present even for sendonly streams; in the case of RTP, the port one higher is still used to receive RTCP.
应答中的连接地址和端口表示应答者希望接收媒体的地址（在RTP的情况下，RTCP将在端口上接收，该端口高一个，除非另有明确指示）。即使对于仅发送的流，此地址和端口也必须存在；在RTP的情况下，高一个端口仍然用于接收RTCP。
In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer. Even if the same payload type number is used, the answer MUST contain rtpmap attributes to define the payload type mappings for dynamic payload types, and SHOULD contain mappings for static payload types. The media formats in the "m=" line MUST be listed in order of preference, with the first format listed being preferred. In this case, preferred means that the offerer SHOULD use the format with the highest preference from the answer.
在RTP的情况下，如果某个特定的编解码器在报价中引用了特定的有效负载类型号，则在应答中该编解码器应使用相同的有效负载类型号。即使使用相同的有效负载类型编号，答案也必须包含rtpmap属性，以定义动态有效负载类型的有效负载类型映射，并且应该包含静态有效负载类型的映射。“m=”行中的媒体格式必须按首选顺序列出，首选第一种格式。在这种情况下，“首选”是指报价人应使用答案中具有最高首选的格式。
Although the answerer MAY list the formats in their desired order of preference, it is RECOMMENDED that unless there is a specific reason, the answerer list formats in the same relative order they were present in the offer. In other words, if a stream in the offer lists audio codecs 8, 22 and 48, in that order, and the answerer only supports codecs 8 and 48, it is RECOMMENDED that, if the answerer has
尽管回答者可能会按照他们想要的优先顺序列出格式，但建议回答者按照他们在报价中出现的相同相对顺序列出格式，除非有特殊原因。换句话说，如果报价中的流按顺序列出音频编解码器8、22和48，并且应答者仅支持编解码器8和48，则建议如果应答者
no reason to change it, the ordering of codecs in the answer be 8, 48, and not 48, 8. This helps assure that the same codec is used in both directions.
没有理由改变它，答案中编解码器的顺序是8，48，而不是48，8。这有助于确保在两个方向上使用相同的编解码器。
The interpretation of fmtp parameters in an offer depends on the parameters. In many cases, those parameters describe specific configurations of the media format, and should therefore be processed as the media format value itself would be. This means that the same fmtp parameters with the same values MUST be present in the answer if the media format they describe is present in the answer. Other fmtp parameters are more like parameters, for which it is perfectly acceptable for each agent to use different values. In that case, the answer MAY contain fmtp parameters, and those MAY have the same values as those in the offer, or they MAY be different. SDP extensions that define new parameters SHOULD specify the proper interpretation in offer/answer.
报价中fmtp参数的解释取决于参数。在许多情况下，这些参数描述了媒体格式的特定配置，因此应按照媒体格式值本身进行处理。这意味着，如果答案中存在所描述的媒体格式，则答案中必须存在具有相同值的相同fmtp参数。其他fmtp参数更像参数，每个代理使用不同的值是完全可以接受的。在这种情况下，答案可能包含fmtp参数，这些参数可能与报价中的参数值相同，也可能不同。定义新参数的SDP扩展应该在offer/answer中指定正确的解释。
The answerer MAY include a non-zero ptime attribute for any media stream; this indicates the packetization interval that the answerer would like to receive. There is no requirement that the packetization interval be the same in each direction for a particular stream.
应答者可以包括用于任何媒体流的非零ptime属性；这表示应答者希望接收的打包间隔。对于特定流，不要求每个方向上的打包间隔相同。
The answerer MAY include a bandwidth attribute for any media stream; this indicates the bandwidth that the answerer would like the offerer to use when sending media. The value of zero is allowed, interpreted as described in Section 5.
应答器可以包括用于任何媒体流的带宽属性；这表示应答者希望报价人在发送媒体时使用的带宽。允许零的值，如第5节所述进行解释。
If the answerer has no media formats in common for a particular offered stream, the answerer MUST reject that media stream by setting the port to zero.
如果应答器对于特定提供的流没有共同的媒体格式，则应答器必须通过将端口设置为零来拒绝该媒体流。
If there are no media formats in common for all streams, the entire offered session is rejected.
如果所有流没有共同的媒体格式，则拒绝整个提供的会话。
Once the answerer has sent the answer, it MUST be prepared to receive media for any recvonly streams described by that answer. It MUST be prepared to send and receive media for any sendrecv streams in the answer, and it MAY send media immediately. The answerer MUST be prepared to receive media for recvonly or sendrecv streams using any media formats listed for those streams in the answer, and it MAY send media immediately. When sending media, it SHOULD use a packetization interval equal to the value of the ptime attribute in the offer, if any was present. It SHOULD send media using a bandwidth no higher than the value of the bandwidth attribute in the offer, if any was present. The answerer MUST send using a media format in the offer that is also listed in the answer, and SHOULD send using the most preferred media format in the offer that is also listed in the
应答者发送应答后，必须准备接收该应答描述的任何可接收流的媒体。它必须准备好为应答中的任何sendrecv流发送和接收媒体，并且可以立即发送媒体。应答者必须准备好使用应答中列出的任何媒体格式接收recvonly或sendrecv流的媒体，并且可以立即发送媒体。发送媒体时，应使用与报价中ptime属性值相等的打包间隔（如果有）。它应该使用不高于报价中带宽属性值的带宽（如果有）发送媒体。回答者必须使用答案中列出的报价中的媒体格式发送，并且应使用报价中列出的最首选媒体格式发送
answer. In the case of RTP, it MUST use the payload type numbers from the offer, even if they differ from those in the answer.
答复在RTP的情况下，它必须使用报价中的有效负载类型号，即使它们与答案中的不同。
Unlike unicast, where there is a two-sided view of the stream, there is only a single view of the stream for multicast. As such, generating an answer to a multicast offer generally involves modifying a limited set of aspects of the stream.
与单播不同，在单播中存在流的双面视图，而对于多播，只有一个流视图。因此，生成对多播提供的应答通常涉及修改流的有限方面集。
If a multicast stream is accepted, the address and port information in the answer MUST match that of the offer. Similarly, the directionality information in the answer (sendonly, recvonly, or sendrecv) MUST equal that of the offer. This is because all participants in a multicast session need to have equivalent views of the parameters of the session, an underlying assumption of the multicast bias of RFC 2327.
如果接受多播流，则应答中的地址和端口信息必须与报价中的地址和端口信息匹配。类似地，答案中的方向性信息（sendonly、RecVoOnly或sendrecv）必须与报价中的方向性信息相同。这是因为多播会话中的所有参与者都需要具有会话参数的等效视图，这是RFC2327多播偏差的基本假设。
The set of media formats in the answer MUST be equal to or be a subset of those in the offer. Removing a format is a way for the answerer to indicate that the format is not supported.
答案中的媒体格式集必须等于或是报价中的媒体格式集的子集。删除格式是回答者表示不支持该格式的一种方式。
The ptime and bandwidth attributes in the answer MUST equal the ones in the offer, if present. If not present, a non-zero ptime MAY be added to the answer.
答案中的ptime和带宽属性必须与报价中的相同（如果存在）。如果不存在，则可在答案中添加非零ptime。
7 Offerer Processing of the Answer
7报价人对答案的处理
When the offerer receives the answer, it MAY send media on the accepted stream(s) (assuming it is listed as sendrecv or recvonly in the answer). It MUST send using a media format listed in the answer, and it SHOULD use the first media format listed in the answer when it does send.
当发盘方收到应答时，它可以在接受的流上发送媒体（假设应答中列为sendrecv或RecvoOnly）。它必须使用答案中列出的媒体格式发送，并且在发送时应使用答案中列出的第一种媒体格式。
The reason this is a SHOULD, and not a MUST (its also a SHOULD, and not a MUST, for the answerer), is because there will oftentimes be a need to change codecs on the fly. For example, during silence periods, an agent might like to switch to a comfort noise codec. Or, if the user presses a number on the keypad, the agent might like to send that using RFC 2833 [9]. Congestion control might necessitate changing to a lower rate codec based on feedback.
这是应该的，而不是必须的（对于回答者来说，这也是应该的，而不是必须的），是因为经常需要动态更改编解码器。例如，在静默期间，代理可能希望切换到舒适噪声编解码器。或者，如果用户按下键盘上的数字，代理可能希望使用RFC 2833[9]发送该数字。拥塞控制可能需要根据反馈更改为较低速率的编解码器。
The offerer SHOULD send media according to the value of any ptime and bandwidth attribute in the answer.
报价人应根据答案中任何ptime和带宽属性的值发送媒体。
The offerer MAY immediately cease listening for media formats that were listed in the initial offer, but not present in the answer.
报价人可立即停止收听初始报价中列出但未出现在答复中的媒体格式。
8 Modifying the Session
8修改会话
At any point during the session, either participant MAY issue a new offer to modify characteristics of the session. It is fundamental to the operation of the offer/answer model that the exact same offer/answer procedure defined above is used for modifying parameters of an existing session.
在会议期间的任何时候，任何一位参与者均可发布新的报价，以修改会议的特征。对于提供/应答模型的操作来说，使用上面定义的完全相同的提供/应答过程来修改现有会话的参数是至关重要的。
The offer MAY be identical to the last SDP provided to the other party (which may have been provided in an offer or an answer), or it MAY be different. We refer to the last SDP provided as the "previous SDP". If the offer is the same, the answer MAY be the same as the previous SDP from the answerer, or it MAY be different. If the offered SDP is different from the previous SDP, some constraints are placed on its construction, discussed below.
该要约可能与向另一方提供的最后一份SDP相同（该SDP可能已在要约或答复中提供），也可能不同。我们将提供的上一个SDP称为“上一个SDP”。如果报价相同，则答案可能与回答者先前的SDP相同，也可能不同。如果提供的SDP与以前的SDP不同，则会对其构造施加一些限制，如下所述。
Nearly all aspects of the session can be modified. New streams can be added, existing streams can be deleted, and parameters of existing streams can change. When issuing an offer that modifies the session, the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number. The answerer MUST be prepared to receive an offer that contains SDP with a version that has not changed; this is effectively a no-op. However, the answerer MUST generate a valid answer (which MAY be the same as the previous SDP from the answerer, or MAY be different), according to the procedures defined in Section 6.
几乎会话的所有方面都可以修改。可以添加新流，删除现有流，并且可以更改现有流的参数。发布修改会话的报价时，新SDP的“o=”行必须与先前SDP中的“o=”行相同，但“来源”字段中的版本必须比先前SDP增加1。如果原始行中的版本没有增加，则SDP必须与具有该版本号的SDP相同。回答者必须准备好接受包含SDP且版本未更改的报价；这实际上是不可操作的。但是，回答者必须根据第6节规定的程序生成有效答案（可能与回答者之前的SDP相同，也可能不同）。
If an SDP is offered, which is different from the previous SDP, the new SDP MUST have a matching media stream for each media stream in the previous SDP. In other words, if the previous SDP had N "m=" lines, the new SDP MUST have at least N "m=" lines. The i-th media stream in the previous SDP, counting from the top, matches the i-th media stream in the new SDP, counting from the top. This matching is necessary in order for the answerer to determine which stream in the new SDP corresponds to a stream in the previous SDP. Because of these requirements, the number of "m=" lines in a stream never decreases, but either stays the same or increases. Deleted media streams from a previous SDP MUST NOT be removed in a new SDP; however, attributes for these streams need not be present.
如果提供了不同于先前SDP的SDP，则新SDP必须为先前SDP中的每个媒体流具有匹配的媒体流。换句话说，如果以前的SDP有N“m=”行，则新SDP必须至少有N“m=”行。前一个SDP中从顶部开始计数的第i个媒体流与新SDP中从顶部开始计数的第i个媒体流相匹配。为了让应答者确定新SDP中的哪个流对应于先前SDP中的流，该匹配是必要的。由于这些要求，流中“m=”行的数量不会减少，而是保持不变或增加。不得在新SDP中删除先前SDP中删除的媒体流；但是，这些流的属性不需要存在。
New media streams are created by new additional media descriptions below the existing ones, or by reusing the "slot" used by an old media stream which had been disabled by setting its port to zero.
新的媒体流是通过在现有媒体流下面添加新的媒体描述来创建的，或者通过重用旧媒体流使用的“插槽”来创建的，旧媒体流已通过将其端口设置为零而禁用。
Reusing its slot means that the new media description replaces the old one, but retains its positioning relative to other media descriptions in the SDP. New media descriptions MUST appear below any existing media sections. The rules for formatting these media descriptions are identical to those described in Section 5.
重用其插槽意味着新媒体描述将替换旧媒体描述，但保留其相对于SDP中其他媒体描述的位置。新媒体描述必须出现在任何现有媒体部分的下方。格式化这些媒体描述的规则与第5节中描述的规则相同。
When the answerer receives an SDP with more media descriptions than the previous SDP from the offerer, or it receives an SDP with a media stream in a slot where the port was previously zero, the answerer knows that new media streams are being added. These can be rejected or accepted by placing an appropriately structured media description in the answer. The procedures for constructing the new media description in the answer are described in Section 6.
当应答方从报价方接收到媒体描述多于先前SDP的SDP时，或者在端口先前为零的插槽中接收到媒体流的SDP时，应答方知道正在添加新的媒体流。通过在答案中添加适当结构的媒体描述，可以拒绝或接受这些内容。第6节描述了在答案中构建新媒体描述的步骤。
Existing media streams are removed by creating a new SDP with the port number for that stream set to zero. The stream description MAY omit all attributes present previously, and MAY list just a single media format.
通过创建一个新的SDP并将该流的端口号设置为零，可以删除现有的媒体流。流描述可以省略先前存在的所有属性，并且可以仅列出单个媒体格式。
A stream that is offered with a port of zero MUST be marked with port zero in the answer. Like the offer, the answer MAY omit all attributes present previously, and MAY list just a single media format from amongst those in the offer.
端口为零的流必须在应答中标记为端口为零。与报价一样，答案可能会忽略之前提供的所有属性，并且可能只列出报价中的一种媒体格式。
Removal of a media stream implies that media is no longer sent for that stream, and any media that is received is discarded. In the case of RTP, RTCP transmission also ceases, as does processing of any received RTCP packets. Any resources associated with it can be released. The user interface might indicate that the stream has terminated, by closing the associated window on a PC, for example.
删除媒体流意味着不再为该流发送媒体，接收到的任何媒体都将被丢弃。在RTP的情况下，RTCP传输也会停止，任何接收到的RTCP数据包的处理也会停止。可以释放与之相关的任何资源。例如，通过关闭PC上的相关窗口，用户界面可能指示流已终止。
Nearly all characteristics of a media stream can be modified.
几乎可以修改媒体流的所有特征。
The port number for a stream MAY be changed. To do this, the offerer creates a new media description, with the port number in the m line different from the corresponding stream in the previous SDP. If only the port number is to be changed, the rest of the media stream description SHOULD remain unchanged. The offerer MUST be prepared to receive media on both the old and new ports as soon as the offer is sent. The offerer SHOULD NOT cease listening for media on the old port until the answer is received and media arrives on the new port. Doing so could result in loss of media during the transition.
可以更改流的端口号。为此，报价人创建一个新的媒体描述，m行中的端口号不同于先前SDP中的相应流。如果只更改端口号，则媒体流描述的其余部分应保持不变。报价人必须准备好在发送报价后立即在新旧端口接收媒体。在收到答复且媒体到达新端口之前，报价人不应停止在旧端口监听媒体。这样做可能会导致过渡期间介质丢失。
Received, in this case, means that the media is passed to a media sink. This means that if there is a playout buffer, the agent would continue to listen on the old port until the media on the new port reached the top of the playout buffer. At that time, it MAY cease listening for media on the old port.
在这种情况下，接收意味着介质被传送到介质接收器。这意味着，如果存在播放缓冲区，代理将继续在旧端口上侦听，直到新端口上的媒体到达播放缓冲区的顶部。此时，它可能会停止侦听旧端口上的媒体。
The corresponding media stream in the answer MAY be the same as the stream in the previous SDP from the answerer, or it MAY be different. If the updated stream is accepted by the answerer, the answerer SHOULD begin sending traffic for that stream to the new port immediately. If the answerer changes the port from the previous SDP, it MUST be prepared to receive media on both the old and new ports as soon as the answer is sent. The answerer MUST NOT cease listening for media on the old port until media arrives on the new port. At that time, it MAY cease listening for media on the old port. The same is true for an offerer that sends an updated offer with a new port; it MUST NOT cease listening for media on the old port until media arrives on the new port.
应答中的对应媒体流可以与来自应答者的先前SDP中的流相同，也可以不同。如果应答者接受更新的流，应答者应立即开始向新端口发送该流的通信量。如果应答者更改了先前SDP的端口，则应答者必须准备好在发送应答后立即在旧端口和新端口上接收媒体。在媒体到达新端口之前，应答者不得停止侦听旧端口上的媒体。此时，它可能会停止侦听旧端口上的媒体。发送带有新端口的更新报价的报价人也是如此；在媒体到达新端口之前，它不得停止侦听旧端口上的媒体。
Of course, if the offered stream is rejected, the offerer can cease being prepared to receive using the new port as soon as the rejection is received.
当然，如果提供的流被拒绝，那么一旦收到拒绝，提供方就可以停止准备使用新端口接收。
To change the IP address where media is sent to, the same procedure is followed for changing the port number. The only difference is that the connection line is updated, not the port number.
要更改媒体发送到的IP地址，请遵循更改端口号的相同步骤。唯一的区别是更新了连接线，而不是端口号。
The transport for a stream MAY be changed. The process for doing this is identical to changing the port, except the transport is updated, not the port.
可以更改流的传输。执行此操作的过程与更改端口相同，只是更新了传输，而不是端口。
The list of media formats used in the session MAY be changed. To do this, the offerer creates a new media description, with the list of media formats in the "m=" line different from the corresponding media stream in the previous SDP. This list MAY include new formats, and MAY remove formats present from the previous SDP. However, in the case of RTP, the mapping from a particular dynamic payload type number to a particular codec within that media stream MUST NOT change for the duration of a session. For example, if A generates an offer with G.711 assigned to dynamic payload type number 46, payload type number 46 MUST refer to G.711 from that point forward in any offers or answers for that media stream within the session. However, it is acceptable for multiple payload type numbers to be mapped to the same codec, so that an updated offer could also use payload type number 72 for G.711.
会话中使用的媒体格式列表可能会更改。为此，报价人创建一个新的媒体描述，“m=”行中的媒体格式列表不同于先前SDP中的相应媒体流。此列表可能包括新格式，也可能从以前的SDP中删除现有格式。然而，在RTP的情况下，在会话期间，从特定动态有效负载类型号到该媒体流中的特定编解码器的映射不得改变。例如，如果A生成分配给动态有效负载类型编号46的G.711的报价，则有效负载类型编号46必须在会话内该媒体流的任何报价或应答中从该点向前参考G.711。但是，可以将多个有效负载类型号映射到同一编解码器，这样更新后的产品也可以将有效负载类型号72用于G.711。
The mappings need to remain fixed for the duration of the session because of the loose synchronization between signaling exchanges of SDP and the media stream.
由于SDP的信令交换和媒体流之间的松散同步，映射需要在会话期间保持固定。
The corresponding media stream in the answer is formulated as described in Section 6, and may result in a change in media formats as well. Similarly, as described in Section 6, as soon as it sends its answer, the answerer MUST begin sending media using any formats in the offer that were also present in the answer, and SHOULD use the most preferred format in the offer that was also listed in the answer (assuming the stream allows for sending), and MUST NOT send using any formats that are not in the offer, even if they were present in a previous SDP from the peer. Similarly, when the offerer receives the answer, it MUST begin sending media using any formats in the answer, and SHOULD use the most preferred one (assuming the stream allows for sending), and MUST NOT send using any formats that are not in the answer, even if they were present in a previous SDP from the peer.
答案中的相应媒体流如第6节所述被公式化，并且也可能导致媒体格式的改变。类似地，如第6节所述，一旦应答者发送其应答，应答者必须开始使用应答中也存在的报价中的任何格式发送媒体，并且应使用应答中也列出的报价中最首选的格式（假设流允许发送），并且不得使用报价中未包含的任何格式发送，即使这些格式存在于同行先前的SDP中。类似地，当报价人接收到答案时，必须开始使用答案中的任何格式发送媒体，并应使用最首选的格式（假设流允许发送），并且不得使用答案中不存在的任何格式发送，即使它们在来自对等方的前一个SDP中存在。
When an agent ceases using a media format (by not listing that format in an offer or answer, even though it was in a previous SDP) the agent will still need to be prepared to receive media with that format for a brief time. How does it know when it can be prepared to stop receiving with that format? If it needs to know, there are three techniques that can be applied. First, the agent can change ports in addition to changing formats. When media arrives on the new port, it knows that the peer has ceased sending with the old format, and it can cease being prepared to receive with it. This approach has the benefit of being media format independent. However, changes in ports may require changes in resource reservation or rekeying of security protocols. The second approach is to use a totally new set of dynamic payload types for all codecs when one is discarded. When media is received with one of the new payload types, the agent knows that the peer has ceased sending with the old format. This approach doesn't affect reservations or security contexts, but it is RTP specific and wasteful of a very small payload type space. A third approach is to use a timer. When the SDP from the peer is received, the timer is set. When it fires, the agent can cease being prepared to receive with the old format. A value of one minute would typically be more than sufficient. In some cases, an agent may not care, and thus continually be prepared to receive with the old formats. Nothing need be done in this case.
当代理停止使用媒体格式时（通过在报价或答复中不列出该格式，即使该格式在以前的SDP中），代理仍需要准备在短时间内接收该格式的媒体。它如何知道何时可以准备停止接收该格式？如果需要知道，有三种技术可以应用。首先，代理除了更改格式外，还可以更改端口。当媒体到达新端口时，它知道对等方已停止使用旧格式发送，并且可以停止准备使用旧格式接收。这种方法的优点是与媒体格式无关。但是，端口的更改可能需要更改资源保留或安全协议的密钥更新。第二种方法是在丢弃一个编解码器时，为所有编解码器使用一组全新的动态负载类型。当使用新的有效负载类型之一接收媒体时，代理知道对等方已停止使用旧格式发送。这种方法不影响保留或安全上下文，但它是RTP特定的，并且浪费了非常小的有效负载类型空间。第三种方法是使用计时器。当接收到来自对等方的SDP时，将设置计时器。当它触发时，代理可以停止准备以旧格式接收。一分钟的值通常就足够了。在某些情况下，代理可能并不在意，因此会不断准备以旧格式接收。在这种情况下不需要做任何事情。
Of course, if the offered stream is rejected, the offer can cease being prepared to receive using any new formats as soon as the rejection is received.
当然，如果提供的流被拒绝，那么一旦收到拒绝，提供就可以停止准备使用任何新格式接收。
The media type (audio, video, etc.) for a stream MAY be changed. It is RECOMMENDED that the media type be changed (as opposed to adding a new stream), when the same logical data is being conveyed, but just in a different media format. This is particularly useful for changing between voiceband fax and fax in a single stream, which are both separate media types. To do this, the offerer creates a new media description, with a new media type, in place of the description in the previous SDP which is to be changed.
流的媒体类型（音频、视频等）可以改变。当传输相同的逻辑数据时，建议更改媒体类型（而不是添加新的流），但只需使用不同的媒体格式。这对于在语音带传真和单一流中的传真之间切换特别有用，这两种媒体类型都是独立的。为此，报价人创建一个新的媒体描述，使用新的媒体类型，代替要更改的先前SDP中的描述。
The corresponding media stream in the answer is formulated as described in Section 6. Assuming the stream is acceptable, the answerer SHOULD begin sending with the new media type and formats as soon as it receives the offer. The offerer MUST be prepared to receive media with both the old and new types until the answer is received, and media with the new type is received and reaches the top of the playout buffer.
答案中的相应媒体流如第6节所述被公式化。假设流是可接受的，应答者应在收到报价后立即开始发送新的媒体类型和格式。报价人必须准备好接收新旧类型的媒体，直到收到答案，并且接收到新类型的媒体并到达播放缓冲区的顶部。
Any other attributes in a media description MAY be updated in an offer or answer. Generally, an agent MUST send media (if the directionality of the stream allows) using the new parameters once the SDP with the change is received.
媒体描述中的任何其他属性可以在报价或应答中更新。通常，一旦接收到带有更改的SDP，代理必须使用新参数发送媒体（如果流的方向性允许）。
If a party in a call wants to put the other party "on hold", i.e., request that it temporarily stops sending one or more unicast media streams, a party offers the other an updated SDP.
如果通话中的一方希望让另一方“暂停”，即请求其暂时停止发送一个或多个单播媒体流，则一方向另一方提供更新的SDP。
If the stream to be placed on hold was previously a sendrecv media stream, it is placed on hold by marking it as sendonly. If the stream to be placed on hold was previously a recvonly media stream, it is placed on hold by marking it inactive.
如果要挂起的流以前是sendrecv媒体流，则通过将其标记为sendonly将其挂起。如果要挂起的流以前是可恢复的媒体流，则通过将其标记为非活动来将其挂起。
This means that a stream is placed "on hold" separately in each direction. Each stream is placed "on hold" independently. The recipient of an offer for a stream on-hold SHOULD NOT automatically return an answer with the corresponding stream on hold. An SDP with all streams "on hold" is referred to as held SDP.
这意味着流在每个方向上分别处于“暂停”状态。每个流都独立地处于“保留”状态。等待流的报价的接收者不应自动返回带有相应等待流的答复。具有所有流“保持”的SDP称为保持SDP。
Certain third party call control scenarios do not work when an answerer responds to held SDP with held SDP.
当应答者用保持的SDP响应保持的SDP时，某些第三方呼叫控制场景不起作用。
Typically, when a user "presses" hold, the agent will generate an offer with all streams in the SDP indicating a direction of sendonly, and it will also locally mute, so that no media is sent to the far end, and no media is played out.
通常，当用户“按下”hold时，代理将生成一个要约，其中SDP中的所有流都指示sendonly的方向，并且它还将本地静音，这样就不会向远端发送媒体，也不会播放媒体。
RFC 2543 [10] specified that placing a user on hold was accomplished by setting the connection address to 0.0.0.0. Its usage for putting a call on hold is no longer recommended, since it doesn't allow for RTCP to be used with held streams, doesn't work with IPv6, and breaks with connection oriented media. However, it can be useful in an initial offer when the offerer knows it wants to use a particular set of media streams and formats, but doesn't know the addresses and ports at the time of the offer. Of course, when used, the port number MUST NOT be zero, which would specify that the stream has been disabled. An agent MUST be capable of receiving SDP with a connection address of 0.0.0.0, in which case it means that neither RTP nor RTCP should be sent to the peer.
RFC 2543[10]规定，通过将连接地址设置为0.0.0.0，可以实现将用户置于挂起状态。不再推荐将其用于挂起呼叫，因为它不允许RTCP与挂起的流一起使用，不适用于IPv6，并且与面向连接的媒体中断。但是，当报价人知道它想要使用一组特定的媒体流和格式，但不知道报价时的地址和端口时，它在初始报价中可能很有用。当然，使用时，端口号不能为零，这将指定流已被禁用。代理必须能够接收连接地址为0.0.0.0的SDP，在这种情况下，这意味着不应向对等方发送RTP或RTCP。
9 Indicating Capabilities
9指示能力
Before an agent sends an offer, it is helpful to know if the media formats in that offer would be acceptable to the answerer. Certain protocols, like SIP, provide a means to query for such capabilities. SDP can be used in responses to such queries to indicate capabilities. This section describes how such an SDP message is formatted. Since SDP has no way to indicate that the message is for the purpose of capability indication, this is determined from the context of the higher layer protocol. The ability of baseline SDP to indicate capabilities is very limited. It cannot express allowed parameter ranges or values, and can not be done in parallel with an offer/answer itself. Extensions might address such limitations in the future.
在代理发送报价之前，了解报价中的媒体格式是否为回答者所接受是很有帮助的。某些协议（如SIP）提供了查询此类功能的方法。SDP可用于响应此类查询以指示功能。本节介绍如何格式化此类SDP消息。由于SDP无法指示该消息用于能力指示，因此这是根据更高层协议的上下文确定的。基线SDP指示能力的能力非常有限。它不能表示允许的参数范围或值，也不能与报价/应答本身并行进行。扩展可能会在将来解决这些限制。
An SDP constructed to indicate media capabilities is structured as follows. It MUST be a valid SDP, except that it MAY omit both "e=" and "p=" lines. The "t=" line MUST be equal to "0 0". For each media type supported by the agent, there MUST be a corresponding media description of that type. The session ID in the origin field MUST be unique for each SDP constructed to indicate media capabilities. The port MUST be set to zero, but the connection address is arbitrary. The usage of port zero makes sure that an SDP formatted for capabilities does not cause media streams to be established if it is interpreted as an offer or answer.
构造用于指示媒体功能的SDP的结构如下所示。它必须是有效的SDP，但可能同时省略“e=”和“p=”行。“t=”行必须等于“0”。对于代理支持的每种媒体类型，必须有该类型的相应媒体描述。对于为指示媒体功能而构造的每个SDP，源字段中的会话ID必须是唯一的。端口必须设置为零，但连接地址是任意的。端口0的使用确保为功能格式化的SDP不会导致媒体流建立（如果它被解释为提供或应答）。
The transport component of the "m=" line indicates the transport for that media type. For each media format of that type supported by the agent, there SHOULD be a media format listed in the "m=" line. In the case of RTP, if dynamic payload types are used, an rtpmap
“m=”行的传输组件表示该介质类型的传输。对于代理支持的该类型的每种媒体格式，“m=”行中应列出一种媒体格式。对于RTP，如果使用动态有效负载类型，则rtpmap
attribute MUST be present to bind the type to a specific format. There is no way to indicate constraints, such as how many simultaneous streams can be supported for a particular codec, and so on.
属性必须存在才能将类型绑定到特定格式。无法指示约束，例如特定编解码器可以支持多少同时流，等等。
v=0
o=carol 28908764872 28908764872 IN IP4 100.3.6.6
s=-
t=0 0
c=IN IP4 192.0.2.4
m=audio 0 RTP/AVP 0 1 3
a=rtpmap:0 PCMU/8000
a=rtpmap:1 1016/8000
a=rtpmap:3 GSM/8000
m=video 0 RTP/AVP 31 34
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000
v=0
o=carol 28908764872 28908764872 IN IP4 100.3.6.6
s=-
t=0 0
c=IN IP4 192.0.2.4
m=audio 0 RTP/AVP 0 1 3
a=rtpmap:0 PCMU/8000
a=rtpmap:1 1016/8000
a=rtpmap:3 GSM/8000
m=video 0 RTP/AVP 31 34
a=rtpmap:31 H261/90000
a=rtpmap:34 H263/90000
Figure 1: SDP Indicating Capabilities
图1:SDP指示能力
The SDP of Figure 1 indicates that the agent can support three audio codecs (PCMU, 1016, and GSM) and two video codecs (H.261 and H.263).
图1的SDP表明代理可以支持三个音频编解码器（PCMU、1016和GSM）和两个视频编解码器（H.261和H.263）。
10 Example Offer/Answer Exchanges
10个报价/应答交换示例
This section provides example offer/answer exchanges.
本节提供了报价/应答交换示例。
Assume that the caller, Alice, has included the following description in her offer. It includes a bidirectional audio stream and two bidirectional video streams, using H.261 (payload type 31) and MPEG (payload type 32). The offered SDP is:
假设来电者Alice在其报价中包含以下描述。它包括一个双向音频流和两个双向视频流，使用H.261（负载类型31）和MPEG（负载类型32）。提供的SDP是：
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 51372 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
The callee, Bob, does not want to receive or send the first video stream, so he returns the SDP below as the answer:
被叫方Bob不想接收或发送第一个视频流，因此他返回以下SDP作为答案：
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
v=0
o=bob 2890844730 2890844730 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 49920 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
At some point later, Bob decides to change the port where he will receive the audio stream (from 49920 to 65422), and at the same time, add an additional audio stream as receive only, using the RTP payload format for events [9]. Bob offers the following SDP in the offer:
稍后，Bob决定更改接收音频流的端口（从49920更改为65422），同时，使用事件的RTP有效负载格式添加一个额外的音频流作为仅接收[9]。Bob在报价中提供以下SDP：
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 65422 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 51434 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=recvonly
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 65422 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 51434 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=recvonly
Alice accepts the additional media stream, and so generates the following answer:
Alice接受额外的媒体流，因此生成以下答案：
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 53122 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=sendonly
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
m=video 0 RTP/AVP 31
a=rtpmap:31 H261/90000
m=video 53000 RTP/AVP 32
a=rtpmap:32 MPV/90000
m=audio 53122 RTP/AVP 110
a=rtpmap:110 telephone-events/8000
a=sendonly
A common occurrence in embedded phones is that the Digital Signal Processor (DSP) used for compression can support multiple codecs at a time, but once that codec is selected, it cannot be readily changed on the fly. This example shows how a session can be set up using an initial offer/answer exchange, followed immediately by a second one to lock down the set of codecs.
嵌入式手机中常见的一种情况是，用于压缩的数字信号处理器（DSP）一次可以支持多个编解码器，但一旦选择了该编解码器，就无法随时更改。此示例显示了如何使用初始提供/应答交换设置会话，然后立即使用第二个交换锁定编解码器集。
The initial offer from Alice to Bob indicates a single audio stream with the three audio codecs that are available in the DSP. The stream is marked as inactive, since media cannot be received until a codec is locked down:
Alice向Bob提供的初始报价表示一个音频流，其中包含DSP中可用的三个音频编解码器。流被标记为非活动，因为在锁定编解码器之前无法接收媒体：
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=inactive
v=0
o=alice 2890844526 2890844526 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 0 4 18
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=inactive
Bob can support dynamic switching between PCMU and G.723. So, he sends the following answer:
Bob支持PCMU和G.723之间的动态切换。因此，他给出了以下答案：
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=inactive
v=0
o=bob 2890844730 2890844731 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=inactive
Alice can then select any one of these two codecs. So, she sends an updated offer with a sendrecv stream:
然后Alice可以选择这两个编解码器中的任意一个。因此，她发送了一个带有sendrecv流的更新报价：
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv
v=0
o=alice 2890844526 2890844527 IN IP4 host.anywhere.com
s=
c=IN IP4 host.anywhere.com
t=0 0
m=audio 62986 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv
Bob accepts the single codec:
Bob接受单一编解码器：
v=0
o=bob 2890844730 2890844732 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv
v=0
o=bob 2890844730 2890844732 IN IP4 host.example.com
s=
c=IN IP4 host.example.com
t=0 0
m=audio 54344 RTP/AVP 4
a=rtpmap:4 G723/8000
a=sendrecv
If the answerer (Bob), was only capable of supporting one-of-N codecs, Bob would select one of the codecs from the offer, and place that in his answer. In this case, Alice would do a re-INVITE to activate that stream with that codec.
如果回答者（Bob）只能支持N个编解码器中的一个，Bob将从报价中选择一个编解码器，并将其放入他的回答中。在本例中，Alice将执行重新邀请以使用该编解码器激活该流。
As an alternative to using "a=inactive" in the first exchange, Alice can list all codecs, and as soon as she receives media from Bob, generate an updated offer locking down the codec to the one just received. Of course, if Bob only supports one-of-N codecs, there would only be one codec in his answer, and in this case, there is no need for a re-INVITE to lock down to a single codec.
作为在第一次交换中使用“a=inactive”的替代方法，Alice可以列出所有编解码器，并且一旦她从Bob接收到媒体，就生成一个更新的报价，将编解码器锁定为刚接收到的编解码器。当然，如果Bob只支持N个编解码器中的一个，那么他的答案中就只有一个编解码器，在这种情况下，不需要重新邀请来锁定单个编解码器。
11 Security Considerations
11安全考虑
There are numerous attacks possible if an attacker can modify offers or answers in transit. Generally, these include diversion of media streams (enabling eavesdropping), disabling of calls, and injection of unwanted media streams. If a passive listener can construct fake offers, and inject those into an exchange, similar attacks are possible. Even if an attacker can simply observe offers and answers, they can inject media streams into an existing conversation.
如果攻击者可以在传输过程中修改提供或应答，则可能会发生多种攻击。通常，这些包括媒体流的转移（启用窃听）、禁用呼叫和注入不需要的媒体流。如果被动侦听器可以构造假提供，并将其注入到交换中，则可能会发生类似的攻击。即使攻击者可以简单地观察报价和应答，他们也可以将媒体流注入现有对话。
Offer/answer relies on transport within an application signaling protocol, such as SIP. It also relies on that protocol for security capabilities. Because of the attacks described above, that protocol MUST provide a means for end-to-end authentication and integrity protection of offers and answers. It SHOULD offer encryption of bodies to prevent eavesdropping. However, media injection attacks can alternatively be resolved through authenticated media exchange, and therefore the encryption requirement is a SHOULD instead of a MUST.
提供/应答依赖于应用程序信令协议（如SIP）内的传输。它还依赖于该协议的安全功能。由于上述攻击，该协议必须提供端到端身份验证以及提供和应答完整性保护的手段。它应该提供加密的机构，以防止窃听。但是，媒体注入攻击也可以通过经过身份验证的媒体交换来解决，因此加密要求是应该的，而不是必须的。
Replay attacks are also problematic. An attacker can replay an old offer, perhaps one that had put media on hold, and thus disable media streams in a conversation. Therefore, the application protocol MUST provide a secure way to sequence offers and answers, and to detect and reject old offers or answers.
重播攻击也有问题。攻击者可以重播旧的提议，可能是将媒体置于暂停状态的提议，从而在对话中禁用媒体流。因此，应用程序协议必须提供一种安全的方式来对提议和应答进行排序，并检测和拒绝旧的提议或应答。
SIP [7] meets all of these requirements.
SIP[7]满足所有这些要求。
12 IANA Considerations
12 IANA考虑事项
There are no IANA considerations with this specification.
本规范没有IANA注意事项。
13 Acknowledgements
13致谢
The authors would like to thank Allison Mankin, Rohan Mahy, Joerg Ott, and Flemming Andreasen for their detailed comments.
作者要感谢Allison Mankin、Rohan Mahy、Joerg Ott和Flemming Andreasen的详细评论。
14 Normative References
14规范性引用文件
[1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[1] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Kumar, R. and M. Mostafa, "Conventions For the Use of The Session Description Protocol (SDP) for ATM Bearer Connections", RFC 3108, May 2001.
[3] Kumar，R.和M.Mostafa，“ATM承载连接使用会话描述协议（SDP）的公约”，RFC 3108，2001年5月。
[4] Schulzrinne, H., Casner, S, Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[4] Schulzrinne，H.，Casner，S，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[5] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996.
[5] Schulzrinne，H.，“具有最小控制的音频和视频会议的RTP配置文件”，RFC 1890，1996年1月。
15 Informative References
15参考资料
[6] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000.
[6] Handley，M.，Perkins，C.和E.Whelan，“会话公告协议”，RFC 29742000年10月。
[7] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[7] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[8] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[8] Schulzrinne，H.，Rao，A.和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[9] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[9] Schulzrinne，H.和S.Petrack，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 28332000年5月。
[10] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[10] Handley，M.，Schulzrinne，H.，Schooler，E.和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
16 Authors' Addresses
16作者地址
Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936
Jonathan Rosenberg dynamicsoft 72 Eagle Rock大道一楼东汉诺威，NJ 07936
EMail: jdrosen@dynamicsoft.com
EMail: jdrosen@dynamicsoft.com
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA
美国纽约州纽约市阿姆斯特丹大道1214号哥伦比亚大学计算机科学系
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。