Network Working Group J. Rosenberg
Request for Comments: 3262 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia U.
June 2002
Network Working Group J. Rosenberg
Request for Comments: 3262 dynamicsoft
Category: Standards Track H. Schulzrinne
Columbia U.
June 2002
Reliability of Provisional Responses in 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 (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method.
本文档指定了会话启动协议（SIP）的扩展，提供可靠的临时响应消息。此扩展使用选项标记100rel并定义临时响应确认（PRACK）方法。
Table of Contents
目录
1 Introduction ........................................ 2
2 Terminology ......................................... 3
3 UAS Behavior ........................................ 3
4 UAC Behavior ........................................ 6
5 The Offer/Answer Model and PRACK .................... 9
6 Definition of the PRACK Method ...................... 10
7 Header Field Definitions ............................ 10
7.1 RSeq ................................................ 10
7.2 RAck ................................................ 11
8 IANA Considerations ................................. 11
8.1 IANA Registration of the 100rel Option Tag .......... 11
8.2 IANA Registration of RSeq and RAck Headers .......... 12
9 Security Considerations ............................. 12
10 Collected BNF ....................................... 12
11 Acknowledgements .................................... 12
12 Normative References ................................ 13
13 Informative References .............................. 13
1 Introduction ........................................ 2
2 Terminology ......................................... 3
3 UAS Behavior ........................................ 3
4 UAC Behavior ........................................ 6
5 The Offer/Answer Model and PRACK .................... 9
6 Definition of the PRACK Method ...................... 10
7 Header Field Definitions ............................ 10
7.1 RSeq ................................................ 10
7.2 RAck ................................................ 11
8 IANA Considerations ................................. 11
8.1 IANA Registration of the 100rel Option Tag .......... 11
8.2 IANA Registration of RSeq and RAck Headers .......... 12
9 Security Considerations ............................. 12
10 Collected BNF ....................................... 12
11 Acknowledgements .................................... 12
12 Normative References ................................ 13
13 Informative References .............................. 13
14 Authors' Addresses .................................. 13
15. Full Copyright Statement............................. 14
14 Authors' Addresses .................................. 13
15. Full Copyright Statement............................. 14
1 Introduction
1导言
The Session Initiation Protocol (SIP) (RFC 3261 [1]) is a request-response protocol for initiating and managing communications sessions. SIP defines two types of responses, provisional and final. Final responses convey the result of the request processing, and are sent reliably. Provisional responses provide information on the progress of the request processing, but are not sent reliably in RFC 3261.
会话发起协议（SIP）（RFC 3261[1]）是用于发起和管理通信会话的请求-响应协议。SIP定义了两种类型的响应，临时响应和最终响应。最终响应传递请求处理的结果，并可靠地发送。临时响应提供有关请求处理进度的信息，但在RFC 3261中无法可靠地发送。
It was later observed that reliability was important in several cases, including interoperability scenarios with the PSTN. Therefore, an optional capability was needed to support reliable transmission of provisional responses. That capability is provided in this specification.
后来发现，可靠性在一些情况下很重要，包括与PSTN的互操作性场景。因此，需要一种可选能力来支持临时响应的可靠传输。该功能在本规范中提供。
The reliability mechanism works by mirroring the current reliability mechanisms for 2xx final responses to INVITE. Those requests are transmitted periodically by the Transaction User (TU) until a separate transaction, ACK, is received that indicates reception of the 2xx by the UAC. The reliability for the 2xx responses to INVITE and ACK messages are end-to-end. In order to achieve reliability for provisional responses, we do nearly the same thing. Reliable provisional responses are retransmitted by the TU with an exponential backoff. Those retransmissions cease when a PRACK message is received. The PRACK request plays the same role as ACK, but for provisional responses. There is an important difference, however. PRACK is a normal SIP message, like BYE. As such, its own reliability is ensured hop-by-hop through each stateful proxy. Also like BYE, but unlike ACK, PRACK has its own response. If this were not the case, the PRACK message could not traverse proxy servers compliant to RFC 2543 [4].
可靠性机制通过镜像当前2xx最终响应的可靠性机制来工作。这些请求由事务用户（TU）定期发送，直到收到单独的事务ACK，表明UAC接收到2xx。INVITE和ACK消息的2xx响应的可靠性是端到端的。为了实现临时响应的可靠性，我们做了几乎相同的事情。可靠的临时响应由具有指数退避的TU重新传输。当收到PRACK消息时，这些重传停止。PRACK请求与ACK起着相同的作用，只是用于临时响应。然而，有一个重要的区别。PRACK是一个普通的SIP消息，比如拜拜。因此，通过每个有状态代理逐跳确保其自身的可靠性。同样像拜拜，但不像阿克，普拉克有自己的反应。如果不是这样，PRACK消息将无法遍历符合RFC 2543[4]的代理服务器。
Each provisional response is given a sequence number, carried in the RSeq header field in the response. The PRACK messages contain an RAck header field, which indicates the sequence number of the provisional response that is being acknowledged. The acknowledgments are not cumulative, and the specifications recommend a single outstanding provisional response at a time, for purposes of congestion control.
每个临时响应都有一个序列号，在响应的RSeq头字段中携带。PRACK消息包含一个RAck header字段，该字段指示正在确认的临时响应的序列号。确认不是累积的，为了拥塞控制的目的，规范建议每次有一个未完成的临时响应。
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 SIP implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”将按照RFC 2119[2]中的描述进行解释，并表示符合SIP实施的要求级别。
3 UAS Behavior
3无人机行为
A UAS MAY send any non-100 provisional response to INVITE reliably, so long as the initial INVITE request (the request whose provisional response is being sent reliably) contained a Supported header field with the option tag 100rel. While this specification does not allow reliable provisional responses for any method but INVITE, extensions that define new methods that can establish dialogs may make use of the mechanism.
UAS可以向INVITE可靠发送任何非100临时响应，只要初始INVITE请求（其临时响应被可靠发送的请求）包含带有选项标记100rel的受支持的头字段。虽然本规范不允许对任何方法（但INVITE）进行可靠的临时响应，但是定义可以建立对话框的新方法的扩展可以利用该机制。
The UAS MUST send any non-100 provisional response reliably if the initial request contained a Require header field with the option tag 100rel. If the UAS is unwilling to do so, it MUST reject the initial request with a 420 (Bad Extension) and include an Unsupported header field containing the option tag 100rel.
如果初始请求包含带有选项标记100rel的Require标头字段，UAS必须可靠地发送任何非100临时响应。如果UAS不愿意这样做，它必须以420（坏扩展名）拒绝初始请求，并包括一个包含选项标记100rel的不受支持的头字段。
A UAS MUST NOT attempt to send a 100 (Trying) response reliably. Only provisional responses numbered 101 to 199 may be sent reliably. If the request did not include either a Supported or Require header field indicating this feature, the UAS MUST NOT send the provisional response reliably.
UAS不得尝试可靠地发送100（尝试）响应。只能可靠地发送编号为101到199的临时响应。如果请求未包含指示此功能的Supported或Require标头字段，则UAS不得可靠地发送临时响应。
100 (Trying) responses are hop-by-hop only. For this reason, the reliability mechanisms described here, which are end-to-end, cannot be used.
100个（尝试）响应仅为逐跳响应。因此，此处描述的端到端可靠性机制无法使用。
An element that can act as a proxy can also send reliable provisional responses. In this case, it acts as a UAS for purposes of that transaction. However, it MUST NOT attempt to do so for any request that contains a tag in the To field. That is, a proxy cannot generate reliable provisional responses to requests sent within the context of a dialog. Of course, unlike a UAS, when the proxy element receives a PRACK that does not match any outstanding reliable provisional response, the PRACK MUST be proxied.
可以充当代理的元素也可以发送可靠的临时响应。在这种情况下，它在该交易中充当UAS。但是，对于在“收件人”字段中包含标记的任何请求，它不得尝试这样做。也就是说，代理无法对对话框上下文中发送的请求生成可靠的临时响应。当然，与UAS不同，当代理元素接收到与任何未完成的可靠临时响应不匹配的PRACK时，必须代理PRACK。
There are several reasons why a UAS might want to send a reliable provisional response. One reason is if the INVITE transaction will take some time to generate a final response. As discussed in Section 13.3.1.1 of RFC 3261, the UAS will need to send periodic provisional responses to request an "extension" of the transaction at proxies. The requirement is that a proxy receive them every three minutes, but
UAS希望发送可靠的临时响应的原因有很多。一个原因是INVITE事务是否需要一些时间来生成最终响应。如RFC 3261第13.3.1.1节所述，UAS需要定期发送临时响应，以请求代理“延长”交易。要求代理每三分钟接收一次，但是
the UAS needs to send them more frequently (once a minute is recommended) because of the possibility of packet loss. As a more efficient alternative, the UAS can send the response reliably, in which case the UAS SHOULD send provisional responses once every two and a half minutes. Use of reliable provisional responses for extending transactions is RECOMMENDED.
由于存在数据包丢失的可能性，UAS需要更频繁地发送它们（建议每分钟发送一次）。作为更有效的替代方案，UAS可以可靠地发送响应，在这种情况下，UAS应该每两分钟半发送一次临时响应。建议使用可靠的临时响应来扩展事务。
The rest of this discussion assumes that the initial request contained a Supported or Require header field listing 100rel, and that there is a provisional response to be sent reliably.
本讨论的其余部分假设初始请求包含一个列出100rel的Supported或Require头字段，并且有一个可靠发送的临时响应。
The provisional response to be sent reliably is constructed by the UAS core according to the procedures of Section 8.2.6 of RFC 3261. In addition, it MUST contain a Require header field containing the option tag 100rel, and MUST include an RSeq header field. The value of the header field for the first reliable provisional response in a transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED that it be chosen uniformly in this range. The RSeq numbering space is within a single transaction. This means that provisional responses for different requests MAY use the same values for the RSeq number.
根据RFC 3261第8.2.6节的程序，由UAS核心构建可靠发送的临时响应。此外，它必须包含包含选项标记100rel的Require标头字段，并且必须包含RSeq标头字段。事务中第一个可靠临时响应的标头字段的值必须介于1和2**31-1之间。建议在此范围内统一选择。RSeq编号空间位于单个事务中。这意味着不同请求的临时响应可能会对RSeq编号使用相同的值。
The reliable provisional response MAY contain a body. The usage of session descriptions is described in Section 5.
可靠的临时响应可能包含一个主体。第5节介绍了会话描述的用法。
The reliable provisional response is passed to the transaction layer periodically with an interval that starts at T1 seconds and doubles for each retransmission (T1 is defined in Section 17 of RFC 3261). Once passed to the server transaction, it is added to an internal list of unacknowledged reliable provisional responses. The transaction layer will forward each retransmission passed from the UAS core.
可靠的临时响应以从T1秒开始的间隔周期性地传递给事务层，并且每次重传的间隔加倍（T1在RFC 3261的第17节中定义）。一旦传递到服务器事务，它将被添加到未确认的可靠临时响应的内部列表中。事务层将转发从UAS核心传递的每次重传。
This differs from retransmissions of 2xx responses, whose intervals cap at T2 seconds. This is because retransmissions of ACK are triggered on receipt of a 2xx, but retransmissions of PRACK take place independently of reception of 1xx.
这不同于2xx响应的重传，其间隔上限为T2秒。这是因为ACK的重传在接收到2xx时触发，但PRACK的重传独立于1xx的接收进行。
Retransmissions of the reliable provisional response cease when a matching PRACK is received by the UA core. PRACK is like any other request within a dialog, and the UAS core processes it according to the procedures of Sections 8.2 and 12.2.2 of RFC 3261. A matching PRACK is defined as one within the same dialog as the response, and whose method, CSeq-num, and response-num in the RAck header field match, respectively, the method from the CSeq, the sequence number from the CSeq, and the sequence number from the RSeq of the reliable provisional response.
当UA核心接收到匹配的PRAK时，可靠临时响应的重传停止。PRACK与对话框中的任何其他请求一样，UAS核心根据RFC 3261第8.2节和第12.2.2节的程序对其进行处理。匹配PRACK定义为与响应在同一对话框中的PRACK，其方法CSeq num和机架标题字段中的response num分别与可靠临时响应的CSeq方法、CSeq序列号和RSeq序列号匹配。
If a PRACK request is received by the UA core that does not match any unacknowledged reliable provisional response, the UAS MUST respond to the PRACK with a 481 response. If the PRACK does match an unacknowledged reliable provisional response, it MUST be responded to with a 2xx response. The UAS can be certain at this point that the provisional response has been received in order. It SHOULD cease retransmissions of the reliable provisional response, and MUST remove it from the list of unacknowledged provisional responses.
如果UA核心收到的PRACK请求与任何未确认的可靠临时响应不匹配，则UAS必须以481响应响应PRACK。如果PRACK与未确认的可靠临时响应匹配，则必须使用2xx响应对其进行响应。此时，UAS可以确定已按顺序收到临时响应。它应该停止可靠临时响应的重新传输，并且必须将其从未确认的临时响应列表中删除。
If a reliable provisional response is retransmitted for 64*T1 seconds without reception of a corresponding PRACK, the UAS SHOULD reject the original request with a 5xx response.
如果可靠的临时响应被重新传输了64*T1秒，而没有收到相应的PRACK，UAS应使用5xx响应拒绝原始请求。
If the PRACK contained a session description, it is processed as described in Section 5 of this document. If the PRACK instead contained any other type of body, the body is treated in the same way that body in an ACK would be treated.
如果PRACK包含会话描述，则按照本文件第5节中的说明进行处理。如果婴儿车包含任何其他类型的身体，则该身体的处理方式与ACK中的身体相同。
After the first reliable provisional response for a request has been acknowledged, the UAS MAY send additional reliable provisional responses. The UAS MUST NOT send a second reliable provisional response until the first is acknowledged. After the first, it is RECOMMENDED that the UAS not send an additional reliable provisional response until the previous is acknowledged. The first reliable provisional response receives special treatment because it conveys the initial sequence number. If additional reliable provisional responses were sent before the first was acknowledged, the UAS could not be certain these were received in order.
在确认请求的第一个可靠临时响应后，UAS可以发送额外的可靠临时响应。在确认第一个响应之前，UAS不得发送第二个可靠的临时响应。在第一次响应之后，建议UAS在确认之前不要发送额外的可靠临时响应。第一个可靠的临时响应接受特殊处理，因为它传递初始序列号。如果在确认第一个响应之前发送了其他可靠的临时响应，UAS无法确定这些响应是否按顺序接收。
The value of the RSeq in each subsequent reliable provisional response for the same request MUST be greater by exactly one. RSeq numbers MUST NOT wrap around. Because the initial one is chosen to be less than 2**31 - 1, but the maximum is 2**32 - 1, there can be up to 2**31 reliable provisional responses per request, which is more than sufficient.
同一请求的每个后续可靠临时响应中的RSeq值必须正好大于1。RSeq编号不得环绕。由于选择的初始响应小于2**31-1，但最大值为2**32-1，因此每个请求最多可以有2**31个可靠的临时响应，这就足够了。
The UAS MAY send a final response to the initial request before having received PRACKs for all unacknowledged reliable provisional responses, unless the final response is 2xx and any of the unacknowledged reliable provisional responses contained a session description. In that case, it MUST NOT send a final response until those provisional responses are acknowledged. If the UAS does send a final response when reliable responses are still unacknowledged, it SHOULD NOT continue to retransmit the unacknowledged reliable provisional responses, but it MUST be prepared to process PRACK requests for those outstanding responses. A UAS MUST NOT send new reliable provisional responses (as opposed to retransmissions of unacknowledged ones) after sending a final response to a request.
UAS可以在收到所有未确认的可靠临时响应的PRACK之前，向初始请求发送最终响应，除非最终响应为2xx且任何未确认的可靠临时响应包含会话描述。在这种情况下，在确认临时回复之前，不得发送最终回复。如果UAS在可靠响应仍然未确认时发送最终响应，则不应继续重新传输未确认的可靠临时响应，但必须准备好处理这些未确认响应的PRACK请求。在发送请求的最终响应后，UAS不得发送新的可靠临时响应（与未确认响应的重新传输相反）。
4 UAC Behavior
4 UAC行为
When the UAC creates a new request, it can insist on reliable delivery of provisional responses for that request. To do that, it inserts a Require header field with the option tag 100rel into the request. A Require header with the value 100rel MUST NOT be present in any requests excepting INVITE, although extensions to SIP may allow its usage with other request methods.
当UAC创建一个新请求时，它可以坚持为该请求提供可靠的临时响应。为此，它在请求中插入一个带有选项标记100rel的Require头字段。值为100rel的Require头不能出现在除INVITE之外的任何请求中，尽管SIP的扩展可能允许它与其他请求方法一起使用。
Header field where PRACK
___________________________________
Accept R o
Accept 2xx -
Accept 415 c
Accept-Encoding R o
Accept-Encoding 2xx -
Accept-Encoding 415 c
Accept-Language R o
Accept-Language 2xx -
Accept-Language 415 c
Alert-Info R -
Alert-Info 180 -
Allow R o
Allow 2xx o
Allow r o
Allow 405 m
Authentication-Info 2xx o
Authorization R o
Call-ID c m
Call-Info -
Contact R -
Contact 1xx -
Contact 2xx -
Contact 3xx o
Contact 485 o
Content-Disposition o
Content-Encoding o
Content-Language o
Content-Length t
Content-Type *
CSeq c m
Date o
Error-Info 300-699 o
Expires -
From c m
In-Reply-To R -
Max-Forwards R m
Min-Expires 423 -
MIME-Version o
Organization -
Header field where PRACK
___________________________________
Accept R o
Accept 2xx -
Accept 415 c
Accept-Encoding R o
Accept-Encoding 2xx -
Accept-Encoding 415 c
Accept-Language R o
Accept-Language 2xx -
Accept-Language 415 c
Alert-Info R -
Alert-Info 180 -
Allow R o
Allow 2xx o
Allow r o
Allow 405 m
Authentication-Info 2xx o
Authorization R o
Call-ID c m
Call-Info -
Contact R -
Contact 1xx -
Contact 2xx -
Contact 3xx o
Contact 485 o
Content-Disposition o
Content-Encoding o
Content-Language o
Content-Length t
Content-Type *
CSeq c m
Date o
Error-Info 300-699 o
Expires -
From c m
In-Reply-To R -
Max-Forwards R m
Min-Expires 423 -
MIME-Version o
Organization -
Table 1: Summary of header fields, A--O
表1：标题字段摘要，A--O
Header field where PRACK
__________________________________________
Priority R -
Proxy-Authenticate 407 m
Proxy-Authenticate 401 o
Proxy-Authorization R o
Proxy-Require R o
Record-Route R o
Record-Route 2xx,18x o
Reply-To -
Require c
Retry-After 404,413,480,486 o
500,503 o
600,603 o
Route R c
Server r o
Subject R -
Supported R o
Supported 2xx o
Timestamp o
To c m
Unsupported 420 m
User-Agent o
Via c m
Warning r o
WWW-Authenticate 401 m
Header field where PRACK
__________________________________________
Priority R -
Proxy-Authenticate 407 m
Proxy-Authenticate 401 o
Proxy-Authorization R o
Proxy-Require R o
Record-Route R o
Record-Route 2xx,18x o
Reply-To -
Require c
Retry-After 404,413,480,486 o
500,503 o
600,603 o
Route R c
Server r o
Subject R -
Supported R o
Supported 2xx o
Timestamp o
To c m
Unsupported 420 m
User-Agent o
Via c m
Warning r o
WWW-Authenticate 401 m
Table 2: Summary of header fields, P--Z
表2：标题字段摘要，P--Z
If the UAC does not wish to insist on usage of reliable provisional responses, but merely indicate that it supports them if the UAS needs to send one, a Supported header MUST be included in the request with the option tag 100rel. The UAC SHOULD include this in all INVITE requests.
如果UAC不希望坚持使用可靠的临时响应，而只是在UAS需要发送响应时表示支持这些响应，则请求中必须包含一个支持的标头，并带有选项标记100rel。UAC应在所有INVITE请求中包含此内容。
If a provisional response is received for an initial request, and that response contains a Require header field containing the option tag 100rel, the response is to be sent reliably. If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, and the procedures below MUST NOT be used.
如果收到初始请求的临时响应，并且该响应包含包含选项标记100rel的Require头字段，则响应将可靠地发送。如果响应为100（尝试）（与101到199相反），则必须忽略此选项标记，并且不得使用以下步骤。
The provisional response MUST establish a dialog if one is not yet created.
如果尚未创建对话框，则临时响应必须建立对话框。
Assuming the response is to be transmitted reliably, the UAC MUST create a new request with method PRACK. This request is sent within the dialog associated with the provisional response (indeed, the provisional response may have created the dialog). PRACK requests MAY contain bodies, which are interpreted according to their type and disposition.
假设要可靠地传输响应，UAC必须使用方法PRACK创建一个新请求。该请求在与临时响应相关联的对话框中发送（实际上，临时响应可能创建了该对话框）。PRACK请求可能包含主体，这些主体根据其类型和配置进行解释。
Note that the PRACK is like any other non-INVITE request within a dialog. In particular, a UAC SHOULD NOT retransmit the PRACK request when it receives a retransmission of the provisional response being acknowledged, although doing so does not create a protocol error.
注意，PRACK与对话框中的任何其他非INVITE请求类似。特别是，UAC在接收到正在确认的临时响应的重传时不应重传PRACK请求，尽管这样做不会产生协议错误。
Once a reliable provisional response is received, retransmissions of that response MUST be discarded. A response is a retransmission when its dialog ID, CSeq, and RSeq match the original response. The UAC MUST maintain a sequence number that indicates the most recently received in-order reliable provisional response for the initial request. This sequence number MUST be maintained until a final response is received for the initial request. Its value MUST be initialized to the RSeq header field in the first reliable provisional response received for the initial request.
一旦收到可靠的临时响应，必须放弃对该响应的重新传输。当响应的对话ID、CSeq和RSeq与原始响应匹配时，响应是重传。UAC必须保留一个序列号，该序列号指示最近收到的请求，以便对初始请求做出可靠的临时响应。在收到初始请求的最终响应之前，必须保留该序列号。它的值必须初始化为初始请求收到的第一个可靠临时响应中的RSeq头字段。
Handling of subsequent reliable provisional responses for the same initial request follows the same rules as above, with the following difference: reliable provisional responses are guaranteed to be in order. As a result, if the UAC receives another reliable provisional response to the same request, and its RSeq value is not one higher than the value of the sequence number, that response MUST NOT be acknowledged with a PRACK, and MUST NOT be processed further by the UAC. An implementation MAY discard the response, or MAY cache the response in the hopes of receiving the missing responses.
对于同一初始请求，后续可靠临时响应的处理遵循与上述相同的规则，区别如下：可靠临时响应保证有序。因此，如果UAC接收到对同一请求的另一可靠临时响应，且其RSeq值不高于序列号的值，则该响应不得通过PRACK确认，且UAC不得进一步处理。实现可以丢弃响应，或者缓存响应，希望接收丢失的响应。
The UAC MAY acknowledge reliable provisional responses received after the final response or MAY discard them.
UAC可以确认在最终响应后收到的可靠临时响应，也可以放弃这些响应。
5 The Offer/Answer Model and PRACK
5提供/回答模型和实践
RFC 3261 describes guidelines for the sets of messages in which offers and answers [3] can appear. Based on those guidelines, this extension provides additional opportunities for offer/answer exchanges.
RFC 3261描述了可显示报价和答案[3]的消息集的准则。根据这些指导原则，此扩展提供了更多交换报价/应答的机会。
If the INVITE contained an offer, the UAS MAY generate an answer in a reliable provisional response (assuming these are supported by the UAC). That results in the establishment of the session before
如果邀请中包含报价，UAS可能会在可靠的临时响应中生成答案（假设UAC支持）。这导致在会议之前设立会议
completion of the call. Similarly, if a reliable provisional response is the first reliable message sent back to the UAC, and the INVITE did not contain an offer, one MUST appear in that reliable provisional response.
通话结束。类似地，如果可靠的临时响应是发送回UAC的第一条可靠消息，并且邀请不包含报价，则必须在该可靠的临时响应中出现。
If the UAC receives a reliable provisional response with an offer (this would occur if the UAC sent an INVITE without an offer, in which case the first reliable provisional response will contain the offer), it MUST generate an answer in the PRACK. If the UAC receives a reliable provisional response with an answer, it MAY generate an additional offer in the PRACK. If the UAS receives a PRACK with an offer, it MUST place the answer in the 2xx to the PRACK.
如果UAC收到带有要约的可靠临时响应（如果UAC发送的邀请没有要约，则会发生这种情况，在这种情况下，第一个可靠的临时响应将包含要约），则必须在PRACK中生成一个答案。如果UAC收到一个可靠的临时回复和一个答复，它可能会在PRACK中生成一个额外的报价。如果UAS收到带有报价的PRACK，则必须将答案放在PRACK的2xx中。
Once an answer has been sent or received, the UA SHOULD establish the session based on the parameters of the offer and answer, even if the original INVITE itself has not been responded to.
一旦发送或接收到应答，UA应根据要约和应答的参数建立会话，即使原始邀请本身未得到响应。
If the UAS had placed a session description in any reliable provisional response that is unacknowledged when the INVITE is accepted, the UAS MUST delay sending the 2xx until the provisional response is acknowledged. Otherwise, the reliability of the 1xx cannot be guaranteed, and reliability is needed for proper operation of the offer/answer exchange.
如果UAS在接受邀请时未确认的任何可靠临时响应中放置了会话描述，则UAS必须延迟发送2xx，直到临时响应得到确认。否则，无法保证1xx的可靠性，并且需要可靠性才能正确操作提供/应答交换。
All user agents that support this extension MUST support all offer/answer exchanges that are possible based on the rules in Section 13.2 of RFC 3261, based on the existence of INVITE and PRACK as requests, and 2xx and reliable 1xx as non-failure reliable responses.
支持此扩展的所有用户代理必须支持根据RFC 3261第13.2节中的规则可能进行的所有提供/应答交换，前提是存在INVITE和PRACK as请求，以及2xx和RELABLE 1xx作为非故障可靠响应。
6 Definition of the PRACK Method
6普拉克方法的定义
This specification defines a new SIP method, PRACK. The semantics of this method are described above. Tables 1 and 2 extend Tables 2 and 3 from RFC 3261 for this new method.
本规范定义了一种新的SIP方法PRACK。上面描述了该方法的语义。对于这种新方法，表1和表2扩展了RFC 3261中的表2和表3。
7 Header Field Definitions
7标题字段定义
This specification defines two new header fields, RAck and RSeq. Table 3 extends Tables 2 and 3 from RFC 3261 for these headers.
本规范定义了两个新的标题字段RAck和RSeq。表3扩展了RFC 3261中的表2和表3，用于这些标题。
The RSeq header is used in provisional responses in order to transmit them reliably. It contains a single numeric value from 1 to 2**32 - 1. For details on its usage, see Section 3.
在临时响应中使用RSeq报头，以便可靠地传输它们。它包含一个从1到2**32-1的单一数值。有关其用法的详细信息，请参见第3节。
Example:
例子：
RSeq: 988789
RSeq:988789
Header field where proxy ACK BYE CAN INV OPT REG PRA
______________________________________________________
RAck R - - - - - - m
RSeq 1xx - - - o - - -
Header field where proxy ACK BYE CAN INV OPT REG PRA
______________________________________________________
RAck R - - - - - - m
RSeq 1xx - - - o - - -
Table 3: RAck and RSeq Header Fields
表3：机架和RSeq头字段
The RAck header is sent in a PRACK request to support reliability of provisional responses. It contains two numbers and a method tag. The first number is the value from the RSeq header in the provisional response that is being acknowledged. The next number, and the method, are copied from the CSeq in the response that is being acknowledged. The method name in the RAck header is case sensitive.
机架标头以PRACK请求发送，以支持临时响应的可靠性。它包含两个数字和一个方法标记。第一个数字是正在确认的临时响应中RSeq头的值。下一个数字和方法将从正在确认的响应中的CSeq复制。机架标头中的方法名称区分大小写。
Example:
例子：
RAck: 776656 1 INVITE
机架：776656 1
8 IANA Considerations
8 IANA考虑因素
This document registers a new option tag and two new headers, based on the IANA registration process of RFC 3261.
本文档根据RFC 3261的IANA注册过程注册了一个新选项标记和两个新标题。
This specification registers a single option tag, 100rel. The required information for this registration, as specified in RFC 3261, is:
本规范注册了一个选项标签100rel。RFC 3261中规定的本次注册所需信息如下：
Name: 100rel
姓名：100rel
Description: This option tag is for reliability of provisional responses. When present in a Supported header, it indicates that the UA can send or receive reliable provisional responses. When present in a Require header in a request, it indicates that the UAS MUST send all provisional responses reliably. When present in a Require header in a reliable provisional response, it indicates that the response is to be sent reliably.
说明：此选项标签用于临时响应的可靠性。当出现在受支持的报头中时，它表示UA可以发送或接收可靠的临时响应。当出现在请求的Require头中时，它表示UAS必须可靠地发送所有临时响应。当在可靠的临时响应中出现在Require报头中时，它表示要可靠地发送响应。
The following is the registration for the RSeq header:
以下是RSeq头的注册：
RFC Number: RFC3262
RFC编号：RFC3262
Header Name: RSeq
标题名称：RSeq
Compact Form: none
紧凑型：无
The following is the registration for the RAck header:
以下是机架标题的注册：
RFC Number: RFC3262
RFC编号：RFC3262
Header Name: RAck
标题名称：机架
Compact Form: none
紧凑型：无
9 Security Considerations
9安全考虑
The PRACK request can be injected by attackers to force retransmissions of reliable provisional responses to cease. As these responses can convey important information, PRACK messages SHOULD be authenticated as any other request. Authentication procedures are specified in RFC 3261.
攻击者可以注入PRACK请求，以强制停止可靠临时响应的重新传输。由于这些响应可以传递重要的信息，PRACK消息应该像任何其他请求一样进行身份验证。RFC 3261中规定了认证程序。
10 Collected BNF
10收集的BNF
The BNF for the RAck and RSeq headers and the PRACK method are defined here.
这里定义了RAck和RSeq头的BNF以及PRACK方法。
PRACKm = %x50.52.41.43.4B ; PRACK in caps
Method = INVITEm / ACKm / OPTIONSm / BYEm
/ CANCELm / REGISTERm / PRACKm
/ extension-method
RAck = "RAck" HCOLON response-num LWS CSeq-num LWS Method
response-num = 1*DIGIT
CSeq-num = 1*DIGIT
RSeq = "RSeq" HCOLON response-num
PRACKm = %x50.52.41.43.4B ; PRACK in caps
Method = INVITEm / ACKm / OPTIONSm / BYEm
/ CANCELm / REGISTERm / PRACKm
/ extension-method
RAck = "RAck" HCOLON response-num LWS CSeq-num LWS Method
response-num = 1*DIGIT
CSeq-num = 1*DIGIT
RSeq = "RSeq" HCOLON response-num
11 Acknowledgements
11致谢
The authors would like to thank Jo Hornsby, Jonathan Lennox, Rohan Mahy, Allison Mankin, Adam Roach, and Tim Schroeder for the comments on this document.
作者感谢Jo Hornsby、Jonathan Lennox、Rohan Mahy、Allison Mankin、Adam Roach和Tim Schroeder对本文件的评论。
12 Normative References
12规范性引用文件
[1] 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.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[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] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with SDP", RFC 3264, June 2002.
[3] Rosenberg，J.和H.Schulzrinne，“具有SDP的报价/应答模型”，RFC 3264，2002年6月。
13 Informative References
13参考资料
[4] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[4] Handley，M.，Schulzrinne，H.，Schooler，E.和J.Rosenberg，“SIP：会话启动协议”，RFC 25431999年3月。
14 Authors' Addresses
14作者地址
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 Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
亨宁·舒尔兹林内哥伦比亚大学M/S 0401 1214纽约州纽约市阿姆斯特丹大道10027-7003
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编辑功能的资金目前由互联网协会提供。