As per Relevance of the word reliability, we have this rfc below:
Network Working Group J.
Request for Comments: 3262
Category: Standards Track H.
Columbia U
June 2002
Reliability of Provisional
in the Session Initiation Protocol (SIP
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document specifies an extension to the Session
Protocol (SIP) providing reliable provisional response messages
This extension uses the option tag 100rel and defines the
Response ACKnowledgement (PRACK) method
Table of
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
The Session Initiation Protocol (SIP) (RFC 3261 [1]) is a request
response protocol for initiating and managing
sessions. SIP defines two types of responses, provisional and final
Final responses convey the result of the request processing, and
sent reliably. Provisional responses provide information on
progress of the request processing, but are not sent reliably in
3261.
It was later observed that reliability was important in
cases, including interoperability scenarios with the PSTN
Therefore, an optional capability was needed to support
transmission of provisional responses. That capability is
in this specification
The reliability mechanism works by mirroring the current
mechanisms for 2xx final responses to INVITE. Those requests
transmitted periodically by the Transaction User (TU) until
separate transaction, ACK, is received that indicates reception
the 2xx by the UAC. The reliability for the 2xx responses to
and ACK messages are end-to-end. In order to achieve reliability
provisional responses, we do nearly the same thing.
provisional responses are retransmitted by the TU with an
backoff. Those retransmissions cease when a PRACK message
received. The PRACK request plays the same role as ACK, but
provisional responses. There is an important difference, however
PRACK is a normal SIP message, like BYE. As such, its
reliability is ensured hop-by-hop through each stateful proxy.
like BYE, but unlike ACK, PRACK has its own response. If this
not the case, the PRACK message could not traverse proxy
compliant to RFC 2543 [4].
Each provisional response is given a sequence number, carried in
RSeq header field in the response. The PRACK messages contain
RAck header field, which indicates the sequence number of
provisional response that is being acknowledged. The
are not cumulative, and the specifications recommend a
outstanding provisional response at a time, for purposes
congestion control
Rosenberg & Schulzrinne Standards Track [Page 2]
RFC 3262 Reliability of Provisional Responses in SIP June 2002
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]
indicate requirement levels for compliant SIP implementations
3 UAS
A UAS MAY send any non-100 provisional response to INVITE reliably
so long as the initial INVITE request (the request whose
response is being sent reliably) contained a Supported header
with the option tag 100rel. While this specification does not
reliable provisional responses for any method but INVITE,
that define new methods that can establish dialogs may make use
the mechanism
The UAS MUST send any non-100 provisional response reliably if
initial request contained a Require header field with the option
100rel. If the UAS is unwilling to do so, it MUST reject the
request with a 420 (Bad Extension) and include an Unsupported
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
field indicating this feature, the UAS MUST NOT send the
response reliably
100 (Trying) responses are hop-by-hop only. For this reason,
reliability mechanisms described here, which are end-to-end
cannot be used
An element that can act as a proxy can also send reliable
responses. In this case, it acts as a UAS for purposes of
transaction. However, it MUST NOT attempt to do so for any
that contains a tag in the To field. That is, a proxy
generate reliable provisional responses to requests sent within
context of a dialog. Of course, unlike a UAS, when the proxy
receives a PRACK that does not match any outstanding
provisional response, the PRACK MUST be proxied
There are several reasons why a UAS might want to send a
provisional response. One reason is if the INVITE transaction
take some time to generate a final response. As discussed in
13.3.1.1 of RFC 3261, the UAS will need to send periodic
responses to request an "extension" of the transaction at proxies
The requirement is that a proxy receive them every three minutes,
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
recommended) because of the possibility of packet loss. As a
efficient alternative, the UAS can send the response reliably,
which case the UAS SHOULD send provisional responses once every
and a half minutes. Use of reliable provisional responses
extending transactions is RECOMMENDED
The rest of this discussion assumes that the initial
contained a Supported or Require header field listing 100rel,
that there is a provisional response to be sent reliably
The provisional response to be sent reliably is constructed by
UAS core according to the procedures of Section 8.2.6 of RFC 3261.
In addition, it MUST contain a Require header field containing
option tag 100rel, and MUST include an RSeq header field. The
of the header field for the first reliable provisional response in
transaction MUST be between 1 and 2**31 - 1. It is RECOMMENDED
it be chosen uniformly in this range. The RSeq numbering space
within a single transaction. This means that provisional
for different requests MAY use the same values for the RSeq number
The reliable provisional response MAY contain a body. The usage
session descriptions is described in Section 5.
The reliable provisional response is passed to the transaction
periodically with an interval that starts at T1 seconds and
for each retransmission (T1 is defined in Section 17 of RFC 3261).
Once passed to the server transaction, it is added to an
list of unacknowledged reliable provisional responses.
transaction layer will forward each retransmission passed from
UAS core
This differs from retransmissions of 2xx responses,
intervals cap at T2 seconds. This is because retransmissions
ACK are triggered on receipt of a 2xx, but retransmissions
PRACK take place independently of reception of 1xx
Retransmissions of the reliable provisional response cease when
matching PRACK is received by the UA core. PRACK is like any
request within a dialog, and the UAS core processes it according
the procedures of Sections 8.2 and 12.2.2 of RFC 3261. A
PRACK is defined as one within the same dialog as the response,
whose method, CSeq-num, and response-num in the RAck header
match, respectively, the method from the CSeq, the sequence
from the CSeq, and the sequence number from the RSeq of the
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
unacknowledged reliable provisional response, the UAS MUST respond
the PRACK with a 481 response. If the PRACK does match
unacknowledged reliable provisional response, it MUST be responded
with a 2xx response. The UAS can be certain at this point that
provisional response has been received in order. It SHOULD
retransmissions of the reliable provisional response, and MUST
it from the list of unacknowledged provisional responses
If a reliable provisional response is retransmitted for 64*T1
without reception of a corresponding PRACK, the UAS SHOULD reject
original request with a 5xx response
If the PRACK contained a session description, it is processed
described in Section 5 of this document. If the PRACK
contained any other type of body, the body is treated in the same
that body in an ACK would be treated
After the first reliable provisional response for a request has
acknowledged, the UAS MAY send additional reliable
responses. The UAS MUST NOT send a second reliable
response until the first is acknowledged. After the first, it
RECOMMENDED that the UAS not send an additional reliable
response until the previous is acknowledged. The first
provisional response receives special treatment because it
the initial sequence number. If additional reliable
responses were sent before the first was acknowledged, the UAS
not be certain these were received in order
The value of the RSeq in each subsequent reliable
response for the same request MUST be greater by exactly one.
numbers MUST NOT wrap around. Because the initial one is chosen
be less than 2**31 - 1, but the maximum is 2**32 - 1, there can be
to 2**31 reliable provisional responses per request, which is
than sufficient
The UAS MAY send a final response to the initial request
having received PRACKs for all unacknowledged reliable
responses, unless the final response is 2xx and any of
unacknowledged reliable provisional responses contained a
description. In that case, it MUST NOT send a final response
those provisional responses are acknowledged. If the UAS does send
final response when reliable responses are still unacknowledged,
SHOULD NOT continue to retransmit the unacknowledged
provisional responses, but it MUST be prepared to process
requests for those outstanding responses. A UAS MUST NOT send
reliable provisional responses (as opposed to retransmissions
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
When the UAC creates a new request, it can insist on
delivery of provisional responses for that request. To do that,
inserts a Require header field with the option tag 100rel into
request. A Require header with the value 100rel MUST NOT be
in any requests excepting INVITE, although extensions to SIP
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
___________________________________
Accept R
Accept 2xx -
Accept 415
Accept-Encoding R
Accept-Encoding 2xx -
Accept-Encoding 415
Accept-Language R
Accept-Language 2xx -
Accept-Language 415
Alert-Info R -
Alert-Info 180 -
Allow R
Allow 2xx
Allow r
Allow 405
Authentication-Info 2xx
Authorization R
Call-ID c
Call-Info -
Contact R -
Contact 1xx -
Contact 2xx -
Contact 3xx
Contact 485
Content-Disposition
Content-Encoding
Content-Language
Content-Length
Content-Type *
CSeq c
Date
Error-Info 300-699
Expires -
From c
In-Reply-To R -
Max-Forwards R
Min-Expires 423 -
MIME-Version
Organization -
Table 1: Summary of header fields, A--
Rosenberg & Schulzrinne Standards Track [Page 7]
RFC 3262 Reliability of Provisional Responses in SIP June 2002
Header field where
__________________________________________
Priority R -
Proxy-Authenticate 407
Proxy-Authenticate 401
Proxy-Authorization R
Proxy-Require R
Record-Route R
Record-Route 2xx,18x
Reply-To -
Require
Retry-After 404,413,480,486
500,503
600,603
Route R
Server r
Subject R -
Supported R
Supported 2xx
Timestamp
To c
Unsupported 420
User-Agent
Via c
Warning r
WWW-Authenticate 401
Table 2: Summary of header fields, P--
If the UAC does not wish to insist on usage of reliable
responses, but merely indicate that it supports them if the UAS
to send one, a Supported header MUST be included in the request
the option tag 100rel. The UAC SHOULD include this in all
requests
If a provisional response is received for an initial request,
that response contains a Require header field containing the
tag 100rel, the response is to be sent reliably. If the response
a 100 (Trying) (as opposed to 101 to 199), this option tag MUST
ignored, and the procedures below MUST NOT be used
Rosenberg & Schulzrinne Standards Track [Page 8]
RFC 3262 Reliability of Provisional Responses in SIP June 2002
The provisional response MUST establish a dialog if one is not
created
Assuming the response is to be transmitted reliably, the UAC
create a new request with method PRACK. This request is sent
the dialog associated with the provisional response (indeed,
provisional response may have created the dialog). PRACK
MAY contain bodies, which are interpreted according to their type
disposition
Note that the PRACK is like any other non-INVITE request within
dialog. In particular, a UAC SHOULD NOT retransmit the PRACK
when it receives a retransmission of the provisional response
acknowledged, although doing so does not create a protocol error
Once a reliable provisional response is received, retransmissions
that response MUST be discarded. A response is a retransmission
its dialog ID, CSeq, and RSeq match the original response. The
MUST maintain a sequence number that indicates the most
received in-order reliable provisional response for the
request. This sequence number MUST be maintained until a
response is received for the initial request. Its value MUST
initialized to the RSeq header field in the first
provisional response received for the initial request
Handling of subsequent reliable provisional responses for the
initial request follows the same rules as above, with the
difference: reliable provisional responses are guaranteed to be
order. As a result, if the UAC receives another reliable
response to the same request, and its RSeq value is not one
than the value of the sequence number, that response MUST NOT
acknowledged with a PRACK, and MUST NOT be processed further by
UAC. An implementation MAY discard the response, or MAY cache
response in the hopes of receiving the missing responses
The UAC MAY acknowledge reliable provisional responses received
the final response or MAY discard them
5 The Offer/Answer Model and
RFC 3261 describes guidelines for the sets of messages in
offers and answers [3] can appear. Based on those guidelines,
extension provides additional opportunities for offer/
exchanges
If the INVITE contained an offer, the UAS MAY generate an answer in
reliable provisional response (assuming these are supported by
UAC). That results in the establishment of the session
Rosenberg & Schulzrinne Standards Track [Page 9]
RFC 3262 Reliability of Provisional Responses in SIP June 2002
completion of the call. Similarly, if a reliable
response is the first reliable message sent back to the UAC, and
INVITE did not contain an offer, one MUST appear in that
provisional response
If the UAC receives a reliable provisional response with an
(this would occur if the UAC sent an INVITE without an offer,
which case the first reliable provisional response will contain
offer), it MUST generate an answer in the PRACK. If the UAC
a reliable provisional response with an answer, it MAY generate
additional offer in the PRACK. If the UAS receives a PRACK with
offer, it MUST place the answer in the 2xx to the PRACK
Once an answer has been sent or received, the UA SHOULD establish
session based on the parameters of the offer and answer, even if
original INVITE itself has not been responded to
If the UAS had placed a session description in any
provisional response that is unacknowledged when the INVITE
accepted, the UAS MUST delay sending the 2xx until the
response is acknowledged. Otherwise, the reliability of the 1
cannot be guaranteed, and reliability is needed for proper
of the offer/answer exchange
All user agents that support this extension MUST support
offer/answer exchanges that are possible based on the rules
Section 13.2 of RFC 3261, based on the existence of INVITE and
as requests, and 2xx and reliable 1xx as non-failure
responses
6 Definition of the PRACK
This specification defines a new SIP method, PRACK. The semantics
this method are described above. Tables 1 and 2 extend Tables 2
3 from RFC 3261 for this new method
7 Header Field
This specification defines two new header fields, RAck and RSeq
Table 3 extends Tables 2 and 3 from RFC 3261 for these headers
7.1
The RSeq header is used in provisional responses in order to
them reliably. It contains a single numeric value from 1 to 2**32 -
1. For details on its usage, see Section 3.
Rosenberg & Schulzrinne Standards Track [Page 10]
RFC 3262 Reliability of Provisional Responses in SIP June 2002
Example
RSeq: 988789
Header field where proxy ACK BYE CAN INV OPT REG
______________________________________________________
RAck R - - - - - -
RSeq 1xx - - - o - - -
Table 3: RAck and RSeq Header
7.2
The RAck header is sent in a PRACK request to support reliability
provisional responses. It contains two numbers and a method tag
The first number is the value from the RSeq header in the
response that is being acknowledged. The next number, and
method, are copied from the CSeq in the response that is
acknowledged. The method name in the RAck header is case sensitive
Example
RAck: 776656 1
8 IANA
This document registers a new option tag and two new headers,
on the IANA registration process of RFC 3261.
8.1 IANA Registration of the 100rel Option
This specification registers a single option tag, 100rel.
required information for this registration, as specified in RFC 3261,
is
Name: 100
Description: This option tag is for reliability of
responses. When present in a Supported header, it
that the UA can send or receive reliable provisional responses
When present in a Require header in a request, it
that the UAS MUST send all provisional responses reliably
When present in a Require header in a reliable
response, it indicates that the response is to be
reliably
Rosenberg & Schulzrinne Standards Track [Page 11]
RFC 3262 Reliability of Provisional Responses in SIP June 2002
8.2 IANA Registration of RSeq and RAck
The following is the registration for the RSeq header
RFC Number: RFC3262
Header Name:
Compact Form:
The following is the registration for the RAck header
RFC Number: RFC3262
Header Name:
Compact Form:
9 Security
The PRACK request can be injected by attackers to
retransmissions of reliable provisional responses to cease. As
responses can convey important information, PRACK messages SHOULD
authenticated as any other request. Authentication procedures
specified in RFC 3261.
10 Collected
The BNF for the RAck and RSeq headers and the PRACK method
defined here
PRACKm = %x50.52.41.43.4B ; PRACK in
Method = INVITEm / ACKm / OPTIONSm /
/ CANCELm / REGISTERm /
/ extension-
RAck = "RAck" HCOLON response-num LWS CSeq-num LWS
response-num = 1*
CSeq-num = 1*
RSeq = "RSeq" HCOLON response-
11
The authors would like to thank Jo Hornsby, Jonathan Lennox,
Mahy, Allison Mankin, Adam Roach, and Tim Schroeder for the
on this document
Rosenberg & Schulzrinne Standards Track [Page 12]
RFC 3262 Reliability of Provisional Responses in SIP June 2002
12 Normative
[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.
[2] Bradner, S., "Key Words for Use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[3] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
SDP", RFC 3264, June 2002.
13 Informative
[4] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
14 Authors'
Jonathan
72 Eagle Rock
First
East Hanover, NJ 07936
EMail: jdrosen@dynamicsoft.
Henning
Columbia
M/S 0401
1214 Amsterdam Ave
New York, NY 10027-7003
EMail: schulzrinne@cs.columbia.
Rosenberg & Schulzrinne Standards Track [Page 13]
RFC 3262 Reliability of Provisional Responses in SIP June 2002
15. Full Copyright
Copyright (C) The Internet Society (2002). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Rosenberg & Schulzrinne Standards Track [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
