One document matched: draft-ietf-sip-100rel-01.txt
Differences from draft-ietf-sip-100rel-00.txt
Internet Engineering Task Force SIP WG
Internet Draft J.Rosenberg,H.Schulzrinne
draft-ietf-sip-100rel-01.txt dynamicsoft,Columbia U.
May 28, 2000
Expires: November, 2000
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 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 May 28, 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 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 May 28, 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
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 May 28, 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 100rel This feature name
is placed in the Supported, Unsupported, or Require 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 May 28, 2000
this extension.
5.1 UAC Behavior
If a UAC supports this extension, it MUST include a Supported header
into all requests (excepting ACK), with the name 100rel listed as an
option tag. Alternatively, if the UAC wishes to insist that all
provisional responses are delivered reliably, it MUST include a
Require header into the request containing the option tag 100rel.
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, but 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 specific
provisional response.
Since provisional responses can arrive from different
UAS's, and from proxies, the routes to those entities will
all be different. This means a Record-Route in one response
may be different from the Record-Route in another. To make
J.Rosenberg,H.Schulzrinne [Page 5]
Internet Draft 100 Reliability May 28, 2000
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] 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
option tag 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 MUST NOT be cancelled - that is, a UAC MUST NOT ever
send a CANCEL for a PRACK request.
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 within the same call leg
(defined as the combination of To, From and Call-ID headers,
including tags), 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 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,
J.Rosenberg,H.Schulzrinne [Page 6]
Internet Draft 100 Reliability May 28, 2000
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.
Note that the UAC MUST acknowledge all reliable provisional responses
as described above, even after a final response to the request has
arrived.
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. The UAS MUST send any non-100 response
reliably if the initial request contained a Require header indicating
that the feature is mandatory for all provisional responses. If the
UAS is unwilling to do so, it MUST reject the initial request with a
420 (Bad Extension) and include a Unsupported header containing the
option tag /sf 100rel.
A UAS MUST NOT attempt to send a 100 response reliably. Only
responses numbered 101 to 199 may be sent reliably.
If the request did not include either a Supported or Require 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].
The rest of this discussion assumes that the initial request
contained a Supported or Require header listing this feature, and
that there is a provisional response to be sent reliably.
Note that a UAS can 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 a Require
header containing the option tag 100rel
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
J.Rosenberg,H.Schulzrinne [Page 7]
Internet Draft 100 Reliability May 28, 2000
provisional responses for different requests (where different is
defined in [1]) 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. This tag MUST also be used in the final
response. The reliable provisional response MUST contain a Contact
header.
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.
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
J.Rosenberg,H.Schulzrinne [Page 8]
Internet Draft 100 Reliability May 28, 2000
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 provisional responses
for which no PRACK has been received, the provisional response
retransmissions for those responses cease. The UAS generates 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 the
response to any non-INVITE request 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 matches 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 MUST NOT be cancelled. If a UAS receives a CANCEL
request for a PRACK, it MUST respond with a 405 (Method Not Allowed).
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 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.
J.Rosenberg,H.Schulzrinne [Page 9]
Internet Draft 100 Reliability May 28, 2000
Note that the UAS MAY send a final response to the initial request
before having received PRACKs for all outstanding reliable
provisional responses. However, it MUST be prepared to process PRACK
requests for those outstanding responses.
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.
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. The tag must also be
present to define a separate RSeq space for reliable provisional
J.Rosenberg,H.Schulzrinne [Page 10]
Internet Draft 100 Reliability May 28, 2000
responses generated by different proxies.
Finally, note that a proxy that wishes to send a non-100 provisional
response, MUST do so reliably if the Require header (NOT the Proxy-
Require header) is present in the request. This is because the proxy
is acting effectively as a user agent, and is thus bound by the
Require header instead of the Proxy-Require.
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: 100rel
From: sip:alexander@bell-tel.com
To: sip:watson@bell-tel.com
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
J.Rosenberg,H.Schulzrinne [Page 11]
Internet Draft 100 Reliability May 28, 2000
Require: 100rel
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: 100rel
From: sip:alexander@bell-tel.com
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
J.Rosenberg,H.Schulzrinne [Page 12]
Internet Draft 100 Reliability May 28, 2000
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
Require: 100rel
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
Require: 100rel
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
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: 100rel
From: sip:alexander@bell-tel.com
To: sip:watson@bell-tel.com;tag=11
Call-ID: 70710@saturn.bell-tel.com
CSeq: 3 PRACK
J.Rosenberg,H.Schulzrinne [Page 13]
Internet Draft 100 Reliability May 28, 2000
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
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
J.Rosenberg,H.Schulzrinne [Page 14]
Internet Draft 100 Reliability May 28, 2000
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---------->
(PRACK 3 1 <.........200 PRACK........
retransmits
cease)
X<....300............... (300 class retransmits start)
<........300...............
-----------ACK------------> (300 retransmits cease)
7 Security Considerations
J.Rosenberg,H.Schulzrinne [Page 15]
Internet Draft 100 Reliability May 28, 2000
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.
8 Acknowledgements
The authors would like to thank Jonathan Lennox and Adam Roach for
the comments on this document.
9 Author's Addresses
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
Henning Schulzrinne
Columbia University
M/S 0401
1214 Amsterdam Ave.
New York, NY 10027-7003
email: schulzrinne@cs.columbia.edu
10 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, "The SIP supported header,"
Internet Draft, Internet Engineering Task Force, Mar. 2000. Work in
J.Rosenberg,H.Schulzrinne [Page 16]
Internet Draft 100 Reliability May 28, 2000
progress.
[5] W. Marshall et al. , "Integration of resource management and SIP
for IP telephony," Internet Draft, Internet Engineering Task Force,
Mar. 2000. Work in progress.
J.Rosenberg,H.Schulzrinne [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 11:21:19 |