Network Working Group G. Camarillo
Request for Comments: 3959 Ericsson
Category: Standards Track December 2004
Network Working Group G. Camarillo
Request for Comments: 3959 Ericsson
Category: Standards Track December 2004
The Early Session Disposition Type for the Session Initiation Protocol (SIP)
会话启动协议（SIP）的早期会话处置类型
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document defines a new disposition type (early-session) for the Content-Disposition header field in the Session Initiation Protocol (SIP). The treatment of "early-session" bodies is similar to the treatment of "session" bodies. That is, they follow the offer/answer model. Their only difference is that session descriptions whose disposition type is "early-session" are used to establish early media sessions within early dialogs, as opposed to regular sessions within regular dialogs.
本文档为会话启动协议（SIP）中的内容处置头字段定义了新的处置类型（早期会话）。对“早期会议”机构的处理类似于对“会议”机构的处理。也就是说，他们遵循提供/回答模式。它们唯一的区别在于，处置类型为“早期会话”的会话描述用于在早期对话框中建立早期媒体会话，而不是在常规对话框中建立常规会话。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Issues Related to Early Media Session Establishment . . . . . 2
4. The Early Session Disposition Type . . . . . . . . . . . . . . 4
5. Preconditions . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Option tag . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informational References . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Issues Related to Early Media Session Establishment . . . . . 2
4. The Early Session Disposition Type . . . . . . . . . . . . . . 4
5. Preconditions . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Option tag . . . . . . . . . . . . . . . . . . . . . . . . . . 5
7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informational References . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 11
Early media refers to media (e.g., audio and video) that is exchanged before a particular session is accepted by the called user. Within a dialog, early media occurs from the moment the initial INVITE is sent until the User Agent Server (UAS) generates a final response. It may be unidirectional or bidirectional, and can be generated by the caller, the callee, or both. Typical examples of early media generated by the callee are ringing tone and announcements (e.g., queuing status). Early media generated by the caller typically consists of voice commands or dual tone multi-frequency (DTMF) tones to drive interactive voice response (IVR) systems.
早期媒体是指在被呼叫用户接受特定会话之前交换的媒体（例如音频和视频）。在对话框中，早期媒体从发送初始邀请开始，直到用户代理服务器（UAS）生成最终响应。它可以是单向的或双向的，并且可以由调用者、被调用者或两者生成。被叫方生成的早期媒体的典型示例是铃声和公告（例如排队状态）。呼叫方生成的早期媒体通常由语音命令或双音多频（DTMF）音调组成，以驱动交互式语音应答（IVR）系统。
The basic SIP specification (RFC 3261 [2]) only supports very simple early media mechanisms. These simple mechanisms have a number of problems related to forking and security, and do not satisfy the requirements of most applications. RFC 3960 [8] goes beyond the mechanisms defined in RFC 3261 [2] and describes two models of early media using SIP: the gateway model and the application server model.
基本SIP规范（RFC3261[2]）只支持非常简单的早期媒体机制。这些简单的机制存在许多与分叉和安全性相关的问题，不能满足大多数应用程序的要求。RFC 3960[8]超越了RFC 3261[2]中定义的机制，并描述了使用SIP的早期媒体的两种模型：网关模型和应用服务器模型。
Although both early media models described in RFC 3960 [8] are superior to the one specified in RFC 3261 [2], the gateway model still presents a set of issues. In particular, the gateway model does not work well with forking. Nevertheless, the gateway model is needed because some SIP entities (in particular, some gateways) cannot implement the application server model.
尽管RFC 3960[8]中描述的两种早期媒体模型都优于RFC 3261[2]中指定的模型，但网关模型仍然存在一系列问题。特别是，网关模型不能很好地用于分叉。然而，由于某些SIP实体（特别是某些网关）无法实现应用服务器模型，因此需要网关模型。
The application server model addresses some of the issues present in the gateway model. This model uses the early-session disposition type specified in this document.
应用服务器模型解决了网关模型中存在的一些问题。此模型使用本文档中指定的早期会话处置类型。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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]中的描述进行解释，并指出合规实施的要求级别。
Traditionally, early media sessions have been established in the same way as regular sessions. That is, using an offer/answer exchange where the disposition type of the session descriptions is "session". Application servers perform an offer/answer exchange with the User Agent Client (UAC) to exchange early media exclusively, while UASs use the same offer/answer exchange, first to exchange early media, and once the regular dialog is established, to exchange regular
传统上，早期媒体会议与定期会议的方式相同。也就是说，使用会话描述的处置类型为“会话”的提供/应答交换。应用程序服务器与用户代理客户端（UAC）执行提供/应答交换，以专门交换早期介质，而UAS使用相同的提供/应答交换，首先交换早期介质，一旦建立了常规对话框，则交换常规介质
media. This way of establishing early media sessions is known as the gateway model [8], which presents some issues related to forking and security. These issues exist when this model is used by either an application server or by a UAS.
媒体这种建立早期媒体会话的方法称为网关模型[8]，它提出了一些与分叉和安全性相关的问题。当应用服务器或UAS使用此模型时，就会出现这些问题。
Application servers may not be able to generate an answer for an offer received in the INVITE. The UAC created the offer for the UAS, and so, it may have applied end-to-end encryption or have included information (e.g., related to key management) that the application server is not supposed to use. Therefore, application servers need a means to perform an offer/answer exchange with the UAC that is independent from the offer/answer exchange between both UAs.
应用程序服务器可能无法为邀请中收到的报价生成答复。UAC为UAS创建了报价，因此，它可能应用了端到端加密，或者包含了应用服务器不应该使用的信息（例如，与密钥管理相关的信息）。因此，应用服务器需要一种与UAC进行提供/应答交换的方式，该方式独立于两个UAs之间的提供/应答交换。
UASs using the offer/answer exchange that will carry regular media for sending and receiving early media can cause media clipping, as described in Section 2.1.1 of [8]. Some UACs cannot receive early media from different UASs at the same time. So, when an INVITE forks and several UASs start sending early media, the UAC mutes all the UASs but one (which is usually chosen at random). If the UAS that accepts the INVITE (i.e., sends a 200 OK) was muted, a new offer/answer exchange is needed to unmute it. This usually causes media clipping. Therefore, UASs need a means of performing an offer/answer exchange with the UAC to exchange early media that is independent from the offer/answer exchanged used to exchange regular media.
如[8]第2.1.1节所述，使用提供/应答交换的UAS将承载常规媒体以发送和接收早期媒体，可能导致媒体剪辑。某些UAC无法同时接收来自不同UAS的早期媒体。因此，当一个INVITE分叉和几个UAS开始发送早期媒体时，UAC将使所有UAS静音，但一个UAS除外（通常是随机选择的）。如果接受邀请（即发送200 OK）的UAS已静音，则需要新的要约/应答交换将其取消静音。这通常会导致媒体剪辑。因此，UAS需要一种与UAC进行要约/应答交换的方式，以交换独立于用于交换常规媒体的要约/应答交换的早期媒体。
A potential solution to this need would be to establish a different dialog using a globally routable URI to perform an independent offer/answer exchange. This dialog would be labelled as a dialog for early media and would be somehow related to the original dialog at the UAC. However, performing all the offer/answer exchanges within the original dialog has many advantages:
这种需求的一个潜在解决方案是使用一个全局可路由URI建立一个不同的对话框，以执行独立的报价/应答交换。该对话框将被标记为早期媒体的对话框，并以某种方式与UAC的原始对话框相关。但是，在原始对话框中执行所有提供/应答交换有许多优点：
o It is simpler.
o 它更简单。
o It does not have synchronization problems, because all the early dialogs are terminated when the session is accepted.
o 它没有同步问题，因为在接受会话时，所有早期对话框都会终止。
o It does not require globally routable URIs.
o 它不需要全局可路由URI。
o It does not introduce service interaction issues related to services that may be wrongly applied to the new dialog.
o 它不会引入与可能错误应用于新对话框的服务相关的服务交互问题。
o It makes firewall management easier.
o 它使防火墙管理更容易。
This way of performing offer/answer exchanges for early media is referred to as the application server model [8]. This model uses the early-session disposition type defined in the following section.
这种为早期媒体执行提供/应答交换的方式称为应用服务器模式[8]。此模型使用下一节中定义的早期会话处置类型。
We define a new disposition type for the Content-Disposition header field: early-session. User agents MUST use early-session bodies to establish early media sessions in the same way as they use session bodies to establish regular sessions, as described in RFCs 3261 [2] and 3264 [3]. Particularly, early-session bodies MUST follow the offer/answer model and MAY appear in the same messages as session bodies do with the exceptions of 2xx responses for an INVITE and ACKs. Nevertheless, it is NOT RECOMMENDED that early offers in INVITEs be included because they can fork, and the UAC could receive multiple early answers establishing early media streams at roughly the same time. Also, the use of the same transport address (IP address plus port) in a session body and in an early-session body is NOT RECOMMENDED. Using different transport addresses (e.g., different ports) to receive early and regular media makes it easy to detect the start of the regular media.
我们为Content disposition header字段定义了一种新的处置类型：早期会话。如RFCs 3261[2]和3264[3]所述，用户代理必须使用早期会话主体建立早期媒体会话，其方式与使用会话主体建立常规会话的方式相同。特别是，早期会话主体必须遵循提供/应答模型，并且可能与会话主体出现在相同的消息中，但邀请和确认的2xx响应除外。然而，不建议在邀请中包含早期报价，因为它们可以分叉，UAC可以在大致相同的时间收到多个早期答案，建立早期媒体流。此外，不建议在会话正文和早期会话正文中使用相同的传输地址（IP地址加端口）。使用不同的传输地址（例如，不同的端口）来接收早期和常规介质，可以很容易地检测到常规介质的开始。
If a User Agent (UA) needs to refuse an early-session offer, it MUST do so by refusing all the media streams in it. When SDP [7] is used, this is done by setting the port number of all the media streams to zero.
如果用户代理（UA）需要拒绝早期会话提供，则必须拒绝其中的所有媒体流。使用SDP[7]时，可通过将所有媒体流的端口号设置为零来完成此操作。
This is the same mechanism that UACs use to refuse regular offers that arrive in a response to an empty INVITE.
这与UAC用于拒绝响应空邀请的定期报价的机制相同。
An early media session established using early-session bodies MUST be terminated when its corresponding early dialog is terminated or it transitions to a regular dialog.
使用早期会话主体建立的早期媒体会话必须在其相应的早期对话框终止或转换为常规对话框时终止。
It is RECOMMENDED that UAs generating regular and early session descriptions use, as long as it is possible, the same codecs in both. This way, the remote UA does not need to change codecs when the early session transitions to a regular session.
建议生成常规和早期会话描述的UAs尽可能在两者中使用相同的编解码器。这样，当早期会话转换为常规会话时，远程UA不需要更改编解码器。
RFC 3312 [4] defines a framework for preconditions for SDP. Early-sessions MAY contain preconditions, which are treated in the same way as preconditions in regular sessions. That is, the UAs do not exchange media, and the called user is not alerted until the preconditions are met.
RFC 3312[4]为SDP的前提条件定义了一个框架。早期会议可能包含先决条件，其处理方式与常规会议中的先决条件相同。也就是说，UAs不交换媒体，并且在满足前提条件之前不会通知被叫用户。
We define an option tag to be used in Require and Supported header fields: early-session. A UA adding the early-session option tag to a message indicates that it understands the early-session disposition type.
我们定义了一个选项标记，用于Require和Supported头字段：early session。UA向消息添加早期会话选项标记表示它了解早期会话处置类型。
Figure 1 shows the message flow between two UAs. INVITE (1) has an early-session option tag in its Supported header field and the body shown in Figure 2. The UAS sends back a response with two body parts, as shown in Figure 3: one of disposition type session and the other early-session. The session body part is the answer to the offer in the INVITE. The early-session body part is an offer to establish an early media session. When the UAC receives the 183 (Session Progress) response, it sends the answer to the early-session offer in a PRACK, as shown in Figure 4. This early media session is terminated when the early dialog transitions to a regular dialog. That is, when the UAS sends the (5) 200 (OK) response for the INVITE.
图1显示了两个UAs之间的消息流。INVITE（1）在其受支持的标题字段和正文中有一个早期会话选项标记，如图2所示。UAS发回一个包含两个主体部分的响应，如图3所示：一个是处置类型会话，另一个是早期会话。会话主体部分是对邀请中的提议的回答。早期会议主体部分是建立早期媒体会议的提议。当UAC收到183（会话进度）响应时，它会在PRACK中向早期会话提供发送响应，如图4所示。此早期媒体会话在早期对话框转换为常规对话框时终止。也就是说，当UAS发送邀请的（5）200（OK）响应时。
A B
| |
|--------(1) INVITE-------->|
| offer |
| |
|<--(2) Session Progress----|
| early-offer |
| answer |
| |
|---------(3) PRACK-------->|
| early-answer |
| |
|<--------(4) 200 OK--------|
| |
| * * |
| ************************* |
|* Early Media *|
| ************************* |
| * * |
| |
|<--------(5) 200 OK--------|
| |
|----------(6) ACK--------->|
| |
A B
| |
|--------(1) INVITE-------->|
| offer |
| |
|<--(2) Session Progress----|
| early-offer |
| answer |
| |
|---------(3) PRACK-------->|
| early-answer |
| |
|<--------(4) 200 OK--------|
| |
| * * |
| ************************* |
|* Early Media *|
| ************************* |
| * * |
| |
|<--------(5) 200 OK--------|
| |
|----------(6) ACK--------->|
| |
Figure 1: Message flow
图1：消息流
Content-Type: application/sdp
Content-Disposition: session
Content-Type: application/sdp
Content-Disposition: session
v=0 o=alice 2890844730 2890844731 IN IP4 host.example.com s= c=IN IP4 192.0.2.1 t=0 0 m=audio 20000 RTP/AVP 0
v=0 o=IP4主机中的alice 2890844730 2890844731.example.com s=c=IP4 192.0.2.1 t=0 0 m=音频20000 RTP/AVP 0
Figure 2: Offer
图2：报价
Content-Type: multipart/mixed; boundary="boundary1"
Content-Length: 401
Content-Type: multipart/mixed; boundary="boundary1"
Content-Length: 401
--boundary1
Content-Type: application/sdp
Content-Disposition: session
--boundary1
Content-Type: application/sdp
Content-Disposition: session
v=0 o=Bob 2890844725 2890844725 IN IP4 host.example.org s= c=IN IP4 192.0.2.2 t=0 0 m=audio 30000 RTP/AVP 0
v=0 o=IP4 host.example.org中的Bob 2890844725 2890844725 s=c=IP4 192.0.2.2中的t=0 0 m=30000音频RTP/AVP 0
--boundary1
Content-Type: application/sdp
Content-Disposition: early-session
--boundary1
Content-Type: application/sdp
Content-Disposition: early-session
v=0 o=Bob 2890844714 2890844714 IN IP4 host.example.org s= c=IN IP4 192.0.2.2 t=0 0 m=audio 30002 RTP/AVP 0
v=0 o=IP4主机中的Bob 2890844714 2890844714.example.org s=c=IP4 192.0.2.2 t=0 0 m=audio 30002 RTP/AVP 0
--boundary1--
--边界1--
Figure 3: Early offer and answer
图3：早期报价和答复
Content-Type: application/sdp
Content-Disposition: early-session
Content-Type: application/sdp
Content-Disposition: early-session
v=0 o=alice 2890844717 2890844717 IN IP4 host.example.com s= c=IN IP4 192.0.2.1 t=0 0 m=audio 20002 RTP/AVP 0
v=0 o=alice 2890844717在IP4 host.example.com中2890844717在IP4 192.0.2.1中s=c=t=0 0 m=audio 20002 RTP/AVP 0
Figure 4: Early answer
图4：早期答案
The security implications of using early-session bodies in SIP are the same as when using session bodies; they are part of the offer/answer model.
在SIP中使用早期会话主体的安全含义与使用会话主体时相同；它们是提供/应答模型的一部分。
SIP uses the offer/answer model [3] to establish early sessions in both the gateway and the application server models. User Agents (UAs) generate a session description, which contains the transport address (i.e., IP address plus port) where they want to receive media, and send it to their peer in a SIP message. When media packets arrive at this transport address, the UA assumes that they come from the receiver of the SIP message carrying the session description. Nevertheless, attackers may attempt to gain access to the contents of the SIP message and send packets to the transport address contained in the session description. To prevent this situation, UAs SHOULD encrypt their session descriptions (e.g., using S/MIME).
SIP使用提供/应答模型[3]在网关和应用服务器模型中建立早期会话。用户代理（UAs）生成会话描述，其中包含他们希望接收媒体的传输地址（即IP地址加端口），并在SIP消息中将其发送给对等方。当媒体分组到达该传输地址时，UA假定它们来自承载会话描述的SIP消息的接收器。然而，攻击者可能试图访问SIP消息的内容，并将数据包发送到会话描述中包含的传输地址。为了防止这种情况，UAs应该加密其会话描述（例如，使用S/MIME）。
Still, even if a UA encrypts its session descriptions, an attacker may try to guess the transport address used by the UA and send media packets to that address. Guessing such a transport address is sometimes easier than it may seem because many UAs always pick up the same initial media port. To prevent this situation, UAs SHOULD use media-level authentication mechanisms (e.g., Secure Realtime Transport Protocol (SRTP)[6]). In addition, UAs that wish to keep their communications confidential SHOULD use media-level encryption mechanisms (e.g, SRTP [6]).
尽管如此，即使UA加密其会话描述，攻击者也可能试图猜测UA使用的传输地址并向该地址发送媒体包。猜测这样一个传输地址有时比看起来更容易，因为许多UAs总是选择相同的初始媒体端口。为了防止这种情况，UAs应使用媒体级身份验证机制（例如，安全实时传输协议（SRTP）[6]）。此外，希望对其通信保密的UAs应使用媒体级加密机制（例如，SRTP[6]）。
Attackers may attempt to make a UA send media to a victim as part of a DoS attack. This can be done by sending a session description with the victim's transport address to the UA. To prevent this attack, the UA SHOULD engage in a handshake with the owner of the transport address received in a session description (just verifying willingness to receive media) before sending a large amount of data to the transport address. This check can be performed by using a connection
作为DoS攻击的一部分，攻击者可能试图让UA向受害者发送媒体。这可以通过向UA发送带有受害者传输地址的会话描述来实现。为了防止这种攻击，UA应该在向传输地址发送大量数据之前，与会话描述中接收的传输地址的所有者进行握手（只是验证是否愿意接收媒体）。可以使用连接执行此检查
oriented transport protocol, by using Simple Traversal of the UDP Protocol through NAT (STUN)[5] in an end-to-end fashion, or by the key exchange in SRTP [6].
面向传输协议，通过NAT（STUN）[5]以端到端的方式简单遍历UDP协议，或通过SRTP中的密钥交换[6]。
In any event, note that the previous security considerations are not early media specific, but apply to the usage of the offer/answer model in SIP to establish sessions in general.
在任何情况下，请注意，前面的安全注意事项不是特定于早期媒体的，而是适用于在SIP中使用提供/应答模型来建立会话。
Additionally, an early media-specific risk (roughly speaking, an equivalent to forms of "toll fraud" in the Public Switched Telephone Network (PSTN)) attempts to exploit the different charging policies some operators apply to early and to regular media. When UAs are allowed to exchange early media for free, but are required to pay for regular media sessions, rogue UAs may try to establish a bidirectional early media session and never send a 2xx response for the INVITE.
此外，早期媒体特有的风险（粗略地说，相当于公共交换电话网（PSTN）中的“收费欺诈”形式）试图利用一些运营商适用于早期媒体和常规媒体的不同收费政策。当UAs被允许免费交换早期媒体，但需要为常规媒体会话付费时，流氓UAs可能会尝试建立双向早期媒体会话，并且从不发送2xx邀请响应。
On the other hand, some application servers (e.g., Interactive Voice Response systems) use bidirectional early media to obtain information from the callers (e.g., the Personal Identification Number (PIN) code of a calling card). So, we do not recommend that operators disallow bidirectional early media. Instead, operators should consider a remedy of charging early media exchanges that last too long, or stopping them at the media level (according to the operator's policy).
另一方面，一些应用服务器（例如，交互式语音响应系统）使用双向早期媒体从呼叫者获取信息（例如，电话卡的个人识别号（PIN）代码）。因此，我们不建议运营商禁止双向早期媒体。取而代之的是，运营商应该考虑对早期媒体交换收取过长时间的补救措施，或者在媒体层面停止运营（根据运营商的政策）。
This document defines a new Content-Disposition header field disposition type (early-session) in Section 4. This value has been registered in the IANA registry for Content-Dispositions with the following description:
本文档在第4节中定义了新的内容处置标题字段处置类型（早期会话）。此值已在IANA注册表中注册，用于内容处理，描述如下：
early-session The body describes an early communications session, for example, an RFC 2327 SDP body
早期会话正文描述早期通信会话，例如RFC 2327 SDP正文
This document defines a SIP option tag (early-session) in Section 6. It has been registered in the SIP parameters registry (http://www.iana.org/assignments/sip-parameters) under "Option Tags", with the following description.
本文档在第6节中定义了SIP选项标签（早期会话）。它已在SIP参数注册表中注册(http://www.iana.org/assignments/sip-parameters)在“选项标签”下，具有以下说明。
early-session A UA adding the early-session option tag to a message indicates that it understands the early-session content disposition.
早期会话UA向消息中添加早期会话选项标记表示它了解早期会话内容配置。
Francois Audet, Christer Holmberg, and Allison Mankin provided useful comments on this document.
Francois Audet、Christer Holmberg和Allison Mankin对该文件提供了有用的评论。
[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] 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.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002.
[3] Rosenberg，J.和H.Schulzrinne，“具有会话描述协议（SDP）的提供/应答模型”，RFC 3264，2002年6月。
[4] Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
[4] Camarillo，G.，Marshall，W.，和J.Rosenberg，“资源管理和会话启动协议（SIP）的集成”，RFC 3312，2002年10月。
[5] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)", RFC 3489, March 2003.
[5] Rosenberg，J.，Weinberger，J.，Huitema，C.，和R.Mahy，“STUN-通过网络地址转换器（NAT）简单遍历用户数据报协议（UDP）”，RFC 3489，2003年3月。
[6] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.
[6] Baugher，M.，McGrew，D.，Naslund，M.，Carrara，E.，和K.Norrman，“安全实时传输协议（SRTP）”，RFC 37112004年3月。
[7] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[7] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[8] Camarillo, G. and H. Schulzrinne, "Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP)", RFC 3960, December 2004.
[8] Camarillo，G.和H.Schulzrinne，“会话启动协议（SIP）中的早期媒体和铃声生成”，RFC 39602004年12月。
Author's Address
作者地址
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420芬兰
EMail: Gonzalo.Camarillo@ericsson.com
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。