Internet Engineering Task Force                                   SIP WG
Internet Draft                           Rosenberg/Schulzrinne/Camarillo
draft-ietf-sip-sctp-01.txt              dynamicsoft,Columbia U.,Ericsson
August 14,
November 20, 2001
Expires: February, May, 2002

                      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

   To view the list Internet-Draft Shadow Directories, see


   This document specifies a mechanism for usage of SCTP (the Stream
   Control Transmission 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
   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.

   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 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119.

3 Potential Benefits

   Coene et. al. present some of the key benefits of SCTP [3]. We
   summarize some of these benefits here and analyze how they relate to

3.1 Advantages over UDP

   All the advantages that SCTP has over UDP regarding SIP transport are
   also shared by TCP. Below there is a list of the general advantages
   that a connection-oriented transport protocol such as TCP or SCTP has
   over a connection-less transport protocol such as UDP.

        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
             be detected much faster than when SIP is run over UDP
             (detection will take at least 500ms, if not more). Note
             that TCP SACK does exist as well, and TCP also has a fast
             retransmit option. 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.

        Congestion Control: SCTP maintains congestion control over the
             entire connection. association. 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 transaction 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.

        Transport layer fragmentation: SCTP and TCP provide transport
             layer fragmentation. If a SIP message is larger than the
             MTU size it is fragmented at the transport layer. When UDP
             is used fragmentation occurs at the IP layer. IP
             fragmentation increases the likelihood of having packet
             losses and make it difficult (when not impossible) NAT and
             firewall traversal. This feature will become important if
             the size of SIP messages grows dramatically.

3.2 Advantages over TCP

   We have shown the advantages of SCTP and TCP over UDP. We now analyze
   the advantages of SCTP over TCP.

        Head of the Line: SCTP is message based as opposed to TCP that
             is stream based. This allows SCTP to separate different
             signalling messages at the transport layer. TCP just
             understands bytes. Assembling received bytes to form
             signalling messages is performed at the application layer.
             Therefore, TCP always delivers an ordered stream of bytes
             to the application. On the other hand, SCTP can deliver
             signalling messages to the application as soon as they
             arrive (when using the unordered service). The loss of a
             signalling message does not affect the delivery of the rest
             of the messages. 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 occurring 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 above).

        Easier Parsing: Another advantage of message based protocols
             such as SCTP and UDP over stream based protocols such as
             TCP is that they allow easier parsing of messages at the
             application layer. There is not need of establishing
             boundaries (typically using Content-Length headers) between
             different messages. However, this advantage is almost

        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

   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.

4 Usage of SCTP

   Usage of SCTP requires no additional headers or syntax in SIP. Below
   we show an example of a SIP URL with a transport parameter and an
   example of a via header. In both examples SCTP is the transport

        Via: SIP/2.0/SCTP

   Rules for sending a request over SCTP are identical to TCP. The only
   difference is that an SCTP sender has to choose a particular stream
   within an association in order to send the request.

   It is important noting that a receiver uses SIP headers such as
   Call-ID to demultiplex requests (or responses) that belong to
   different transactions and are received over the same STCP
   association. The stream id MUST NOT be used for this purpose.

        This way a receiver is not affected by the way a particular
        sender maps transactions into streams. The receiver will
        always be able to properly demultiplex incoming SIP traffic
        without knowing the mapping policy of the sender.

   Note that no SCTP identifier needs to be defined for SIP messages.
   Therefore, the Payload Protocol Indentifier in SCTP DATA chunks
   transporting SIP messages MUST be set to zero.

4.1 Mapping of transactions into streams

   The more efficient mapping of transactions into streams consists SIP transport layers of
   sending requests belonging both peers are responsible to manage the same call over
   persistent SCTP connection between them. On the same ordered
   stream. Requests belonging sender side the core
   or a client (or server) transaction generates a request (or response)
   and passes it to different calls will be mapped into
   different streams. It the transport layer. The transport sends the request
   to the peer's transaction layer. The peer's transaction layer is RECOMMENDED that some kind
   responsible of stateless hash
   be used so that requests for delivering the same call all be mapped into incoming request (or response) to the
   same stream.

        Note that if
   proper existing server (or client) transaction. If no server (or
   client) transaction exists for the number of calls handled by incoming message the SIP entity
        is larger than transport
   layer passes the number of available streams some calls
        would have request (or response) to share the same stream. This would result in the head core, which may decide
   to construct a new server (or client) transaction.

   The mapping of SIP transactions into SCTP stream IDs serves two

        1.   Avoid Head Of the line Line (HOL) blocking problem described previously.

   Responses are mapped in

        2.   Provide a lightweight mechanism to perform transaction
             identification. This allows an efficient delivery of
             incoming SIP messages from the same way - responses that belong SIP transport layer to the
   same call are sent over
             client or server transaction the same ordered stream. However, final
   responses should be transmitted with message belongs to.

   The former is REQUIRED whereas the unordered flag set. latter is RECOMMENDED. This
   prevents lost provisional responses from delaying
   document describes how to achieve both goals.

        We believe that using stream IDs to demultiplex incoming
        traffic is a useful mechanism to implement highly efficient
        SIP proxies and gateways. However, we too believe that it
        is essential that a SIP entity that is not stream ID aware
        can interoperate with any other implementation. That is why
        this feature is optional, and so, the second bullet is

4.1 Mapping of SIP Transactions into Streams

   A SIP entity needs to relate incoming SIP messages to existing client
   and server transactions. On the client side incoming responses need
   to be delivered to the client transaction that generated the request.
   On the server side:

        1.   ACKs for non-2xx final responses need to be delivered to
             the INVITE server transaction that generated the response.

        2.   The core needs to relate incoming CANCEL requests to
             existing server transactions.

   Note that retransmissions of a request are never received over a
   reliable transport such as SCTP.

   In order to match a particular SIP message with an existing client or
   server transaction it is necessary to compute the transaction
   identifier of the message. The transaction identifier consists of the
   To, From, Call-ID, Cseq and topmost Via header fields. The use of
   SCTP stream IDs as lightweight transaction identifiers saves parsing
   these headers every time a new SIP message arrives.

   If a SIP entity chooses not to use SCTP stream IDs as lightweight
   transaction identifiers it MUST send every request and every response
   it generates using the SCTP stream ID zero with the "unordered" flag

   A SIP entity that decides to use stream IDs to identify particular
   transactions MUST follow the rules described below (Sections 4.1.1
   and 4.1.2).

4.1.1 Client Side

   The decision of whether or not to use the SCTP stream ID to
   demultiplex incoming traffic is made on a transaction basis by the
   client's transport layer. If the transaction layer intends to perform
   SIP traffic demultiplexing based on stream IDs for the current
   transaction it MUST follow the rules below. If the transaction layer
   does not intend to use stream IDs for that purpose for this
   particular transaction it MUST send the request using the SCTP stream
   ID zero with the "unordered" flag set.

   A transport layer receiving a request from the core (as opposed to
   from a client transaction layer) MUST send the request using the SCTP
   stream ID zero with the "unordered" flag set.

   A transport layer performing demultiplexing based on stream IDs MUST
   use an uneven stream ID to send the any request but CANCEL. CANCEL
   requests MUST be sent over the stream ID that the request to be
   cancelled was sent plus one (e.g., an INVITE over stream 1 and its
   CANCEL over stream 2). This rule implies that the highest stream ID
   (2**16-1) MUST NOT be used to send SIP traffic.

   A transport layer sending a request over a stream ID different than
   zero MUST be able to relate the stream ID used to send the request
   with the client transaction that generated the request. This MAY be
   done by implementing an indexed table that relates stream IDs with
   client transactions. Responses arriving over this particular stream
   ID MUST be delivered to the client transaction that generated the

   Requests sent over a stream different than zero MUST NOT have the
   "unordered" flag set.

   A particular stream ID different than zero MUST NOT be used by more
   than one client transaction at a time. Note, however, that a
   particular stream ID MAY be used at the same time by a client
   transaction and by a server transaction.

        The transaction layer is able to distinguish requests from
        responses and thus it is able to decide whether to deliver
        the incoming SIP message to the client or to the server

   Effectively, a particular stream ID can be reused by a new client
   transaction once the client transaction currently related to it
   terminates. If an indexed table is used, the entry corresponding to
   this transaction is removed at this point of time.

   ACKs are a special case. ACK requests for non-2xx responses to an
   INVITE are generated by the client transaction. They MUST be sent
   over the same stream ID as the INVITE was sent. ACK requests for 2xx
   responses for the INVITE are generated by the Transaction User. As
   previously stated, every request generated by the core is sent over
   stream ID zero with the "unordered" flag set.

4.1.2 Server Side

   The decision of whether or not to use the SCTP stream ID to
   demultiplex incoming traffic is made on a transaction basis by the
   server's transport layer. If the transaction layer intends to perform
   SIP traffic demultiplexing based on stream IDs for the current
   transaction it MUST follow the rules below. If the transaction layer
   does not intend to use stream IDs for that purpose for this
   particular transaction it MUST send all responses it generates for
   this transaction over stream zero with the "unordered" flag set.

   If a transport layer chooses to demultiplex traffic based on stream
   IDs it MUST be able to relate stream IDs with server transactions.
   This MAY be implemented using an indexed table. When a new request
   arrives over a stream different than zero, if the stream ID is
   related to an existing server transaction the request MUST be passed
   to that server transaction. If the stream ID is not related to any
   server transaction the request is passed to the core. The SIP
   transport layer MUST inform the core about the stream ID the request
   was received over. If the core decides to create a server transaction
   for the request, it MUST inform the transport layer about the server
   transaction that corresponds to that particular stream ID.

        If an indexed table is used an entry relating the stream ID
        with the newly created server transaction is added.

   When a server transaction passes a response to the SIP transport
   layer this response MUST be sent over the stream ID corresponding to
   this transaction. Responses passed to the transport layer directly
   from the core (no server transaction involved) MUST be sent over
   stream ID zero.

   Once a server transaction terminates the delivery of
   final responses.

   Some implementors might think that bundling between this way of mapping transactions
   into streams sever
   transaction and the stream ID is somehow complicated. It terminated as well.

        If case an indexed table is possible to perform implemented, the entry for this
   mapping in a much simpler way. Senders can take advantage
        server transaction is removed.

   Regardless of the
   ordering of requests that SIP performs at stream ID used, the application layer. That
   is, SIP does not transport layer MUST send a new request until
   every response with the last transaction has
   completed (or at least until "unordered" flag set.

        This avoids that a SIP loss in a provisional response has arrived from affects
   remote side). Therefore, all requests and responses can be sent with delivery of a final response within a particular

4.1.3 Size of the unordered flag set over any stream. Effectively, stream ID space

   The SCTP stream identifier is a single 16-bit field. Since stream
   can zero and
   stream 2**16-1 cannot be used for all SIP traffic. This way of performing the mapping
   is almost as effective as the one described previously and it has the
   advantage of being simpler.

        The scenarios where this transaction identifiers there are
   2**15-1 = 32767 available stream IDs. A SIP proxy handling 333
   requests per second way (1.2 million Busy Hour Call attempts) would only
   run out of performing the
        mapping might result in reordering stream IDs if it only handled INVITE transactions and if
   every transaction lasted more than 98 seconds (INVITE transactions
   typically last much less than that). Non-INVITE transactions
   typically last less than INVITE transactions (16 seconds maximum
   using default timers), so a proxy can handle a larger number of requests/responses
        represent corner cases non-
   INVITE transactions.

   This calculations show that do not justify the increase in the complexity stream ID space is large enough even
   for proxies handling heavy traffic loads. And even if a proxy did
   eventually run out of the first solution.

   It stream IDs, stream zero is RECOMMENDED to use always available for
   the second approach because it combines
   simplicity and efficiency. excess of traffic.

5 Locating a SIP server

   The primary issue when sending a request is determining whether the
   next hop server supports SCTP, so that an association can be opened.
   This draft assumes that SRV records are the primary vehicle for such
   determinations. RFC2543bis [4] describes the process that an entity
   (UAC or proxy) that wishes to send a request to a particular URI MUST

   The format of the SRV RR as described in [5] is shown below:

        _Service._Proto.Name TTL Class Priority weight Port Target

   When SRV records are to be used, the service to use when querying for
   the SRV record is "sip" and the transport protocol is "sctp". So, a
   SIP client that wants to discover a SIP server that supports SCTP for
   the domain does a lookup of

   SCTP associations 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. It is very likely that
        only proxies have SRV record entries.

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

7 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

   Gonzalo Camarillo
   Advanced Signalling Research Lab.

   FIN-02420 Jorvas
   Phone: +358 9 299 3371
   Fax: +358 9 299 3052

8 Bibliography

   [1] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, T.
   Taylor, I. Rytina, M. Kalla, L. Zhang, and V. Paxson, "Stream control
   transmission protocol," Request for Comments 2960, Internet
   Engineering Task Force, Oct.  2000.

   [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 et al.  , "Stream control transmission protocol
   applicability statement," Internet Draft, Internet Engineering Task
   Force, Apr. 2001.  Work in progress.

   [4] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, H. Schulzrinne, et al.  , "SIP: Session initiation
   protocol," Internet Draft, Internet Engineering Task Force, Nov. 2000. Oct.
   2001.  Work in progress.

   [5] 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.

                           Table of Contents

   1          Introduction ........................................    1
   2          Terminology .........................................    2
   3          Potential Benefits ..................................    2
   3.1        Advantages over UDP .................................    2
   3.2        Advantages over TCP .................................    3
   4          Usage of SCTP .......................................    4
   4.1        Mapping of transactions SIP Transactions into streams ................ Streams ............    5
   4.1.1      Client Side .........................................    6
   4.1.2      Server Side .........................................    7
   4.1.3      Size of the stream ID space .........................    8
   5          Locating a SIP server ...............................    6    8
   6          Conclusion ..........................................    6    9
   7          Author's Addresses ..................................    6    9
   8          Bibliography ........................................    7   10