📄 rfc3262.txt
字号:
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)
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.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
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.
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
Rosenberg & Schulzrinne Standards Track [Page 1]
RFC 3262 Reliability of Provisional Responses in SIP June 2002
14 Authors' Addresses .................................. 13
15. Full Copyright Statement............................. 14
1 Introduction
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.
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.
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].
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.
Rosenberg & Schulzrinne Standards Track [Page 2]
RFC 3262 Reliability of Provisional Responses in SIP June 2002
2 Terminology
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.
3 UAS Behavior
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.
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.
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.
100 (Trying) responses are hop-by-hop only. For this reason, the
reliability mechanisms described here, which are end-to-end,
cannot be used.
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.
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
Rosenberg & Schulzrinne Standards Track [Page 3]
RFC 3262 Reliability of Provisional Responses in SIP June 2002
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.
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.
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.
The reliable provisional response MAY contain a body. The usage of
session descriptions is described in Section 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.
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.
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.
Rosenberg & Schulzrinne Standards Track [Page 4]
RFC 3262 Reliability of Provisional Responses in SIP June 2002
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.
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.
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.
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.
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.
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.
Rosenberg & Schulzrinne Standards Track [Page 5]
RFC 3262 Reliability of Provisional Responses in SIP June 2002
4 UAC Behavior
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.
Rosenberg & Schulzrinne Standards Track [Page 6]
RFC 3262 Reliability of Provisional Responses in SIP June 2002
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
Rosenberg & Schulzrinne Standards Track [Page 7]
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -