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]