Network Working Group G. Camarillo
Request for Comments: 3388 G. Eriksson
Category: Standards Track J. Holler
Ericsson
H. Schulzrinne
Columbia University
December 2002
Network Working Group G. Camarillo
Request for Comments: 3388 G. Eriksson
Category: Standards Track J. Holler
Ericsson
H. Schulzrinne
Columbia University
December 2002
Grouping of Media Lines in 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 two Session Description Protocol (SDP) attributes: "group" and "mid". They allow to group together several "m" lines for two different purposes: for lip synchronization and for receiving media from a single flow (several media streams) that are encoded in different formats during a particular session, on different ports and host interfaces.
本文档定义了两个会话描述协议（SDP）属性：“组”和“mid”。它们允许将多条“m”线组合在一起，用于两个不同的目的：用于lip同步和从单个流（多个媒体流）接收媒体，这些流在特定会话期间在不同端口和主机接口上以不同格式编码。
Table of Contents
目录
1. Introduction.................................................. 2
2. Terminology................................................... 2
3. Media Stream Identification Attribute......................... 3
4. Group Attribute............................................... 3
5. Use of "group" and "mid"...................................... 3
6. Lip Synchronization (LS)...................................... 4
6.1 Example of LS............................................. 5
7. Flow Identification (FID)..................................... 5
7.1 SIP and Cellular Access................................... 6
7.2 DTMF Tones................................................ 6
7.3 Media Flow Definition..................................... 6
7.4 FID Semantics............................................. 7
7.4.1 Examples of FID..................................... 8
7.5 Scenarios that FID does not Cover........................ 11
1. Introduction.................................................. 2
2. Terminology................................................... 2
3. Media Stream Identification Attribute......................... 3
4. Group Attribute............................................... 3
5. Use of "group" and "mid"...................................... 3
6. Lip Synchronization (LS)...................................... 4
6.1 Example of LS............................................. 5
7. Flow Identification (FID)..................................... 5
7.1 SIP and Cellular Access................................... 6
7.2 DTMF Tones................................................ 6
7.3 Media Flow Definition..................................... 6
7.4 FID Semantics............................................. 7
7.4.1 Examples of FID..................................... 8
7.5 Scenarios that FID does not Cover........................ 11
7.5.1 Parallel Encoding Using Different Codecs........... 11
7.5.2 Layered Encoding................................... 12
7.5.3 Same IP Address and Port Number.................... 12
8. Usage of the "group" Attribute in SIP........................ 13
8.1 Mid Value in Answers..................................... 13
8.1.1 Example............................................ 14
8.2 Group Value in Answers................................... 15
8.2.1 Example............................................ 15
8.3 Capability Negotiation................................... 16
8.3.1 Example............................................ 17
8.4 Backward Compatibility................................... 17
8.4.1 Offerer does not Support "group"................... 17
8.4.2 Answerer does not Support "group".................. 17
9. Security Considerations................................... 18
10. IANA Considerations....................................... 18
11. Acknowledgements.......................................... 19
12. References................................................ 19
13. Authors' Addresses........................................ 20
14. Full Copyright Statement.................................. 21
7.5.1 Parallel Encoding Using Different Codecs........... 11
7.5.2 Layered Encoding................................... 12
7.5.3 Same IP Address and Port Number.................... 12
8. Usage of the "group" Attribute in SIP........................ 13
8.1 Mid Value in Answers..................................... 13
8.1.1 Example............................................ 14
8.2 Group Value in Answers................................... 15
8.2.1 Example............................................ 15
8.3 Capability Negotiation................................... 16
8.3.1 Example............................................ 17
8.4 Backward Compatibility................................... 17
8.4.1 Offerer does not Support "group"................... 17
8.4.2 Answerer does not Support "group".................. 17
9. Security Considerations................................... 18
10. IANA Considerations....................................... 18
11. Acknowledgements.......................................... 19
12. References................................................ 19
13. Authors' Addresses........................................ 20
14. Full Copyright Statement.................................. 21
An SDP session description typically contains one or more media lines - they are commonly known as "m" lines. When a session description contains more than one "m" line, SDP does not provide any means to express a particular relationship between two or more of them. When an application receives an SDP session description with more than one "m" line, it is up to the application what to do with them. SDP does not carry any information about grouping media streams.
SDP会话描述通常包含一个或多个媒体行，通常称为“m”行。当会话描述包含多个“m”行时，SDP不提供任何方法来表示两个或多个“m”行之间的特定关系。当应用程序收到带有多行“m”的SDP会话描述时，由应用程序决定如何处理它们。SDP不携带关于分组媒体流的任何信息。
While in some environments this information can be carried out of band, it would be desirable to have extensions to SDP that allow the expression of how different media streams within a session description relate to each other. This document defines such extensions.
虽然在某些环境中，该信息可以带外执行，但希望对SDP进行扩展，以允许表达会话描述中的不同媒体流如何相互关联。本文档定义了此类扩展。
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 BCP 14, RFC 2119 [1] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释，并指出合规实施的要求级别。
A new "media stream identification" media attribute is defined. It is used for identifying media streams within a session description. Its formatting in SDP [2] is described by the following BNF:
定义了新的“媒体流标识”媒体属性。它用于识别会话描述中的媒体流。SDP[2]中的格式由以下BNF描述：
mid-attribute = "a=mid:" identification-tag
identification-tag = token
mid-attribute = "a=mid:" identification-tag
identification-tag = token
The identification tag MUST be unique within an SDP session description.
标识标签在SDP会话描述中必须是唯一的。
A new "group" session-level attribute is defined. It is used for grouping together different media streams. Its formatting in SDP is described by the following BNF:
定义了一个新的“组”会话级别属性。它用于将不同的媒体流分组在一起。SDP中的格式由以下BNF描述：
group-attribute = "a=group:" semantics
*(space identification-tag)
semantics = "LS" | "FID"
group-attribute = "a=group:" semantics
*(space identification-tag)
semantics = "LS" | "FID"
This document defines two standard semantics: LS (Lip Synchronization) and FID (Flow Identification). Further semantics need to be defined in a standards-track document. However, defining new semantics apart from LS and FID is discouraged. Instead, it is RECOMMENDED to use other session description mechanisms such as SDPng.
本文档定义了两种标准语义：LS（Lip同步）和FID（流标识）。需要在标准跟踪文档中定义进一步的语义。然而，不鼓励在LS和FID之外定义新的语义。相反，建议使用其他会话描述机制，如SDPng。
All the "m" lines of a session description that uses "group" MUST be identified with a "mid" attribute whether they appear in the group line(s) or not. If a session description contains at least one "m" line that has no "mid" identification the application MUST NOT perform any grouping of media lines.
会话描述中使用“组”的所有“m”行必须用“mid”属性标识，无论它们是否出现在组行中。如果会话描述至少包含一个没有“mid”标识的“m”行，则应用程序不得执行任何媒体行分组。
"a=group" lines are used to group together several "m" lines that are identified by their "mid" attribute. "a=group" lines that contain identification-tags that do not correspond to any "m" line within the session description MUST be ignored. The application acts as if the "a=group" line did not exist. The behavior of an application receiving an SDP with grouped "m" lines is defined by the semantics field in the "a=group" line.
“a=group”行用于将由其“mid”属性标识的多个“m”行组合在一起。必须忽略包含与会话描述中的任何“m”行不对应的标识标记的“a=组”行。应用程序的行为就像“a=group”行不存在一样。接收带有分组“m”行的SDP的应用程序的行为由“a=group”行中的语义字段定义。
There MAY be several "a=group" lines in a session description. All the "a=group" lines of a session description MAY or MAY NOT use the same semantics. An "m" line identified by its "mid" attribute MAY appear in more than one "a=group" line as long as the "a=group" lines use different semantics. An "m" line identified by its "mid" attribute MUST NOT appear in more than one "a=group" line using the same semantics.
会话描述中可能有多行“a=group”。会话描述的所有“a=group”行可能使用相同的语义，也可能不使用相同的语义。由“mid”属性标识的“m”行可能出现在多个“a=group”行中，只要“a=group”行使用不同的语义。由“mid”属性标识的“m”行不得出现在使用相同语义的多个“a=group”行中。
An application that receives a session description that contains "m" lines that are grouped together using LS semantics MUST synchronize the playout of the corresponding media streams. Note that LS semantics not only apply to a video stream that has to be synchronized with an audio stream. The playout of two streams of the same type can be synchronized as well.
接收包含使用LS语义分组在一起的“m”行的会话描述的应用程序必须同步相应媒体流的播放。注意，LS语义不仅适用于必须与音频流同步的视频流。相同类型的两个流的播放也可以同步。
For RTP streams synchronization is typically performed using RTCP, which provides enough information to map time stamps from the different streams into a wall clock. However, the concept of media stream synchronization MAY also apply to media streams that do not make use of RTP. If this is the case, the application MUST recover the original timing relationship between the streams using whatever available mechanism.
对于RTP流，通常使用RTCP执行同步，RTCP提供足够的信息将不同流的时间戳映射到墙上的时钟。然而，媒体流同步的概念也可以应用于不使用RTP的媒体流。如果是这种情况，应用程序必须使用任何可用机制恢复流之间的原始定时关系。
The following example shows a session description of a conference that is being multicast. The first media stream (mid:1) contains the voice of the speaker who speaks in English. The second media stream (mid:2) contains the video component and the third (mid:3) media stream carries the translation to Spanish of what he is saying. The first and the second media streams MUST be synchronized.
以下示例显示正在进行多播的会议的会话描述。第一个媒体流（mid:1）包含讲英语的人的声音。第二个媒体流（mid:2）包含视频组件，第三个媒体流（mid:3）包含他所说内容的西班牙语翻译。第一和第二媒体流必须同步。
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
t=0 0
c=IN IP4 224.2.17.12/127
a=group:LS 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=video 30002 RTP/AVP 31
a=mid:2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation
a=mid:3
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
t=0 0
c=IN IP4 224.2.17.12/127
a=group:LS 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=video 30002 RTP/AVP 31
a=mid:2
m=audio 30004 RTP/AVP 0
i=This media stream contains the Spanish translation
a=mid:3
Note that although the third media stream is not present in the group line, it still MUST contain a mid attribute (mid:3), as stated before.
请注意，尽管第三个媒体流不在组行中，但它仍然必须包含mid属性（mid:3），如前所述。
An "m" line in an SDP session description defines a media stream. However, SDP does not define what a media stream is. This definition can be found in the RTSP specification. The RTSP RFC [5] defines a media stream as "a single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. When using RTP, a stream consists of all RTP and RTCP packets created by a source within an RTP session".
SDP会话描述中的“m”行定义媒体流。然而，SDP并没有定义什么是媒体流。该定义可在RTSP规范中找到。RTSP RFC[5]将媒体流定义为“单个媒体实例，例如音频流或视频流以及单个白板或共享应用程序组。使用RTP时，流由RTP会话中源创建的所有RTP和RTCP数据包组成”。
This definition assumes that a single audio (or video) stream maps into an RTP session. The RTP RFC [6] defines an RTP session as follows: "For each participant, the session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP)".
此定义假定单个音频（或视频）流映射到RTP会话。RTP RFC[6]对RTP会话的定义如下：“对于每个参与者，会话由一对特定的目标传输地址（一个网络地址加上RTP和RTCP的端口对）定义”。
While the previous definitions cover the most common cases, there are situations where a single media instance, (e.g., an audio stream or a video stream) is sent using more than one RTP session. Two examples (among many others) of this kind of situation are cellular systems using SIP [3] and systems receiving DTMF tones on a different host than the voice.
虽然前面的定义涵盖了最常见的情况，但也存在使用多个RTP会话发送单个媒体实例（例如，音频流或视频流）的情况。这种情况的两个例子（在许多其他例子中）是使用SIP[3]的蜂窝系统和在不同于语音的主机上接收DTMF音调的系统。
Systems using a cellular access and SIP as a signalling protocol need to receive media over the air. During a session the media can be encoded using different codecs. The encoded media has to traverse the radio interface. The radio interface is generally characterized by being bit error prone and associated with relatively high packet transfer delays. In addition, radio interface resources in a cellular environment are scarce and thus expensive, which calls for special measures in providing a highly efficient transport. In order to get an appropriate speech quality in combination with an efficient transport, precise knowledge of codec properties are required so that a proper radio bearer for the RTP session can be configured before transferring the media. These radio bearers are dedicated bearers per media type, i.e., codec.
使用蜂窝接入和SIP作为信令协议的系统需要通过空中接收媒体。在会话期间，可以使用不同的编解码器对媒体进行编码。编码媒体必须穿过无线电接口。无线电接口的一般特征是容易发生比特错误，并且与相对较高的分组传输延迟相关。此外，蜂窝环境中的无线电接口资源稀缺，因此价格昂贵，这就需要采取特殊措施来提供高效的传输。为了结合有效的传输获得适当的语音质量，需要对编解码器属性有精确的了解，以便在传输媒体之前为RTP会话配置适当的无线电承载。这些无线电承载是每种媒体类型的专用承载，即编解码器。
Cellular systems typically configure different radio bearers on different port numbers. Therefore, incoming media has to have different destination port numbers for the different possible codecs in order to be routed properly to the correct radio bearer. Thus, this is an example in which several RTP sessions are used to carry a single media instance (the encoded speech from the sender).
蜂窝系统通常在不同的端口号上配置不同的无线电承载。因此，为了正确地路由到正确的无线电承载，传入媒体必须具有不同可能编解码器的不同目标端口号。因此，这是一个示例，其中几个RTP会话用于承载单个媒体实例（来自发送方的编码语音）。
Some voice sessions include DTMF tones. Sometimes the voice handling is performed by a different host than the DTMF handling. It is common to have an application server in the network gathering DTMF tones for the user while the user receives the encoded speech on his user agent. In this situations it is necessary to establish two RTP sessions: one for the voice and the other for the DTMF tones. Both RTP sessions are logically part of the same media instance.
一些语音会话包括DTMF音调。有时，语音处理由不同于DTMF处理的主机执行。当用户在其用户代理上接收编码语音时，网络中的应用服务器通常为用户收集DTMF音调。在这种情况下，有必要建立两个RTP会话：一个用于语音，另一个用于DTMF音调。两个RTP会话在逻辑上是同一媒体实例的一部分。
The previous examples show that the definition of a media stream in [5] do not cover some scenarios. It cannot be assumed that a single media instance maps into a single RTP session. Therefore, we introduce the definition of a media flow:
前面的示例表明[5]中的媒体流定义没有涵盖某些场景。不能假设单个媒体实例映射到单个RTP会话。因此，我们引入媒体流的定义：
Media flow consists of a single media instance, e.g., an audio stream or a video stream as well as a single whiteboard or shared application group. When using RTP, a media flow comprises one or more RTP sessions.
媒体流包括单个媒体实例，例如音频流或视频流以及单个白板或共享应用程序组。当使用RTP时，媒体流包括一个或多个RTP会话。
Several "m" lines grouped together using FID semantics form a media flow. A media agent handling a media flow that comprises several "m" lines MUST send a copy of the media to every "m" line part of the flow as long as the codecs and the direction attribute present in a particular "m" line allow it.
使用FID语义将几个“m”行组合在一起，形成一个媒体流。处理包含多个“m”行的媒体流的媒体代理必须向流的每个“m”行部分发送媒体副本，只要特定“m”行中存在的编解码器和方向属性允许。
It is assumed that the application uses only one codec at a time to encode the media produced. This codec MAY change dynamically during the session, but at any particular moment only one codec is in use.
假设应用程序一次仅使用一个编解码器对生成的媒体进行编码。此编解码器在会话期间可能会动态更改，但在任何特定时刻，只有一个编解码器在使用。
The application encodes the media using the current codec and checks one by one all the "m" lines that are part of the flow. If a particular "m" line contains the codec being used and the direction attribute is "sendonly" or "sendrecv", a copy of the encoded media is sent to the address/port specified in that particular media stream. If either the "m" line does not contain the codec being used or the direction attribute is neither "sendonly" nor "sendrecv", nothing is sent over this media stream.
应用程序使用当前编解码器对媒体进行编码，并逐个检查流中的所有“m”行。如果特定的“m”行包含正在使用的编解码器，且方向属性为“sendonly”或“sendrecv”，则编码媒体的副本将发送到该特定媒体流中指定的地址/端口。如果“m”行不包含正在使用的编解码器，或者“方向”属性既不是“sendonly”也不是“sendrecv”，则不会通过此媒体流发送任何内容。
The application typically ends up sending media to different destinations (IP address/port number) depending on the codec used at any moment.
应用程序通常会将媒体发送到不同的目的地（IP地址/端口号），具体取决于随时使用的编解码器。
The session description below might be sent by a SIP user agent using a cellular access. The user agent supports GSM on port 30000 and AMR on port 30002. When the remote party sends GSM, it will send RTP packets to port number 30000. When AMR is the codec chosen, packets will be sent to port 30002. Note that the remote party can switch between both codecs dynamically in the middle of the session. However, in this example, only one media stream at a time carries voice. The other remains "muted" while its corresponding codec is not in use.
下面的会话描述可能由SIP用户代理使用蜂窝访问发送。用户代理在端口30000上支持GSM，在端口30002上支持AMR。当远程方发送GSM时，它将向端口号30000发送RTP数据包。当选择AMR编解码器时，数据包将发送到端口30002。请注意，远程方可以在会话中间动态地切换两个编解码器。然而，在此示例中，一次只有一个媒体流承载语音。另一个在其相应的编解码器未使用时保持“静音”。
v=0
o=Laura 289083124 289083124 IN IP4 two.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2
m=audio 30000 RTP/AVP 3
a=rtpmap:3 GSM/8000
a=mid:1
m=audio 30002 RTP/AVP 97
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2;
mode-change-neighbor; maxframes=1
a=mid:2
v=0
o=Laura 289083124 289083124 IN IP4 two.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2
m=audio 30000 RTP/AVP 3
a=rtpmap:3 GSM/8000
a=mid:1
m=audio 30002 RTP/AVP 97
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2;
mode-change-neighbor; maxframes=1
a=mid:2
(The linebreak in the fmtp line accommodates RFC formatting restrictions; SDP does not have continuation lines.)
（fmtp行中的换行符符合RFC格式限制；SDP没有续行。）
In the previous example, a system receives media on the same IP address on different port numbers. The following example shows how a system can receive different codecs on different IP addresses.
在前面的示例中，系统在不同端口号的相同IP地址上接收媒体。下面的示例显示了系统如何在不同的IP地址上接收不同的编解码器。
v=0
o=Laura 289083124 289083124 IN IP4 three.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2
m=audio 20000 RTP/AVP 0
c=IN IP4 131.160.1.111
a=rtpmap:0 PCMU/8000
a=mid:1
m=audio 30002 RTP/AVP 97
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2;
mode-change-neighbor; maxframes=1
a=mid:2
v=0
o=Laura 289083124 289083124 IN IP4 three.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2
m=audio 20000 RTP/AVP 0
c=IN IP4 131.160.1.111
a=rtpmap:0 PCMU/8000
a=mid:1
m=audio 30002 RTP/AVP 97
a=rtpmap:97 AMR/8000
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2;
mode-change-neighbor; maxframes=1
a=mid:2
(The linebreak in the fmtp line accomodates RFC formatting restrictions; SDP does not have continuation lines.)
（fmtp行中的换行符符合RFC格式限制；SDP没有续行。）
The cellular terminal of this example only supports the AMR codec. However, many current IP phones only support PCM (payload 0). In order to be able to interoperate with them, the cellular terminal uses a transcoder whose IP address is 131.160.1.111. The cellular terminal includes in its SDP support for PCM at that IP address. Remote systems will send AMR directly to the terminal but PCM will be sent to the transcoder. The transcoder will be configured (using whatever method) to convert the incoming PCM audio to AMR and send it to the terminal.
本示例的蜂窝终端仅支持AMR编解码器。但是，许多当前的IP电话仅支持PCM（有效负载0）。为了能够与它们互操作，蜂窝终端使用IP地址为131.160.1.111的转码器。蜂窝终端在其SDP支持中包括该IP地址处的PCM。远程系统将直接向终端发送AMR，但PCM将发送至转码器。将配置转码器（使用任何方法）将传入的PCM音频转换为AMR并发送到终端。
The next example shows how the "group" attribute used with FID semantics can indicate the use of two different codecs in the two directions of a bidirectional media stream.
下一个示例显示了与FID语义一起使用的“group”属性如何指示在双向媒体流的两个方向上使用两个不同的编解码器。
v=0
o=Laura 289083124 289083124 IN IP4 four.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=recvonly
a=mid:2
v=0
o=Laura 289083124 289083124 IN IP4 four.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=recvonly
a=mid:2
A user agent that receives the SDP above knows that at a certain moment it can send either PCM u-law to port number 30000 or PCM A-law to port number 30002. However, the media agent also knows that the other end will only send PCM u-law (payload 0).
接收上述SDP的用户代理知道，在某个时刻，它可以将PCM u-law发送到端口号30000或将PCM A-law发送到端口号30002。但是，媒体代理也知道另一端将只发送PCM u-law（有效负载0）。
The following example shows a session description with different "m" lines grouped together using FID semantics that contain the same codec.
下面的示例显示了一个会话描述，其中使用包含相同编解码器的FID语义将不同的“m”行分组在一起。
v=0
o=Laura 289083124 289083124 IN IP4 five.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2 3
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=mid:2
m=audio 20000 RTP/AVP 0 8
c=IN IP4 131.160.1.111
a=recvonly
a=mid:3
v=0
o=Laura 289083124 289083124 IN IP4 five.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2 3
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=mid:2
m=audio 20000 RTP/AVP 0 8
c=IN IP4 131.160.1.111
a=recvonly
a=mid:3
At a particular point in time, if the media agent is sending PCM u-law (payload 0), it sends RTP packets to 131.160.1.112 on port 30000 and to 131.160.1.111 on port 20000 (first and third "m" lines). If it is sending PCM A-law (payload 8), it sends RTP packets to 131.160.1.112 on port 30002 and to 131.160.1.111 on port 20000 (second and third "m" lines).
在特定时间点，如果媒体代理正在发送PCM u-law（有效负载0），则它会将RTP数据包发送到端口30000上的131.160.1.112和端口20000上的131.160.1.111（第一条和第三条“m”线）。如果它正在发送PCM A-law（有效负载8），它将RTP数据包发送到端口30002上的131.160.1.112和端口20000上的131.160.1.111（第二和第三条“m”线）。
The system that generated the SDP above supports PCM u-law on port 30000 and PCM A-law on port 30002. Besides, it uses an application server whose IP address is 131.160.1.111 that records the conversation. That is why the application server always receives a copy of the audio stream regardless of the codec being used at any given moment (it actually performs an RTP dump, so it can effectively receive any codec).
生成上述SDP的系统支持端口30000上的PCM u-law和端口30002上的PCM A-law。此外，它使用IP地址为131.160.1.111的应用服务器记录对话。这就是为什么应用服务器总是接收音频流的副本，而不管在任何给定时刻使用的编解码器是什么（它实际上执行RTP转储，因此可以有效地接收任何编解码器）。
Remember that if several "m" lines grouped together using FID semantics contain the same codec the media agent MUST send media over several RTP sessions at the same time.
请记住，如果使用FID语义分组在一起的多个“m”行包含相同的编解码器，则媒体代理必须同时通过多个RTP会话发送媒体。
The last example of this section deals with DTMF tones. DTMF tones can be transmitted using a regular voice codec or can be transmitted as telephony events. The RTP payload for DTMF tones treated as telephone events is described in RFC 2833 [7]. Below, there is an example of an SDP session description using FID semantics and this payload type.
本节的最后一个示例涉及DTMF音调。DTMF音调可以使用常规语音编解码器传输，也可以作为电话事件传输。RFC 2833[7]中描述了视为电话事件的DTMF音的RTP有效载荷。下面是一个使用FID语义和此有效负载类型的SDP会话描述示例。
v=0
o=Laura 289083124 289083124 IN IP4 six.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 20000 RTP/AVP 97
c=IN IP4 131.160.1.111
a=rtpmap:97 telephone-events
a=mid:2
v=0
o=Laura 289083124 289083124 IN IP4 six.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 20000 RTP/AVP 97
c=IN IP4 131.160.1.111
a=rtpmap:97 telephone-events
a=mid:2
The remote party would send PCM encoded voice (payload 0) to 131.160.1.112 and DTMF tones encoded as telephony events to 131.160.1.111. Note that only voice or DTMF is sent at a particular point of time. When DTMF tones are sent, the first media stream does not carry any data and, when voice is sent, there is no data in the second media stream. FID semantics provide different destinations for alternative codecs.
远程方将向131.160.1.112发送PCM编码的语音（有效载荷0），并向131.160.1.111发送DTMF编码的语音，作为电话事件。请注意，在特定时间点仅发送语音或DTMF。当发送DTMF音调时，第一媒体流不携带任何数据，当发送语音时，第二媒体流中没有数据。FID语义为备选编解码器提供了不同的目的地。
It is worthwhile mentioning some scenarios where the "group" attribute using existing semantics (particularly FID) might seem to be applicable but is not.
值得一提的是，在某些场景中，使用现有语义（特别是FID）的“group”属性似乎是适用的，但实际上并不适用。
FID semantics are useful when the application only uses one codec at a time. An application that encodes the same media using different codecs simultaneously MUST NOT use FID to group those media lines. Some systems that handle DTMF tones are a typical example of parallel encoding using different codecs.
当应用程序一次只使用一个编解码器时，FID语义非常有用。同时使用不同编解码器对同一媒体进行编码的应用程序不得使用FID对这些媒体行进行分组。一些处理DTMF音调的系统是使用不同编解码器进行并行编码的典型示例。
Some systems implement the RTP payload defined in RFC 2833, but when they send DTMF tones they do not mute the voice channel. Therefore, in effect they are sending two copies of the same DTMF tone: encoded as voice and encoded as a telephony event. When the receiver gets both copies, it typically uses the telephony event rather than the tone encoded as voice. FID semantics MUST NOT be used in this context to group both media streams since such a system is not using
一些系统实现RFC 2833中定义的RTP有效负载，但当它们发送DTMF音调时，不会使语音信道静音。因此，实际上他们发送的是同一DTMF音调的两个副本：编码为语音和编码为电话事件。当接收器获得两个副本时，它通常使用电话事件，而不是编码为语音的音调。在此上下文中，不能使用FID语义对两个媒体流进行分组，因为这样的系统不使用
alternative codecs but rather different parallel encodings for the same information.
可供选择的编解码器，但对相同信息采用不同的并行编码。
Layered encoding schemes encode media in different layers. Quality at the receiver varies depending on the number of layers received. SDP provides a means to group together contiguous multicast addresses that transport different layers. The "c" line below:
分层编码方案在不同的层中对媒体进行编码。接收器的质量取决于接收的层数。SDP提供了一种将传输不同层的连续多播地址分组的方法。下面的“c”行：
c=IN IP4 224.2.1.1/127/3
c=IN IP4 224.2.1.1/127/3
is equivalent to the following three "c" lines:
相当于以下三条“c”线：
c=IN IP4 224.2.1.1/127
c=IN IP4 224.2.1.2/127
c=IN IP4 224.2.1.3/127
c=IN IP4 224.2.1.1/127
c=IN IP4 224.2.1.2/127
c=IN IP4 224.2.1.3/127
FID MUST NOT be used to group "m" lines that do not represent the same information. Therefore, FID MUST NOT be used to group "m" lines that contain the different layers of layered encoding scheme. Besides, we do not define new group semantics to provide a more flexible way of grouping different layers because the already existing SDP mechanism covers the most useful scenarios.
不得使用FID对不代表相同信息的“m”行进行分组。因此，不得使用FID对包含分层编码方案不同层的“m”行进行分组。此外，我们没有定义新的组语义来提供更灵活的方式来分组不同的层，因为已经存在的SDP机制涵盖了最有用的场景。
If several codecs have to be sent to the same IP address and port, the traditional SDP syntax of listing several codecs in the same "m" line MUST be used. FID MUST NOT be used to group "m" lines with the same IP address/port. Therefore, an SDP like the one below MUST NOT be generated.
如果必须将多个编解码器发送到同一IP地址和端口，则必须使用在同一“m”行中列出多个编解码器的传统SDP语法。不得使用FID将具有相同IP地址/端口的“m”行分组。因此，不得生成如下SDP。
v=0
o=Laura 289083124 289083124 IN IP4 six.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30000 RTP/AVP 8
a=mid:2
v=0
o=Laura 289083124 289083124 IN IP4 six.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30000 RTP/AVP 8
a=mid:2
The correct SDP for the session above would be the following one:
上述会话的正确SDP如下所示：
v=0 o=Laura 289083124 289083124 IN IP4 six.example.com t=0 0 c=IN IP4 131.160.1.112 m=audio 30000 RTP/AVP 0 8
v=0 o=IP4 six.example.com中的Laura 289083124 289083124 t=0 c=IP4 131.160.1.112 m=audio 30000 RTP/AVP 0 8
If two "m" lines are grouped using FID they MUST differ in their transport addresses (i.e., IP address plus port).
如果使用FID对两条“m”线进行分组，则它们的传输地址（即IP地址加端口）必须不同。
SDP descriptions are used by several different protocols, SIP among them. We include a section about SIP because the "group" attribute will most likely be used mainly by SIP systems.
SDP描述由几种不同的协议使用，其中包括SIP。我们包含了一节关于SIP的内容，因为“group”属性很可能主要由SIP系统使用。
SIP [3] is an application layer protocol for establishing, terminating and modifying multimedia sessions. SIP carries session descriptions in the bodies of the SIP messages but is independent from the protocol used for describing sessions. SDP [2] is one of the protocols that can be used for this purpose.
SIP[3]是用于建立、终止和修改多媒体会话的应用层协议。SIP在SIP消息体中承载会话描述，但独立于用于描述会话的协议。SDP[2]是可用于此目的的协议之一。
At session establishment SIP provides a three-way handshake (INVITE-200 OK-ACK) between end systems. However, just two of these three messages carry SDP, as described in [4].
会话建立时，SIP在终端系统之间提供三方握手（INVITE-200 OK-ACK）。然而，这三条消息中只有两条携带SDP，如[4]所述。
The "mid" attribute is an identifier for a particular media stream. Therefore, the "mid" value in the offer MUST be the same as the "mid" value in the answer. Besides, subsequent offers (e.g., in a re-INVITE) SHOULD use the same "mid" value for the already existing media streams.
“mid”属性是特定媒体流的标识符。因此，报价中的“中间”值必须与答案中的“中间”值相同。此外，后续提供（例如，在重新邀请中）应该对已经存在的媒体流使用相同的“中间”值。
RFC 3264 [4] describes the usage of SDP in relation to SIP. The offerer and the answerer align their media description so that the nth media stream ("m=" line) in the offerer's session description corresponds to the nth media stream in the answerer's description.
RFC 3264[4]描述了SDP与SIP的关系。报价人和应答人对齐其媒体描述，以便报价人会话描述中的第n个媒体流（“m=”行）对应于应答人描述中的第n个媒体流。
The presence of the "group" attribute in an SDP session description does not modify this behavior.
SDP会话描述中存在“group”属性不会修改此行为。
Since the "mid" attribute provides a means to label "m" lines, it would be possible to perform media alignment using "mid" labels rather than matching nth "m" lines. However this would not bring any
由于“mid”属性提供了标记“m”行的方法，因此可以使用“mid”标签而不是匹配第n个“m”行来执行介质对齐。然而，这不会带来任何影响
gain and would add complexity to implementations. Therefore SIP systems MUST perform media alignment matching nth lines regardless of the presence of the "group" or "mid" attributes.
这将增加实现的复杂性。因此，无论是否存在“组”或“中间”属性，SIP系统都必须执行媒体对齐匹配第n行。
If a media stream that contained a particular "mid" identifier in the offer contains a different identifier in the answer the application ignores all the "mid" and "group" lines that might appear in the session description. The following example illustrates this scenario.
如果在报价中包含特定“mid”标识符的媒体流在应答中包含不同的标识符，则应用程序将忽略会话描述中可能出现的所有“mid”和“组”行。下面的示例演示了此场景。
Two SIP entities exchange SDPs during session establishment. The INVITE contains the SDP below:
两个SIP实体在会话建立期间交换SDP。邀请包含以下SDP：
v=0
o=Laura 289083124 289083124 IN IP4 seven.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2
m=audio 30000 RTP/AVP 0 8
a=mid:1
m=audio 30002 RTP/AVP 0 8
a=mid:2
v=0
o=Laura 289083124 289083124 IN IP4 seven.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2
m=audio 30000 RTP/AVP 0 8
a=mid:1
m=audio 30002 RTP/AVP 0 8
a=mid:2
The 200 OK response contains the following SDP:
200 OK响应包含以下SDP：
v=0
o=Bob 289083122 289083122 IN IP4 eigth.example.com
t=0 0
c=IN IP4 131.160.1.113
a=group:FID 1 2
m=audio 25000 RTP/AVP 0 8
a=mid:2
m=audio 25002 RTP/AVP 0 8
a=mid:1
v=0
o=Bob 289083122 289083122 IN IP4 eigth.example.com
t=0 0
c=IN IP4 131.160.1.113
a=group:FID 1 2
m=audio 25000 RTP/AVP 0 8
a=mid:2
m=audio 25002 RTP/AVP 0 8
a=mid:1
Since alignment of "m" lines is performed based on matching of nth lines, the first stream had "mid:1" in the INVITE and "mid:2" in the 200 OK. Therefore, the application MUST ignore every "mid" and "group" lines contained in the SDP.
由于“m”行的对齐是基于第n行的匹配来执行的，因此第一个流在INVITE中具有“mid:1”，在200 OK中具有“mid:2”。因此，应用程序必须忽略SDP中包含的每个“mid”和“group”行。
A well-behaved SIP user agent would have returned the SDP below in the 200 OK:
行为良好的SIP用户代理将在200 OK中返回以下SDP：
v=0
o=Bob 289083122 289083122 IN IP4 nine.example.com
t=0 0
c=IN IP4 131.160.1.113
a=group:FID 1 2
m=audio 25002 RTP/AVP 0 8
a=mid:1
m=audio 25000 RTP/AVP 0 8
a=mid:2
v=0
o=Bob 289083122 289083122 IN IP4 nine.example.com
t=0 0
c=IN IP4 131.160.1.113
a=group:FID 1 2
m=audio 25002 RTP/AVP 0 8
a=mid:1
m=audio 25000 RTP/AVP 0 8
a=mid:2
A SIP entity that receives an offer that contains an "a=group" line with semantics that it does not understand MUST return an answer without the "group" line. Note that, as it was described in the previous section, the "mid" lines MUST still be present in the answer.
接收包含“A=group”行且其语义不理解的要约的SIP实体必须返回不带“group”行的答案。请注意，如前一节所述，“中间”行必须仍然存在于答案中。
A SIP entity that receives an offer that contains an "a=group" line with semantics that are understood MUST return an answer that contains an "a=group" line with the same semantics. The identification-tags contained in this "a=group" lines MUST be the same that were received in the offer or a subset of them (zero identification-tags is a valid subset). When the identification-tags in the answer are a subset, the "group" value to be used in the session MUST be the one present in the answer.
接收到包含“A=group”行且其语义已被理解的要约的SIP实体必须返回包含具有相同语义的“A=group”行的应答。“a=组”行中包含的标识标签必须与报价中收到的标识标签或其子集相同（零标识标签为有效子集）。当答案中的标识标签是子集时，会话中使用的“组”值必须是答案中的值。
SIP entities refuse media streams by setting the port to zero in the corresponding "m" line. "a=group" lines MUST NOT contain identification-tags that correspond to "m" lines with port zero.
SIP实体通过在相应的“m”行中将端口设置为零来拒绝媒体流。“a=组”行不得包含与端口为零的“m”行相对应的标识标签。
Note that grouping of m lines MUST always be requested by the offerer, never by the answerer. Since SIP provides a two-way SDP exchange, an answerer that requested grouping would not know whether the "group" attribute was accepted by the offerer or not. An answerer that wants to group media lines SHOULD issue another offer after having responded to the first one (in a re-INVITE for instance).
请注意，m行的分组必须始终由报价人请求，而不是由应答人请求。由于SIP提供双向SDP交换，请求分组的应答者将不知道“组”属性是否被报价人接受。想要对媒体线路进行分组的应答者应在回应第一个报价后再发出另一个报价（例如，在重新邀请中）。
The example below shows how the callee refuses a media stream offered by the caller by setting its port number to zero. The "mid" value corresponding to that media stream is removed from the "group" value in the answer.
下面的示例显示被调用者如何通过将端口号设置为零来拒绝调用者提供的媒体流。与该媒体流相对应的“中间”值将从应答中的“组”值中删除。
SDP in the INVITE from caller to callee:
从呼叫者到被呼叫者的邀请中的SDP：
v=0
o=Laura 289083124 289083124 IN IP4 ten.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2 3
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=mid:2
m=audio 30004 RTP/AVP 3
a=mid:3
v=0
o=Laura 289083124 289083124 IN IP4 ten.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID 1 2 3
m=audio 30000 RTP/AVP 0
a=mid:1
m=audio 30002 RTP/AVP 8
a=mid:2
m=audio 30004 RTP/AVP 3
a=mid:3
SDP in the INVITE from callee to caller:
从被叫方到主叫方的邀请中的SDP：
v=0
o=Bob 289083125 289083125 IN IP4 eleven.example.com
t=0 0
c=IN IP4 131.160.1.113
a=group:FID 1 3
m=audio 20000 RTP/AVP 0
a=mid:1
m=audio 0 RTP/AVP 8
a=mid:2
m=audio 20002 RTP/AVP 3
a=mid:3
v=0
o=Bob 289083125 289083125 IN IP4 eleven.example.com
t=0 0
c=IN IP4 131.160.1.113
a=group:FID 1 3
m=audio 20000 RTP/AVP 0
a=mid:1
m=audio 0 RTP/AVP 8
a=mid:2
m=audio 20002 RTP/AVP 3
a=mid:3
A client that understands "group" and "mid" but does not want to make use of them in a particular session MAY want to indicate that it supports them. If a client decides to do that, it SHOULD add an "a=group" line with no identification-tags for every semantics it understands.
理解“组”和“mid”但不想在特定会话中使用它们的客户端可能希望表明它支持它们。如果客户机决定这样做，它应该添加一个“a=group”行，它所理解的每一种语义都没有标识标签。
If a server receives an offer that contains empty "a=group" lines, it SHOULD add its capabilities also in the form of empty "a=group" lines to its answer.
如果服务器收到包含空“a=group”行的报价，则应以空“a=group”行的形式将其功能添加到其答案中。
A system that supports both LS and FID semantics but does not want to group any media stream for this particular session generates the following SDP:
支持LS和FID语义但不希望为此特定会话对任何媒体流进行分组的系统将生成以下SDP：
v=0
o=Bob 289083125 289083125 IN IP4 twelve.example.com
t=0 0
c=IN IP4 131.160.1.113
a=group:LS
a=group:FID
m=audio 20000 RTP/AVP 0 8
v=0
o=Bob 289083125 289083125 IN IP4 twelve.example.com
t=0 0
c=IN IP4 131.160.1.113
a=group:LS
a=group:FID
m=audio 20000 RTP/AVP 0 8
The server that receives that offer supports FID but not LS. It responds with the SDP below:
接收该报价的服务器支持FID，但不支持LS。它用以下SDP进行响应：
v=0
o=Laura 289083124 289083124 IN IP4 thirteen.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID
m=audio 30000 RTP/AVP 0
v=0
o=Laura 289083124 289083124 IN IP4 thirteen.example.com
t=0 0
c=IN IP4 131.160.1.112
a=group:FID
m=audio 30000 RTP/AVP 0
This document does not define any SIP "Require" header. Therefore, if one of the SIP user agents does not understand the "group" attribute the standard SDP fall back mechanism MUST be used (attributes that are not understood are simply ignored).
本文档未定义任何SIP“Require”标题。因此，如果其中一个SIP用户代理不理解“组”属性，则必须使用标准SDP回退机制（不理解的属性将被忽略）。
This situation does not represent a problem because grouping requests are always performed by offerers, not by answerers. If the offerer does not support "group" this attribute will just not be used.
这种情况并不代表问题，因为分组请求总是由提供方执行，而不是由应答方执行。如果报价人不支持“组”，则不使用此属性。
The answerer will ignore the "group" attribute, since it does not understand it (it will also ignore the "mid" attribute). For LS semantics, the answerer might decide to perform or to not perform synchronization between media streams.
回答者将忽略“group”属性，因为它不理解它（它也将忽略“mid”属性）。对于LS语义，应答者可能决定在媒体流之间执行或不执行同步。
For FID semantics, the answerer will consider that the session comprises several media streams.
对于FID语义，应答者将考虑会话包括多个媒体流。
Different implementations would behave in different ways.
不同的实现将以不同的方式运行。
In the case of audio and different "m" lines for different codecs an implementation might decide to act as a mixer with the different incoming RTP sessions, which is the correct behavior.
在音频和不同编解码器的不同“m”线的情况下，实现可能会决定充当不同传入RTP会话的混音器，这是正确的行为。
An implementation might also decide to refuse the request (e.g., 488 Not acceptable here or 606 Not Acceptable) because it contains several "m" lines. In this case, the server does not support the type of session that the caller wanted to establish. In case the client is willing to establish a simpler session anyway, he SHOULD re-try the request without "group" attribute and only one "m" line per flow.
实现还可能决定拒绝请求（例如，此处488不可接受或606不可接受），因为它包含多个“m”行。在这种情况下，服务器不支持调用方想要建立的会话类型。如果客户机愿意建立一个更简单的会话，他应该在没有“group”属性和每个流只有一行“m”的情况下重新尝试请求。
Using the "group" parameter with FID semantics, an entity that managed to modify the session descriptions exchanged between the participants to establish a multimedia session could force the participants to send a copy of the media to any particular destination.
使用具有FID语义的“group”参数，一个能够修改参与者之间交换的会话描述以建立多媒体会话的实体可以强制参与者向任何特定目的地发送媒体副本。
Integrity mechanism provided by protocols used to exchange session descriptions and media encryption can be used to prevent this attack.
用于交换会话描述和媒体加密的协议提供的完整性机制可用于防止此攻击。
This document defines two SDP attributes: "mid" and "group".
本文档定义了两个SDP属性：“mid”和“group”。
The "mid" attribute is used to identify media streams within a session description and its format is defined in Section 3.
“mid”属性用于标识会话描述中的媒体流，其格式在第3节中定义。
The "group" attribute is used for grouping together different media streams and its format is defined in Section 4.
“group”属性用于将不同的媒体流分组在一起，其格式在第4节中定义。
This document defines a framework to group media lines in SDP using different semantics. Semantics to be used with this framework are registered by the IANA when they are published in standards track RFCs.
本文档定义了一个使用不同语义对SDP中的媒体行进行分组的框架。与此框架一起使用的语义在标准跟踪RFC中发布时由IANA注册。
The IANA Considerations section of the RFC MUST include the following information, which appears in the IANA registry along with the RFC number of the publication.
RFC的IANA注意事项部分必须包括以下信息，这些信息与出版物的RFC编号一起出现在IANA注册表中。
o A brief description of the semantics.
o 对语义的简要描述。
o Token to be used within the group attribute. This token may be of any length, but SHOULD be no more than four characters long.
o 要在组属性中使用的标记。此标记可以是任意长度，但长度不应超过四个字符。
o Reference to an standards track RFC.
o 参考标准跟踪RFC。
The only entries in the registry for the time being are:
目前注册表中的唯一条目为：
Semantics Token Reference
------------------- ----- -----------
Lip synchronization LS RFC 3388
Flow identification FID RFC 3388
Semantics Token Reference
------------------- ----- -----------
Lip synchronization LS RFC 3388
Flow identification FID RFC 3388
The authors would like to thank Jonathan Rosenberg, Adam Roach, Orit Levin and Joerg Ott for their feedback on this document.
作者感谢Jonathan Rosenberg、Adam Roach、Orit Levin和Joerg Ott对本文件的反馈。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[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] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with the Session Description Protocol (SDP)", RFC 3264, June 2002.
[4] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[5] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[5] Schulzrinne，H.，Rao，A.和R.Lanphier，“实时流协议（RTSP）”，RFC2326，1998年4月。
[6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[6] Schulzrinne，H.，Casner，S.，Frederick，R.和V.Jacobson，“RTP：实时应用的传输协议”，RFC 1889，1996年1月。
[7] Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.
[7] Schulzrinne，H.和S.Petrack，“DTMF数字、电话音和电话信号的RTP有效载荷”，RFC 28332000年5月。
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
Gonzalo Camarillo Ericsson高级信号研究实验室FIN-02420 Jorvas芬兰
Phone: +358 9 299 3371
Fax: +358 9 299 3052
EMail: Gonzalo.Camarillo@ericsson.com
Phone: +358 9 299 3371
Fax: +358 9 299 3052
EMail: Gonzalo.Camarillo@ericsson.com
Jan Holler Ericsson Research S-16480 Stockholm Sweden
瑞典斯德哥尔摩爱立信研究院S-16480
Phone: +46 8 58532845
Fax: +46 8 4047020
EMail: Jan.Holler@era.ericsson.se
Phone: +46 8 58532845
Fax: +46 8 4047020
EMail: Jan.Holler@era.ericsson.se
Goran AP Eriksson Ericsson Research S-16480 Stockholm Sweden
Goran AP Eriksson爱立信研究公司S-16480瑞典斯德哥尔摩
Phone: +46 8 58531762
Fax: +46 8 4047020
EMail: Goran.AP.Eriksson@era.ericsson.se
Phone: +46 8 58531762
Fax: +46 8 4047020
EMail: Goran.AP.Eriksson@era.ericsson.se
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编辑功能的资金目前由互联网协会提供。