One document matched: draft-ietf-sip-100rel-00.txt
Reliability of Provisional Responses in SIP
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as work in progress.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document specifies an extension to the Session Initiation
Protocol (SIP) providing reliable provisional response messages. This
extension uses the option tag org.ietf.sip.100rel.
1 Introduction
The Session Initiation Protocol (SIP) [1] is a request-response
protocol for initiating, maintaining, and terminating multimedia
sessions. Each SIP request is followed by one or more provisional
responses, followed by a one or more definitive responses. These
provisional responses, also called informational responses, have
status codes within the 100-199 range. They are most commonly used
for responses to an INVITE request. They provide information on call
progress, such as trying (100), alerting (180), queueing (182), and
J.Rosenberg,H.Schulzrinne [Page 1]
Internet Draft 100 Reliability January 16, 2000
session progress (183) [2]. However, when run over UDP, SIP does not
guarantee that these messages are delivered reliably, or in order.
However, a number of applications require reliability and in-order
delivery of provisional responses to INVITE. These include gateway
applications, wireless phones, ACD servers, and call queueing
systems. Generally, these applications make use of the provisional
responses to drive state machinery. This is especially true for the
180 Ringing provisional response, which maps to the Q.931 ALERTING
message.
This document provides a simple extension to SIP for ensuring that
provisional responses to all SIP requests are delivered reliably end
to end, independent of the underlying transport mechanism. The
extension works for provisional responses for any method. The
extension is simple, requiring two new header fields, and one new
method. The extension does not require support in proxies. The
extension is indicated with the option tag org.ietf.sip.100rel.
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 [3] and
indicate requirement levels for compliant implementations.
3 Overview
The reliability mechanism is based on the standard windowed
acknowledgement technique. When a server generates a provisional
response which is to be delivered reliably, it places a sequence
number (via the RSeq header field) in the provisional response. These
sequence numbers are chosen with a random initial value, for security
reasons. The provisional response is then retransmitted with an
exponential backoff, in a fashion that is identical to final
responses to INVITE. Note that a UAS MUST NOT send a response
reliably unless there was a Supported header in the request
indicating support for this extension [4].
Note that the reliability provided is NOT hop-by-hop. Proxies do not
retransmit the provisional responses; they are simply forwarded. This
is similar to the way in which 200 responses for INVITE messages are
handled in proxies. Note, however, that the PRACK message described
here is sent reliably using the same hop-by-hop techniques for all
non-INVITE requests.
The provisional response is then received at the UAC. The UAC can
determine that the response is to be transmitted reliably by the
J.Rosenberg,H.Schulzrinne [Page 2]
Internet Draft 100 Reliability January 16, 2000
presence of the RSeq header. Responses which are not transmitted
reliably do not contain the RSeq header.
For a provisional response which is to be sent reliably, the UAC
creates a new request, with a method of PRACK, used to acknowledge
one or more provisional responses (PRACK is a cumulative
acknowledgement). The PRACK request is like any other non-INVITE
request sent within a call. The PRACK request contains the same
Call-ID as the provisional response it is acknowledging. The CSeq
number in the PRACK is higher than that of the request whose
provisional response it acknowledges. The PRACK also contains a
header, called RAck, which contains the highest value of the RSeq
among the provisional responses being acknowledged. The RAck header
also contains the contents of the CSeq field in the response being
acknowledged. The combination of Call-ID, CSeq, and RAck allow the
PRACK request to be matched to a set of provisonal responses within a
specific transaction within a specific call. Like any other non-
INVITE request, the PRACK request is retransmitted periodically up to
a maximum of a four second interval. Note that the PRACK request is
SHOULD NOT be retransmitted when retransmissions of the provisional
response are received.
When the UAS receives the PRACK request, it knows that the set of
provisional responses have been received. The UAS then ceases
retransmission of those provisional responses. It also generates a
200 OK response to the PRACK, and sends it to the UAC. As with any
other non-INVITE request, the 200 response to the PRACK request MUST
be retransmitted when retransmissions of the PRACK request are
received.
When the UAC receives the 200 response (or any other final response)
to the PRACK, it stops retransmitting the PRACK. This is standard
behavior for non-INVITE requests.
The UAS MUST NOT generate an additional reliable provisional response
until the first is acknowledged. After the first is acknowledged, the
UAS MAY send subsequent reliable provisional responses without
waiting for acknowledgements of the previous. Since the PRACK request
is a cumulative acknowledgement, a UAC MAY send a single PRACK for
several provisional responses. However, for purposes of congestion
control, it is RECOMMENDED that a UAS wait for the acknowledgement of
a provisional response before sending the next. This effectively
means that reliable provisional responses can be sent at a rate of at
most per one per RTT (it may be less if there is loss).
4 Extension Syntax
Two new header fields are defined, RSeq and RAck, in addition to a
J.Rosenberg,H.Schulzrinne [Page 3]
Internet Draft 100 Reliability January 16, 2000
new method, PRACK. The BNF for the headers are:
RSeq = "RSeq" ":" response-num
RAck = "RAck" ":" response-num CSeq-num Method
response-num = 1*DIGIT
CSeq-num = 1*DIGIT
RSeq is a response header field. RAck is a request header field.
The RSeq number in any reliable provisional response MUST be between
1 and 2**32 - 1. The value in the first reliable provisional response
is randomly chosen by the UAS. It 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 request. This means that
provisional responses for different requests MAY use the same values
for the RSeq number. Reliable provisional responses for the same
request MUST contain RSeq values which increment by exactly one for
each response. 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 RAck header 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 specified here is called PRACK.
Prack = "PRACK"
As with other methods, the PRACK method name is case sensitive. The
method in the RAck header is also case sensitive.
This document specifies the named extension org.ietf.sip.100rel.
This feature name is placed in the Supported or Unsupported header in
requests.
5 Detailed Protocol Semantics
In this section, we discuss the detailed behavior required from user
agent clients, user agent servers, and proxies, in order to implement
J.Rosenberg,H.Schulzrinne [Page 4]
Internet Draft 100 Reliability January 16, 2000
this extension.
5.1 UAC Behavior
If a UAC supports this extension, it MAY include a Supported header
with the name org.ietf.sip.100rel listed as a feature token. If the
UAC does not insert this header in an initial request, and it
receives an error response with either a Require or Proxy-Require
header indicating this feature, the UAC MUST resubmit the request,
and this time include the Supported header listing this feature. This
behavior is specified in the server side feature extension
specification [4]. The rest of this discussion assumes this header
has been inserted into a request. The request whose provisional
response is being reliably sent is referred to as the initial
request.
If a provisional response is received for the initial request, and
that response contains an RSeq header, the response is to be sent
reliably. If the response is a 100 (as opposed to 101 to 199), the
RSeq in the response is ignored. The reliability mechanisms defined
here MUST NOT be used on 100 responses.
100 responses are hop by hop only. For this reason, the
reliability mechanisms described here, which are end to
end, cannot be used.
If the received provisional response was not a 100, and contained an
RSeq header, the UAC MUST create a new request with method PRACK. The
Call-ID in this request MUST match that of the provisional response.
The CSeq in this request MUST be larger than the last request (PRACK
or otherwise) sent by this UAC for this call leg. The To, From, and
Via headers MUST be present, and MUST be constructed as they would be
for a re-INVITE or BYE as specified in [1]. In particular, if the
provisional response contained a tag in the To field, this tag MUST
be mirrored in the To field of the PRACK.
Since reliable provisional responses MAY contain Record-Route and
Contact headers, the PRACK request MUST contain Route headers if the
Record-Route headers were present in the provisional response. The
Route header is constructed as specified in [1]. The Route header
that is constructed from some provisional response MUST NOT be placed
in any other request except for the PRACK for that provisional
response.
Since provisional responses can arrive from different
UAS's, and from proxies, the routes to those entities will
J.Rosenberg,H.Schulzrinne [Page 5]
Internet Draft 100 Reliability January 16, 2000
all be different. This means a Record-Route in one response
may be different from the Record-Route in another. To make
sure the PRACK request gets to the right place, it has to
contain the Route header that comes from the Record-Route
header in the response it acknowledges.
A UAC MUST NOT insert a Route header into a PRACK request if no
Record-Route header was present in the response.
PRACK requests MAY contain bodies. This is useful for establishing
early media sessions for tones and announcements, or for setting up
security or network preconditions for call completion [5][6].
If the initial request was sent with credentials, the PRACK request
SHOULD contain those credentials as well.
It is not neccesary to include the Supported header listing the
feature org.ietf.sip.100rel in the PRACK request. The usage of this
method implicitly indicates support for this extension. An
implementation MUST NOT send a PRACK request if this extension is not
supported.
Once the PRACK request is created, it is sent by the UAC. It is sent
as would any other non-INVITE request for a call. In particular, when
sent over UDP, the PRACK request is retransmitted with an
exponentially increasing interval, starting at 500 milliseconds and
increasing to 4 seconds. Note that 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. As with any other non-INVITE request, the UAC
continues to retransmit the PRACK request until it receives a final
response. A reliable provisional response for which a PRACK request
has been sent is called an acknowledged reliable provisional
response.
A PRACK request MAY be cancelled. However, whilst allowed for
purposes of generality, usage of CANCEL with PRACK is NOT
RECOMMENDED.
Handling of subsequent reliable provisional responses for the same
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 a reliable provisional
response, and its RSeq value isn't one higher than the previous
acknowledged reliable provisional response, that response MUST NOT be
acknowledged with a PRACK. An implementation MAY discard the
response, or MAY cache the response in the hopes of receiving the
missing responses. Note that this requires the UAC to store the RSeq
J.Rosenberg,H.Schulzrinne [Page 6]
Internet Draft 100 Reliability January 16, 2000
value of the last acknowledged reliable provisional response for the
duration of the transaction.
If the UAC has received a sequence of reliable provisional responses,
and there are no gaps in the RSeq values among those responses, and
the lowest RSeq value is one higher than the last acknowledged
reliable provisional response, the UAC MAY send a single PRACK
request to acknowledge the entire sequence. The RAck header in the
PRACK refers to the highest received RSeq value. It acknowledges
receipt of all reliable provisional responses up to, and including,
the one whose RSeq value is listed in the RAck.
5.2 UAS Behavior
The UAS MAY send any provisional response reliably, so long as the
initial request contained a Supported header indicating that this
feature is understood. If the request did not include a Supported
header indicating this feature, and it did not include a Unsupported
header indicating this feature, and the UAS wishes to send some
provisional responses reliably, the UAS SHOULD reject the intitial
request and include a Require header in the response, as per [4]. In
addition, the UAS MUST NOT attempt to send a 100 response reliably.
Only responses numbered 101 to 199 MAY be sent reliably. The rest of
this discussion assumes that the initial request contained a
Supported header listing this feature, and that there is a response
to be sent reliably.
Note that a UAS MAY send reliable provisional responses for any
request, including a PRACK request. It is anticipated that reliable
provisional responses will be most useful for INVITE requests.
The provisional response to be sent reliably MUST include an RSeq
header. The numeric value of this header is chosen randomly for the
first provisional response for a given request as described in
section 4. The value in each subsequent reliable provisional response
for the same request MUST be greater by exactly one. The RSeq
numbering space is within a single request. This means that
provisional responses for different requests MAY use the same values
for the RSeq number.
Reliable provisional respones MAY contain a body. If the initial
request contained Record-Route headers, the provisional response MUST
contain a copy of those headers, as if the response were a 200 OK to
the initial request. As with any other response, reliable provisional
responses MUST mirror the From, Call-ID, CSeq, Via, and To fields
from the request. The UAS MUST insert a tag into the To field of the
provisional response. The reliable provisional response MUST contain
a Contact header.
J.Rosenberg,H.Schulzrinne [Page 7]
Internet Draft 100 Reliability January 16, 2000
The reliable provisional response is retransmitted periodically, even
if sent over TCP. The retransmission interval starts at 500 ms, and
doubles after each retransmission, up to a maximum of 32 seconds.
This mirrors the behavior of INVITE responses in [1]. If no PRACK is
received for that response after 96 seconds, it is considered a
network or endpoint failure. Behavior at that point is at the
discretion of the implementor.
The UAS then waits for a PRACK request. It matches the PRACK request
to a reliable provisional response through the Call-ID, To, and From,
which identify the call-leg of the PRACK, and through the RAck
header, which identifies the particular request and provisional
response within the call leg. Specifically, a PRACK request X matches
a provisional response Y if all of the following are true:
o The Call-ID in X matches the Call-ID in Y.
o The From in X matches the From in Y, including the tag, if
present.
o The To in X matches the To in Y, including the tag, if
present. If Y did not contain a tag, but X did, these do not
match. If Y did contain a tag, but X does not, these do match.
o The method in the RAck of X matches the method in the CSeq of
Y.
o The CSeq-num in the RAck matches the CSeq number in Y.
o The response-num in the RAck is greater than or equal to the
RSeq value in Y.
Note that a single PRACK may match multiple provisional responses.
Only one response is sent to the PRACK.
If a PRACK request is received that does not match any reliable
provisional response, the UAS responds to the PRACK with a 481
response.
PRACK requests MAY be authenticated. If the UAS requires
authentication of the requestor, and the PRACK does not contain
credentials, or contains bad credentials, the UAS MAY respond to the
PRACK with a 401, as outlined in [1], and include a challenge in the
response.
If a PRACK request is received that does match some provisional
responses for which no PRACK has been received, the provisional
response retransmissions for those responses cease. The UAS generates
J.Rosenberg,H.Schulzrinne [Page 8]
Internet Draft 100 Reliability January 16, 2000
a 200 OK response to the PRACK, and sends it. The rules for
generation of the 200 OK for the PRACK, and for its transmission,
follow those for any non-INVITE method outlined in [1]. The UAS can
be certain at this point that those provisional responses have been
received in order.
If a PRACK request is received that does match some provisional
responses, but a different PRACK has been received for all those
responses already (different meaning the PRACK had a different CSeq
value), the new PRACK is responded to with a 200 OK. There is no need
to stop retransmissions of those reliable provisional responses that
match, since their retransmissions will have already ceased from the
previous PRACK.
If the PRACK contained a body, the body is treated in the same way a
body in an ACK is treated.
As with any other non-INVITE request, if a retransmission of the
PRACK request is received, the response to the PRACK is
retransmitted. There is no need to retransmit the reliable
provisional response when a PRACK is received.
A PRACK request MAY be cancelled. If a UAS receives a CANCEL request
for a PRACK before it has sent a final response to the PRACK, the
PRACK is responded to with a 487, and the UAS acts as if the PRACK
were never received. However, whilst allowed for purposes of
generality, usage of CANCEL with PRACK is NOT RECOMMENDED.
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 additional reliable provisional
responses until the previous is acknowledged. The first reliable
provisional response receives special treatment because it conveys
the intitial sequence number. If additional reliable provisional
responses were sent before the first is acknowledged, the UAS could
not be certain these were received in order.
5.3 Proxy Behavior
This extension does not require active participation from proxies. As
far as they are concerned, the PRACK is just another request to be
forwarded. In most cases, the PRACK will have Route headers to
indicate its proxy path. If there is no Route header, the PRACK is
forwarded as any other request without a Route header. Rules for
forking of a PRACK follow those for any non-INVITE request; the best
response is forwarded upstream.
J.Rosenberg,H.Schulzrinne [Page 9]
Internet Draft 100 Reliability January 16, 2000
The only requirement for proxies is that they MUST pass all
provisional responses upstream. RFC 2543 does not mandate that
provisional responses are forwarded.
Note that proxies MAY generate their own provisional responses to be
sent reliably. When they do so, they follow the rules in Section 5.2,
playing the role of the UAS, with the following exceptions.
PRACK requests which do not match a provisional response sent
reliably by the proxy are forwarded, rather than responded to with a
481. A PRACK that does match a provisional response sent by the proxy
MUST NOT be forwarded.
To ensure that the PRACK request is routed to the right proxy, a
proxy MUST copy the Record-Route header from the received initial
request into the reliable provisional response. Furthermore, the
proxy MUST then add itself as the first entry in the Record-Route
header returned in the provisional response. If no Record-Route
header was present in the request, and thus none copied to the
response, the proxy MUST create one in the response and add itself as
the only entry. Note that it is not required for the proxy to insert
itself into the Record-Route header of the request that is forwarded
downstream. This allows a proxy to receive PRACK requests for its own
responses, but not be on the signaling path for subsequent requests.
Note that a proxy MUST insert a tag in the To field of the
provisional response. This ensures that PRACK requests for
provisional responses generated by different proxies can be processed
at the right proxy. The reliable provisional responses from two
different proxies, for the same request, differ only in their tag in
the To field. Therefore, to match the PRACK request to a provisional
response, the tag in the To header must be used.
6 Examples
6.1 Message Formatting
In this example, a UAC sends an INVITE to a UAS directly. The UAS
sends a 183 response reliably.
The initial request looks like:
C->S: INVITE sip:watson@bell-tel.com SIP/2.0
Via: SIP/2.0/UDP saturn.bell-tel.com
Supported: org.ietf.sip.100rel, org.ietf.sip.supported
From: sip:alexander@bell-tel.com
To: sip:watson@bell-tel.com
J.Rosenberg,H.Schulzrinne [Page 10]
Internet Draft 100 Reliability January 16, 2000
Call-ID: 70710@saturn.bell-tel.com
CSeq: 1 INVITE
Subject: Come here Watson
The server first responds with a 100:
S->C: SIP/2.0 100 Trying
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:alexander@bell-tel.com
To: sip:watson@bell-tel.com
Call-ID: 70710@saturn.bell-tel.com
CSeq: 1 INVITE
and then with a 183 that is sent reliably:
S->C: SIP/2.0 183 Proceeding
Via: SIP/2.0/UDP saturn.bell-tel.com
RSeq: 776655
From: sip:alexander@bell-tel.com
To: sip:watson@bell-tel.com;tag=11
Call-ID: 70710@saturn.bell-tel.com
CSeq: 1 INVITE
Content-Type: application/sdp
v=0
s=Let's talk
b=CT:128
c=IN IP4 north.east.isi.edu
m=audio 3456 RTP/AVP 5 0 7
m=video 2232 RTP/AVP 31
This response is retransmitted with an exponential backoff. When the
UAC receives the response, it sends a PRACK:
C->S: PRACK sip:watson@bell-tel.com SIP/2.0
RAck: 776655 1 INVITE
Via: SIP/2.0/UDP saturn.bell-tel.com
Supported: org.ietf.sip.supported
From: sip:alexander@bell-tel.com
J.Rosenberg,H.Schulzrinne [Page 11]
Internet Draft 100 Reliability January 16, 2000
To: sip:watson@bell-tel.com;tag=11
Call-ID: 70710@saturn.bell-tel.com
CSeq: 2 PRACK
Content-Type: application/sdp
v=0
s=Let's talk
b=CT:128
c=IN IP4 machine.bell-tel.com
m=audio 3456 RTP/AVP 5 0 7
m=video 2232 RTP/AVP 31
Upon receiving this, the UAS stops retransmitting the 183, and sends
a 200 OK to the PRACK:
S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:alexander@bell-tel.com
To: sip:watson@bell-tel.com;tag=11
Call-ID: 70710@saturn.bell-tel.com
CSeq: 2 PRACK
The UAS then sends two provisional responses in rapid succession:
S->C: SIP/2.0 182 Two in the Queue
Via: SIP/2.0/UDP saturn.bell-tel.com
RSeq: 776656
From: sip:alexander@bell-tel.com
To: sip:watson@bell-tel.com;tag=11
Call-ID: 70710@saturn.bell-tel.com
CSeq: 1 INVITE
S->C: SIP/2.0 182 One in the Queue
Via: SIP/2.0/UDP saturn.bell-tel.com
RSeq: 776657
From: sip:alexander@bell-tel.com
To: sip:watson@bell-tel.com;tag=11
Call-ID: 70710@saturn.bell-tel.com
CSeq: 1 INVITE
J.Rosenberg,H.Schulzrinne [Page 12]
Internet Draft 100 Reliability January 16, 2000
The UAC then receives these both, and sends a single PRACK to
acknowledge them both:
C->S: PRACK sip:watson@bell-tel.com SIP/2.0
RAck: 776657 1 INVITE
Via: SIP/2.0/UDP saturn.bell-tel.com
Supported: org.ietf.sip.supported
From: sip:alexander@bell-tel.com
To: sip:watson@bell-tel.com;tag=11
Call-ID: 70710@saturn.bell-tel.com
CSeq: 3 PRACK
This causes retransmission of both 181 responses to be stopped, and a
200 OK to the PRACK to be sent:
S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:alexander@bell-tel.com
To: sip:watson@bell-tel.com;tag=11
Call-ID: 70710@saturn.bell-tel.com
CSeq: 3 PRACK
Finally, the UAS sends a final response to the INVITE:
S->C: SIP/2.0 200 OK
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:alexander@bell-tel.com
To: sip:watson@bell-tel.com;tag=11
Call-ID: 70710@saturn.bell-tel.com
CSeq: 1 INVITE
Content-Type: application/sdp
v=0
s=Let's talk
b=CT:128
c=IN IP4 north.east.isi.edu
m=audio 3456 RTP/AVP 5 0 7
m=video 2232 RTP/AVP 31
J.Rosenberg,H.Schulzrinne [Page 13]
Internet Draft 100 Reliability January 16, 2000
And the UAC sends an ACK for the 200 OK:
C->S: ACK sip:watson@bell-tel.com SIP/2.0
Via: SIP/2.0/UDP saturn.bell-tel.com
From: sip:alexander@bell-tel.com
To: sip:watson@bell-tel.com;tag=11
Call-ID: 70710@saturn.bell-tel.com
CSeq: 1 INVITE
6.2 Message Flows
This section illustrates an example message flow using this
extension. We abbreviate a PRACK request with a RAck header value of
M N INVITE as "PRACK M N", an INVITE with a CSeq of N as "INV N", a
provisional response with a RSeq header value of M as "1xx M", and a
200 OK response to a PRACK as "200 PRACK". Packets which are lost are
shown with an "X" in front of them.
The ladder diagram considers the case of a direct request between a
UAC and UAS. The UAS sends a 100 response first, and then a 180
reliably. It then responds with a final response of 300.
UAC UAS
(request -------INV 1--------------->
retransmits
start)
X<.......100.........
-------INV 1---->X
-------INV 1-------------->
(request <..........100.............
retransmissions
cease)
X<...180 3............ (180 retransmits start)
<.........180 3............
(PRACK -------PRACK 3 1---->X
retransmits start)
<.........180 3............
-------PRACK 3 1----------> (180 retransmits cease)
X<....200 PRACK........
-------PRACK 3 1---------->
J.Rosenberg,H.Schulzrinne [Page 14]
Internet Draft 100 Reliability January 16, 2000
(PRACK 3 1 <.........200 PRACK........
retransmits
cease)
X<....300............... (300 class retransmits start)
<........300...............
-----------ACK------------> (300 retransmits cease)
7 Open Issues
There are a number of open issues:
1. Is PRACK an OK name for this request?
2. Do we need cumulative acknowledgements, or is to too
complex?
3. Should we simply disallow CANCEL for PRACK?
8 Security Considerations
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.
9 Acknowledgements
The authors would like to thank Jonathan Lennox and Adam Roach for
the comments on this document.
10 Author's Addresses
Jonathan Rosenberg
dynamicsoft
200 Executive Drive
Suite 120
West Orange, NJ 07052
email: jdrosen@dynamicsoft.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
J.Rosenberg,H.Schulzrinne [Page 15]
Internet Draft 100 Reliability January 16, 2000
email: schulzrinne@cs.columbia.edu
11 Bibliography
[1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments (Proposed
Standard) 2543, Internet Engineering Task Force, Mar. 1999.
[2] S. Donovan, H. Schulzrinne, J. Rosenberg, M. Cannon, and A.
Roach, "SIP 183 session progress message," Internet Draft, Internet
Engineering Task Force, Oct. 1999. Work in progress.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement
levels," Request for Comments (Best Current Practice) 2119, Internet
Engineering Task Force, Mar. 1997.
[4] J. Rosenberg and H. Schulzrinne, "Mandating SIP extension support
by servers," Internet Draft, Internet Engineering Task Force, Jan.
2000. Work in progress.
[5] J. Rosenberg, H. Schulzrinne, and S. Donovan, "Establishing QoS
and security preconditions for SDP sessions," Internet Draft,
Internet Engineering Task Force, June 1999. Work in progress.
[6] W. Marshall, K. Ramakrishnan, E. Miller, G. Russell, B. Beser, M.
Mannette, K. Steinbrenner, D. Oran, J. Pickens, P. Lalwaney, J.
Fellows, D. Evans, K. Kelly, and F. Andreasen, "Integration of
resource management and call signaling for IP telephony," Internet
Draft, Internet Engineering Task Force, Oct. 1999. Work in progress.
J.Rosenberg,H.Schulzrinne [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-23 04:21:20 |