Internet Engineering Task Force                                    SIP WG
Internet Draft                    Jonathan Rosenberg, Henning Schulzrinne
draft-rosenberg-sip-sctp-00.txt                  dynamicsoft, Columbia U.
June 23, 2000
Expires: December, 2000

                      SCTP as a Transport for SIP


   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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at


   This document specifies a mechanism for usage of SCTP (the Stream
   Control Transmisson Protocol) as the transport between SIP entities.
   SCTP is a new protocol which provides several features that may prove
   beneficial for transport between SIP entities which exchange a large
   amount of messages, including gateways and proxies. As SIP is
   transport independent, support of SCTP is a relatively
   straightforward process, nearly identical to support for TCP.

1 Introduction

   The Stream Control Transmission Protocol (SCTP) [1] has been designed
   as a new transport protocol for the Internet (or intranets), at the
   same layer as TCP and UDP. SCTP has been designed with the transport
   of legacy SS7 signaling messages in mind. We have observed that many

Jonathan Rosenberg, Henning Schulzrinne                       [Page 1]

Internet Draft               SIP over SCTP                 June 23, 2000

   of the features designed to support transport of such signaling are
   also useful for the transport of SIP (the Session Initiation
   Protocol) [2], which is used to initiate and manage interactive
   sessions on the Internet.

   SIP itself is transport-independent, and can run over any reliable or
   unreliable message or stream transport. However, procedures are only
   defined for transport over UDP and TCP. In order to encourage
   experimentation and evaluation of the appropriateness of SCTP for SIP
   transport, this document defines transport of SIP over SCTP. The
   primary aspect of this problem is determination that both sending
   entity and receiving entity support SCTP. This document defines new
   SRV procedures for such discovery.

   Note that this is not a proposal that SCTP be adopted as the primary
   or preferred transport for SIP; substantial evaluation of SCTP,
   deployment, and experimentation can take place before that happens.
   This draft is targeted at encouraging such experimentation by
   enabling it in SIP.

2 Potential Benefits

   Coene et. al. present some of the key benefits of SCTP [3]. We
   summarize some these benefits here:

        Multihoming: An SCTP connection can be associated with multiple
             IP addresses on the same host. Data is always sent over one
             of the addresses, but should it become unreachable, data
             sent to one can migrate to a different address. This
             improves fault tolerance; network failures making one
             interface of the server unavailable do not prevent the
             service from continuing to operate. SIP servers are likely
             to have substantial fault tolerance requirements. It is
             worth noting that because SIP is message-oriented, and not
             stream oriented, the existing SRV procedures defined in [2]
             can accomplish the same goal, even when SIP is run over
             TCP. In fact, SRV records allow the "connection" to fail
             over to a separate host. Since SIP proxies can run
             statelessly, failover can be accomplished without data
             synchronization between the primary and its backups. Thus,
             the multihoming capabilities of SCTP provide marginal

        Fast Retransmit: SCTP can quickly determine the loss of a
             packet, as a result of its usage of SACK and a mechanism
             which sends SACK messages faster than normal when losses
             are detected. The result is that losses of SIP messages can

Jonathan Rosenberg, Henning Schulzrinne                       [Page 2]

Internet Draft               SIP over SCTP                 June 23, 2000

             be detected much faster than when SIP is run over UDP
             (detection will take at least 500ms, if not more) or TCP
             (note that TCP SACK does exist as well, and TCP also has a
             fast retransmit option; it is yet to be determined how much
             faster SCTP's mechanism is compared to TCP). Over an
             existing connection, this results in faster call setup
             times under conditions of packet loss, which is very
             desirable. This is probably the most significant advantage
             to SCTP for SIP transport.

        Streams: Within a connection, SCTP can support multiple streams.
             Transmitted data can be associated with a particular
             stream. Ordering can be guaranteed within a stream, but is
             not enforced across streams. This avoids the head of line
             blocking problem in TCP, which occurs when multiple higher
             layer connections are multiplexed within a single TCP
             connection. A SIP transaction can be considered an
             application layer connection. Between proxies there are
             multiple transactions running. The loss of a message in one
             transaction should not adversely effect the ability of a
             different transaction to send a message. Thus, if SIP is
             run between entities with many transactions occuring in
             parallel, SCTP can provide improved performance over SIP
             over TCP (but not SIP over UDP; but SIP over UDP is not
             ideal from a congestion control standpoint, see below).

        Congestion Control: SCTP maintains congestion control over the
             entire connection. For SIP, this means that the aggregate
             rate of messages between two entities can be controlled.
             When SIP is run over TCP, the same advantages are afforded.
             However, when run over UDP, SIP provides less effective
             congestion control. That is because congestion state
             (measured in terms of the UDP retransmit interval) is
             computed on a transcation by transaction basis, rather than
             across all transactions. Congestion control performance is
             thus similar to opening N parallel TCP connections, as
             opposed to sending N messages over 1 TCP connection.

   It is important to note that most of the benefits of SCTP for SIP
   occur under loss conditions. Therefore, under a zero loss condition,
   SCTP transport of SIP should perform on par with TCP transport.
   Research is needed to evaluate under what loss conditions the
   improvements in setup times and throughput will be observed. The
   purpose of this draft is to enable such experimentation in order to
   provide concrete data on its applicability to SIP.

Jonathan Rosenberg, Henning Schulzrinne                       [Page 3]

Internet Draft               SIP over SCTP                 June 23, 2000

3 Usage of SCTP

   Usage of SCTP requires no additional headers or syntax in SIP.

        The only possibility would be the addition of a transport
        token with value sctp in the SIP URL. But, this isn't
        required for operation.

   Rules for sending a request over SCTP are exactly identical to TCP.

   The primary issue is, when sending a request, determining whether the
   next hop server supports SCTP, so that a connection can be opened. If
   a connection is already opened, the issue is selection of a stream.
   This draft assumes that SRV records are the primary vehicle for such
   determinations. The text below on usage of SRV records replaces the
   text in Appendix D of RFC2543 [2].

   When an entity (UAC or proxy) wishes to send a request to a
   particular URI, the following process is followed. The process
   consists of a number of steps. If a step elicits no addresses, the
   client continues to the next step. However if a step elicits one or
   more addresses, but no SIP server at any of those addresses responds,
   then the entity concludes the server is down and doesn't continue on
   to the next step.

   When SRV records are to be used, the protocol to use when querying
   for the SRV record is "sip". SRV records contain port numbers for
   servers, in addition to IP addresses; the entity always uses this
   port number when contacting the SIP server. Otherwise, the port
   number in the SIP URI is used, if present. If there is no port number
   in the URI, the default port, 5060, is used.

        1.   If the host portion of the Request-URI is an IP address,
             the entity contacts the server at the given address. If the
             host portion of the Request-URI is not an IP address, the
             entity proceeds to the next step.

        2.   The Request-URI is examined. If it contains an explicit
             port number, the next two steps are skipped.

        3.   The Request-URI is examined. If it does not specify a
             protocol (TCP or UDP), the entity queries the name server
             for SRV records for both UDP (if supported by the entity)
             and TCP (if supported by the entity) and SCTP (if supported
             by the entity) SIP servers. The format of these queries is

Jonathan Rosenberg, Henning Schulzrinne                       [Page 4]

Internet Draft               SIP over SCTP                 June 23, 2000

             defined in RFC 2782 [4]. The results of the query or
             queries are merged together and ordered based on priority.
             Then, the searching technique outlined in RFC 2782 [4] is
             used to select servers in order. If DNS doesn't return any
             records, the entity goes to the last step. Otherwise, the
             entity attempts to contact each server in the order listed.
             If no server is contacted, the entity gives up.

        4.   If the Request-URI specifies a protocol (TCP or UDP) that
             is supported by the entity, the entity queries the name
             server for SRV records for SIP servers of that protocol
             type only. If the entity does not support the protocol
             specified in the Request-URI, it gives up. The searching
             technique outlined in RFC 2782 [4] is used to select
             servers from the DNS response in order. If DNS doesn't
             return any records, the entity goes to the last step.
             Otherwise, the entity attempts to contact each server in
             the order listed. If no server is contacted, the entity
             gives up.

        5.   The entity queries the name server for address records for
             the host portion of the Request-URI. If there were no
             address records, the entity stops, as it has been unable to
             locate a server. By address record, we mean A RR's, AAAA
             RR's, or their most modern equivalent.

   In the process abvoe, the step of "contacting" the server consists of
   the following steps:

        1.   If the transport is UDP, simply send a request to the
             specific IP address and port.

        2.   If the transport is TCP, the entity SHOULD look for
             existing open connections to the given IP address and port,
             and then send the request over this connection if one is
             found. Otherwise, a new TCP connection is opened, and the
             request sent over it.

        3.   If the transport is SCTP, the entity SHOULD look for
             exising open SCTP connections to the given IP address and
             port. The number of streams within the connection, and the
             mapping of SIP requests to streams, are at the discretion
             of the entity. However, it is RECOMMENDED that some kind of
             stateless hash be used so that requests for the same call
             all be mapped into the same stream. If no SCTP connection
             is established, one is opened and the request sent over it.

Jonathan Rosenberg, Henning Schulzrinne                       [Page 5]

Internet Draft               SIP over SCTP                 June 23, 2000

   TCP and SCTP connections that were opened by proxies as the result of
   a successful SRV query SHOULD remain open after the transaction
   completes. The amount of time after completion of a transaction,
   before which the connection is closed, is configurable.

        The rule here for SRV provides a neat way to differentiate
        among connections between proxies, and between proxies and
        UAs and UAs and proxies. You really only want and need long
        lived connections between proxies. Its very likely that
        only proxies have SRV record entries.

   A entity MAY cache a successful DNS query result. A successful query
   is one which contained records in the answer, and a server was
   contacted at one of the addresses from the answer. When the entity
   wishes to send a request to the same host, it starts the search as if
   it had just received this answer from the name server. The server
   uses the procedures specified in RFC1035 [15] regarding cache
   invalidation when the time-to-live of the DNS result expires. If the
   entity does not find a SIP server among the addresses listed in the
   cached answer, it starts the search at the beginning of the sequence
   described above.

4 Conclusion

   This draft has presented a discussion on the applicability of SCTP to
   SIP transport, and provided an experimental mechanism for allowing
   two SCTP-capable entities to establish and use an SCTP connection.

5 Author's Addresses

   Jonathan Rosenberg
   200 Executive Drive
   Suite 120
   West Orange, NJ 07052

   Henning Schulzrinne
   Columbia University
   M/S 0401
   1214 Amsterdam Ave.
   New York, NY 10027-7003

Jonathan Rosenberg, Henning Schulzrinne                       [Page 6]

Internet Draft               SIP over SCTP                 June 23, 2000

6 Bibliography

   [1] R. Stewart et al.  , "Simple control transmission protocol,"
   Internet Draft, Internet Engineering Task Force, Apr. 2000.  Work in

   [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
   session initiation protocol," Request for Comments 2543, Internet
   Engineering Task Force, Mar. 1999.

   [3] L. Coene, J. Loughney, I. Rytina, and L. Ong, "Simple control
   transmission Protocol(SCTP) applicability statement," Internet Draft,
   Internet Engineering Task Force, Mar. 2000.  Work in progress.

   [4] A. Gulbrandsen, P. Vixie, and L. Esibov, "A DNS RR for specifying
   the location of services (DNS SRV)," Request for Comments 2782,
   Internet Engineering Task Force, Feb. 2000.

Jonathan Rosenberg, Henning Schulzrinne                       [Page 7]