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

Versions: 00 01

Internet Engineering Task Force                                MMUSIC WG
Internet Draft                                 J.Rosenberg,H.Schulzrinne
draft-ietf-mmusic-sip-100rel-00.txt        Bell Laboratories,Columbia U.
November 18, 1998
Expires: May 1999


              Reliability of Provisional Responses in SIP

STATUS OF THIS MEMO

   This document is an Internet-Draft. 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''.

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or
   ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.

1 Abstract

   This document specifies an extension to the Session Initiation
   Protocol (SIP) providing reliable provisional response messages.

2 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 provide information on
   call progress, such as trying (100), alerting (180), and queuing
   (181). However, when run over UDP, SIP does not guarantee that these
   messages are delivered reliably, or in order. A server simply
   transmits a provisional response. If the client retransmits the
   request, the server retransmits the most recent response, provisional
   or otherwise.



J.Rosenberg,H.Schulzrinne                                     [Page 1]


Internet Draft              100 Reliability            November 18, 1998


   However, a number of applications require reliability and in-order
   delivery of provisional responses. 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 are delivered reliably, independent of the
   underlying transport mechanism. The extension is simple, requiring
   two new header fields, and no new methods. It fits well within the
   generic framework of SIP reliability.

3 Overview

   The reliability mechanism is based on the standard windowed
   acknowledgement technique. When a server generates a provisional
   response, it places a sequence number (via the  RSeq header field) in
   the provisional response. The sequence number always starts at zero.
   The sequence number space need only be unique within each Call-ID,
   To, and  CSeq tuple. Because of this, there is no need for randomized
   sequence number selection or SYN handshakes as in TCP.

   The server maintains a window of size 1, which is effectively the
   value of the highest unacknowledged provisional response that has
   been transmitted, call this rn. The client maintains a single
   variable, sn, which represents the highest in order provisional
   response received so far. Both sn and rn are initialized to -1.

   When the server wishes to send a provisional response, it increments
   rn, places its value in the  RSeq header field, and sends the
   response. The provisional response is retransmitted at intervals with
   an exponential backoff, starting at T1 (default of 500ms), and
   doubling after each retransmission. When the client receives the
   response, it checks the sequence number. If it is one higher than the
   current value of sn, sn is incremented, otherwise sn is unchanged. It
   then resends the original request (independently of whether the value
   of sn has changed), and includes the sequence number sn in the
   request in the header field  RAck.

   When the request is received at the server, if the sequence number in
   the message is equal to the current value of rn, the provisional
   response is no longer retransmitted. The server is free to increment
   rn and transmit another provisional response. If the value of the
   sequence number in the request is one less than the current value of
   rn, the response is retransmitted, and the server may not generate an
   additional provisional response.



J.Rosenberg,H.Schulzrinne                                     [Page 2]


Internet Draft              100 Reliability            November 18, 1998


   The mechanism is essentially TCP without congestion control, and with
   a window of one. The result is a fairly simple mechanism. However,
   the penalty is that the throughput of provisional responses is fairly
   low (1 per RTT without loss, lower with loss). However, as the
   provisional responses are used to signal changes in phone call
   states, which generally occur on timescales on the order of hundreds
   of milliseconds to seconds, such a limited throughput appears
   acceptable. The mechanism can be extended to support larger window
   sizes, if necessary.

4 Header Fields

   Two new header fields are defined,  RSeq and RAck. The BNF for these
   are:



        RSeq    =    "RSeq" ":" 1*DIGIT
        RAck    =    "RAck" ":" 1*DIGIT


   RSeq is a response header field. It is mandatory when used with this
   extension.  RAck is a request header field. It is mandatory when used
   with this extension.

   The use of reliable provisional responses is signaled by the UAC to
   the UAS through the  Requires header field. This document specifies
   the named extension org.ietf.sip.reliable-100 requests which require
   reliable 100's must include this name in the Requires header field
   and in the  Proxy-Require header field, as proxies need to
   participate.

5 Operation with Proxies

   A SIP request may pass through any number of proxies, some of which
   may fork the request. Furthermore, the SIP specification allows
   proxies to pass back provisional responses (except for the 100
   response) upstream at the discretion of the administrator. If
   reliability of provisional responses were done end-to-end only, an
   intermediate proxy which discards provisional responses by default
   would interfere with the reliability. As such, all intermediate
   proxies must be aware of the use of the mechanism, and participate.

   As a result, reliability of provisional responses is done hop-by-hop,
   similar to the way non-200-class final responses are handled in
   normal SIP operation. Stateless proxies can simply forward all
   provisional responses upstream, ignoring the reliability
   requirements. A stateful proxy must act as a virtual UAS-UAC in the



J.Rosenberg,H.Schulzrinne                                     [Page 3]


Internet Draft              100 Reliability            November 18, 1998


   algorithm described in the previous section. Once a provisional
   response has been received reliably at a proxy, the proxy can
   reliably transmit it upstream towards the next stateful proxy, or may
   discard it.

   Since a proxy may be receiving reliable provisional responses from
   several branches of a forked request, it will need to merge the
   provisional response streams together. There are no requirements
   about the ordering of provisional responses across branches. However,
   all provisional responses from a given branch must be transmitted
   reliably upstream in the same order they were received along a
   branch. For example, consider a forking proxy A which sends a request
   to UAS's B and C. B sends provisional response 0 towards A, and once
   it has been received, sends response 1. Similarly, B sends
   provisional response 2, and once received and acknowledged by A,
   sends provisional response 3. Proxy A may forward the provisional
   responses towards the UAS in any one of the following orders:



   0,1,2,3
   0,2,1,3
   2,3,0,1
   2,0,3,1
   0,2,3,1
   2,0,1,3




   Since responses from several branches may be merged at a forking
   proxy, a proxy may need to renumber the provisional responses (always
   starting at zero, however) when forwarding them upstream. As this
   requires changing the  RSeq value, the  RSeq header field cannot be
   protected by either end-to-end encryption or authentication.
   Similarly, a stateful proxy will need to insert the RAck header field
   itself in all proxied requests.

6 Example

   In this example, a UAC wishes to send an INVITE message and receive
   reliable 100-class responses. Such an INVITE might look like:


   C->S: INVITE 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



J.Rosenberg,H.Schulzrinne                                     [Page 4]


Internet Draft              100 Reliability            November 18, 1998


         Call-ID: 70710@saturn.bell-tel.com
         CSeq: 1 INVITE
         Subject: Come here Watson
         Require: org.ietf.sip.reliable-100
         Proxy-Require: org.ietf.sip.reliable-100



   The server wishes to send a 180 Ringing provisional response
   reliably. The response will look like:


   S->C: SIP/2.0 180 Ringing
         Via: SIP/2.0/UDP saturn.bell-tel.com
         RSeq: 0
         From: sip:alexander@bell-tel.com
         To: sip:watson@bell-tel.com
         Call-ID: 70710@saturn.bell-tel.com
         CSeq: 1 INVITE



   This response is retransmitted with an exponential backoff. When the
   UAC receives the response, it retransmits the request, but adds the
   RAck header field:


   C->S: INVITE sip:watson@bell-tel.com SIP/2.0
         RAck: 0
         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
         Subject: Come here Watson
         Require: org.ietf.sip.reliable-100
         Proxy-Require: org.ietf.sip.reliable-100



7 Open Issues

   There are a number of open issues:

        1.   It is possible to use a list of sequence numbers in the
             RAck header field instead of a single number. This would
             enable a SACK-like mechanism very easily. Is this worth the
             additional complication?



J.Rosenberg,H.Schulzrinne                                     [Page 5]


Internet Draft              100 Reliability            November 18, 1998


        2.   Should we support window sizes greater than one?

        3.   Currently, SIP requests with the same values of the  To,
             From,  Call-ID and  CSeq fields are isomorphic. It is
             possible that certain implementations may discard non-
             isomorphic requests with identical values for these header
             fields. By adding the  RAck header into a request
             retransmission, we break the isomorphism of retransmitted
             requests. Is this a problem?

8 Security Considerations

   Since the  RSeq value cannot be encrypted or authenticated end-to-
   end, nor can the  RAck, man in the middle attacks are possible which
   can cause the provisional responses to be reordered at the UAC. This
   can be alleviated by the use of hop-by-hop encryption and
   authentication mechanisms, such as IPSEC [2,2].

9 Author's Addresses


   Jonathan Rosenberg
   Lucent Technologies, Bell Laboratories
   101 Crawfords Corner Rd.
   Holmdel, NJ 07733
   Rm. 4C-526
   email: jdrosen@bell-labs.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," Internet Draft, Internet Engineering
   Task Force, Sept. 1998.  Work in progress.

   [2] R. Atkinson, "IP encapsulating security payload (ESP)," Request
   for Comments (Proposed Standard) 1827, Internet Engineering Task
   Force, Aug.  1995.




J.Rosenberg,H.Schulzrinne                                     [Page 6]


Internet Draft              100 Reliability            November 18, 1998





















































J.Rosenberg,H.Schulzrinne                                     [Page 7]


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