Internet Engineering Task Force                                   SIP WG
Internet Draft                                 J.Rosenberg,H.Schulzrinne
draft-ietf-sip-100rel-03.txt                     dynamicsoft,Columbia U.
March 2, 2001
Expires: September 2001


              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                March 2, 2001


   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 an extension to SIP for ensuring that
   provisional responses to all SIP requests can be delivered reliably
   end to end, independent of the underlying transport mechanism. The
   extension works for provisional responses for any method (excepting
   ACK, of course, which have no responses, and PRACK, defined here).
   The extension requires 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 Basic Overview

   The reliability mechanism works by mirroring the current reliability
   mechanisms for 200 class final responses to INVITE. As specified in
   RFC 2543, 200 class final responses to INVITE are retransmitted with
   an exponential backoff until an ACK is received, at which point, they
   stop. The reliability for the final responses and the ACK messages
   are end-to-end (that is, neither is retransmitted by intermediate
   proxies). In order to achieve reliability for provisional responses,
   we do nearly the same thing. Provisional responses are retransmitted
   with an exponential backoff. Those retransmisions 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. Provisional responses, like 200 class responses, are
   forwarded end-to-end without local retransmissions in proxies.
   However, unlike ACK, which is end-to-end, PRACK is a normal SIP
   message, like BYE. As such, its own reliability is ensured hop-by-hop
   through each stateful proxy. Similarly, PRACK has its own response.
   If this were not the case, the PRACK message could not traverse
   existing proxy servers.




J.Rosenberg,H.Schulzrinne                                     [Page 2]


Internet Draft              100 Reliability                March 2, 2001


   Each provisional response is given a sequence number, carried in a
   new header, RSeq, in the response. The PRACK messages contain an RAck
   header, which indicates the sequence number of the provisional
   response which is being acknowledged.

   To keep things simple, the acknowledgements are not cumulative, and
   the specifications recommend a single outstanding provisional
   response at a time, for purposes of congestion control.

4 Detailed Overview of Operation

   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 or Require header in the
   request indicating this extension [4].

   Proxies forward these provisional responses as they are received.
   There are no local retransmissions or processing of any other kind.
   Each provisional response received by a proxy is forwarded upstream.
   This is standard behavior in RFC2543 compliant proxies.


        Strictly speaking, RFC2543 makes forwarding of provisionals
        upstream optional. However, to our knowledge all existing
        proxies forward all provisional responses upstream.

   The provisional response is then received at the UAC. The UAC can
   determine that the response is to be transmitted reliably by the
   presence of the Require header containing the option tag 100rel [4].
   Responses which are not transmitted reliably do not contain this tag
   in a Require 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
   the provisional response. 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 the last request sent by the
   UAC. PRACK also contains a header, called RAck, which contains the
   value of the RSeq header for the provisional response being
   acknowledged. The RAck header also contains the contents of the CSeq
   field in the response being acknowledged. The combination of Call-ID,



J.Rosenberg,H.Schulzrinne                                     [Page 3]


Internet Draft              100 Reliability                March 2, 2001


   CSeq, and RAck allow the PRACK request to be matched to a specific
   provisonal response 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
   provisional response has been received. The UAS then ceases
   retransmission of that provisional response. 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. This is because the first reliable
   provisional response establishes the initial sequence number. If the
   UAS sent two reliable provisional responses, one right after the
   other, the UAC might receive the second one, accept it, and then
   receive the first, after having incorrectly accepted the other one.

   After the first is acknowledged, the UAS MAY send subsequent reliable
   provisional responses without waiting for acknowledgements of the
   previous. 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).

5 Extension Syntax

   Two new header fields are defined, RSeq and RAck, in addition to a
   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.




J.Rosenberg,H.Schulzrinne                                     [Page 4]


Internet Draft              100 Reliability                March 2, 2001


   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 name in the RAck header is also case sensitive.

   This document specifies the named extension 100rel This feature name
   is placed in the Supported or Require header in requests, or the
   Require, Supported or Unsupported header in responses [4].

6 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
   this extension.

6.1 UAC Behavior

   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. Otherwise, if a UAC supports this
   extension, it SHOULD include a Supported header into all requests
   (excepting ACK and PRACK), with the name  100rel listed as an option
   tag.

   The rest of this discussion assumes either the Require or Supported



J.Rosenberg,H.Schulzrinne                                     [Page 5]


Internet Draft              100 Reliability                March 2, 2001


   header has been inserted into a request containing the option tag
   100rel. 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 a Require header containing the option tag
   100rel, the response is to be sent reliably. If the response is a 100
   (as opposed to 101 to 199), this option tag 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.

   Assuming the response is to be transmitted reliably, 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. If the provisional response contained a Timestamp
   header, this is copied into the PRACK.

   Since reliable provisional responses MAY contain Record-Route headers
   (if the request was an initial INVITE, for example), the PRACK
   request MUST contain Route headers according to the procedures
   specified in [1], as if the PRACK were a BYE. 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. For reliable provisional responses to a request that
   contained Route headers, the PRACK MUST contain the same Route
   headers as the request.


        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
        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 (1) no
   Record-Route header was present in the response, and (2) no Route



J.Rosenberg,H.Schulzrinne                                     [Page 6]


Internet Draft              100 Reliability                March 2, 2001


   header was present in the request whose provisional response is being
   acknowledged.

   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. That is because a UAS MUST
   NOT generate reliable provisional responses to PRACK. An
   implementation MUST NOT send a PRACK request if this extension is not
   supported. Furthermore, an implementation MUST NOT include a Require
   header in the PRACK with the option tag 100rel, as reliable
   provisional responses to PRACK are forbidden.

   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.

   Note that the UAC MUST acknowledge a reliable provisional response as



J.Rosenberg,H.Schulzrinne                                     [Page 7]


Internet Draft              100 Reliability                March 2, 2001


   described above, even after a final response to the request has
   arrived.

6.2 UAS Behavior

   The UAS MAY send any non-100 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  100rel.

   A UAS MUST NOT attempt to send a 100 response reliably. Only
   responses numbered 101 to 199 may be sent reliably. A UAS MUST NOT
   send a reliable provisional response to a PRACK request, in order to
   avoid provisional/PRACK loops.

   If the request did not include either a Supported or Require header
   indicating this feature, the UAS SHOULD send the provisional response
   unreliably.

   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, excepting a PRACK request and ACK. 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 5. 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 (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



J.Rosenberg,H.Schulzrinne                                     [Page 8]


Internet Draft              100 Reliability                March 2, 2001


   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.

   Reliable provisional responses MAY contain a Timestamp header, which
   will be mirrored in the PRACK. This allows for RTT estimation. See
   section 7.

   The reliable provisional response is retransmitted periodically, even
   if sent over TCP. Computation of this retransmission interval is
   discussed in Section 7.

   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 matches the RSeq value in Y.

   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 matches a provisional response
   for which no PRACK has been received, the provisional response



J.Rosenberg,H.Schulzrinne                                     [Page 9]


Internet Draft              100 Reliability                March 2, 2001


   retransmission ceases. 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 the provisional response has been received in order.

   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 to the CANCEL 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.

   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 SHOULD continue to retransmit
   those outstanding responses, and 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
   outstanding ones) after sending a final response to a request.

6.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



J.Rosenberg,H.Schulzrinne                                    [Page 10]


Internet Draft              100 Reliability                March 2, 2001


   provisional responses upstream. RFC 2543 does not mandate that
   provisional responses are forwarded, although most proxy
   implementations do.

   Note that proxies MAY generate their own provisional responses to be
   sent reliably. When they do so, they follow the rules in Section 6.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
   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.

7 Retransmit Interval Computation

   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



J.Rosenberg,H.Schulzrinne                                    [Page 11]


Internet Draft              100 Reliability                March 2, 2001


   implementor.


        More information is needed here on using the RTT estimates
        measured with the Timestamp.

8 Examples

8.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;tag=736ad7789
         Contact: sip:alexander@host33.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;tag=736ad7789
         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
         Require: 100rel



J.Rosenberg,H.Schulzrinne                                    [Page 12]


Internet Draft              100 Reliability                March 2, 2001


         Via: SIP/2.0/UDP saturn.bell-tel.com
         RSeq: 776655
         From: sip:alexander@bell-tel.com;tag=736ad7789
         To: sip:watson@bell-tel.com;tag=11
         Call-ID: 70710@saturn.bell-tel.com
         Contact: sip:watson@mypc.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@mypc.bell-tel.com SIP/2.0
         RAck: 776655 1 INVITE
         Via: SIP/2.0/UDP saturn.bell-tel.com
         From: sip:alexander@bell-tel.com;tag=736ad7789
         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



J.Rosenberg,H.Schulzrinne                                    [Page 13]


Internet Draft              100 Reliability                March 2, 2001


         From: sip:alexander@bell-tel.com;tag=736ad7789
         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;tag=736ad7789
         To: sip:watson@bell-tel.com;tag=11
         Call-ID: 70710@saturn.bell-tel.com
         Contact: sip:watson@mypc.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;tag=736ad7789
         To: sip:watson@bell-tel.com;tag=11
         Call-ID: 70710@saturn.bell-tel.com
         Contact: sip:watson@mypc.bell-tel.com
         CSeq: 1 INVITE



   The UAC then receives these both, and sends a two PRACK requests to
   acknowledge them both:



   C->S: PRACK sip:watson@mypc.bell-tel.com SIP/2.0
         RAck: 776656 1 INVITE
         Via: SIP/2.0/UDP saturn.bell-tel.com
         From: sip:alexander@bell-tel.com;tag=736ad7789
         To: sip:watson@bell-tel.com;tag=11
         Call-ID: 70710@saturn.bell-tel.com
         CSeq: 3 PRACK






J.Rosenberg,H.Schulzrinne                                    [Page 14]


Internet Draft              100 Reliability                March 2, 2001


   C->S: PRACK sip:watson@mypc.bell-tel.com SIP/2.0
         RAck: 776657 1 INVITE
         Via: SIP/2.0/UDP saturn.bell-tel.com
         From: sip:alexander@bell-tel.com;tag=736ad7789
         To: sip:watson@bell-tel.com;tag=11
         Call-ID: 70710@saturn.bell-tel.com
         CSeq: 4 PRACK



   This causes retransmission of both 181 responses to be stopped, and a
   200 OK to each 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;tag=736ad7789
         To: sip:watson@bell-tel.com;tag=11
         Call-ID: 70710@saturn.bell-tel.com
         CSeq: 3 PRACK





   S->C: SIP/2.0 200 OK
         Via: SIP/2.0/UDP saturn.bell-tel.com
         From: sip:alexander@bell-tel.com;tag=736ad7789
         To: sip:watson@bell-tel.com;tag=11
         Call-ID: 70710@saturn.bell-tel.com
         CSeq: 4 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;tag=736ad7789
         To: sip:watson@bell-tel.com;tag=11
         Call-ID: 70710@saturn.bell-tel.com
         Contact: sip:watson@mypc.bell-tel.com
         CSeq: 1 INVITE
         Content-Type: application/sdp




J.Rosenberg,H.Schulzrinne                                    [Page 15]


Internet Draft              100 Reliability                March 2, 2001


         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@mypc.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



8.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



J.Rosenberg,H.Schulzrinne                                    [Page 16]


Internet Draft              100 Reliability                March 2, 2001


   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)




9 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.

10 Acknowledgements

   The authors would like to thank Jonathan Lennox, Adam Roach, and Tim
   Schroeder for the comments on this document.

11 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



J.Rosenberg,H.Schulzrinne                                    [Page 17]


Internet Draft              100 Reliability                March 2, 2001


   1214 Amsterdam Ave.
   New York, NY 10027-7003
   email: schulzrinne@cs.columbia.edu




12 Bibliography

   [1] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments 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 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
   progress.

   [5] W. Marshall, K. Ramakrishnan, et al.  , "Integration of resource
   management and SIP," Internet Draft, Internet Engineering Task Force,
   June 2000.  Work in progress.























J.Rosenberg,H.Schulzrinne                                    [Page 18]