[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 RFC 3262

Internet Engineering Task Force                                   SIP WG
Internet Draft                                 J.Rosenberg,H.Schulzrinne
draft-ietf-sip-100rel-00.txt                     dynamicsoft,Columbia U.
January 16, 2000
Expires: July, 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 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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/