draft-ietf-sip-sctp-06.txt   rfc4168.txt 
SIP J. Rosenberg Network Working Group J. Rosenberg
Internet-Draft Cisco Systems Request for Comments: 4168 Cisco Systems
Expires: July 14, 2005 H. Schulzrinne Category: Standards Track H. Schulzrinne
Columbia University Columbia University
G. Camarillo G. Camarillo
Ericsson Ericsson
January 13, 2005 October 2005
The Stream Control Transmission Protocol (SCTP) as a Transport for
the Session Initiation Protocol (SIP)
draft-ietf-sip-sctp-06.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 The Stream Control Transmission Protocol (SCTP)
http://www.ietf.org/ietf/1id-abstracts.txt. as a Transport for the Session Initiation Protocol (SIP)
The list of Internet-Draft Shadow Directories can be accessed at Status of This Memo
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 14, 2005. This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document specifies a mechanism for usage of SCTP (the Stream This document specifies a mechanism for usage of SCTP (the Stream
Control Transmission Protocol) as the transport between SIP (Session Control Transmission Protocol) as the transport mechanism between SIP
Initiation Protocol) entities. SCTP is a new protocol which provides (Session Initiation Protocol) entities. SCTP is a new protocol that
several features that may prove beneficial for transport between SIP provides several features that may prove beneficial for transport
entities which exchange a large amount of messages, including between SIP entities that exchange a large amount of messages,
gateways and proxies. As SIP is transport independent, support of including gateways and proxies. As SIP is transport-independent,
SCTP is a relatively straightforward process, nearly identical to support of SCTP is a relatively straightforward process, nearly
support for TCP. identical to support for TCP.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology .....................................................2
3. Potential Benefits . . . . . . . . . . . . . . . . . . . . . . 3 3. Potential Benefits ..............................................2
3.1 Advantages over UDP . . . . . . . . . . . . . . . . . . . 3 3.1. Advantages over UDP ........................................3
3.2 Advantages over TCP . . . . . . . . . . . . . . . . . . . 4 3.2. Advantages over TCP ........................................3
4. Transport Parameters . . . . . . . . . . . . . . . . . . . . . 5 4. Transport Parameter .............................................5
5. SCTP Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. SCTP Usage ......................................................5
5.1 Mapping of SIP Transactions into SCTP Streams . . . . . . 7 5.1. Mapping of SIP Transactions into SCTP Streams ..............5
6. Locating a SIP Server . . . . . . . . . . . . . . . . . . . . 8 6. Locating a SIP Server ...........................................6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations .........................................7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations .............................................7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9. References ......................................................7
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References .......................................7
9.2 Informative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References .....................................8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . 11
1. Introduction 1. Introduction
The Stream Control Transmission Protocol (SCTP) [4] has been designed The Stream Control Transmission Protocol (SCTP) [4] has been designed
as a new transport protocol for the Internet (or intranets), at the 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 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 legacy SS7 signaling messages in mind. We have observed that many
of the features designed to support transport of such signaling are of the features designed to support transport of such signaling are
also useful for the transport of SIP (the Session Initiation also useful for the transport of SIP (the Session Initiation
Protocol) [5], which is used to initiate and manage interactive Protocol) [5], which is used to initiate and manage interactive
sessions on the Internet. sessions on the Internet.
SIP itself is transport-independent, and can run over any reliable or SIP itself is transport-independent, and can run over any reliable or
unreliable message or stream transport. However, procedures are only unreliable message or stream transport. However, procedures are only
defined for transport over UDP and TCP. This document defines defined for transport over UDP and TCP. This document defines
transport of SIP over SCTP. transport of SIP over SCTP.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [1].
3. Potential Benefits 3. Potential Benefits
Coene et. al. present some of the key benefits of SCTP [10]. We RFC 3257 presents some of the key benefits of SCTP [10]. We
summarize some of these benefits here and analyze how they relate to summarize some of these benefits here and analyze how they relate to
SIP (a more detailed analysis can be found in [12]). SIP (a more detailed analysis can be found in [12]).
3.1 Advantages over UDP 3.1. Advantages over UDP
All the advantages that SCTP has over UDP regarding SIP transport are 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 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 that a connection-oriented transport protocol such as TCP or SCTP has
over a connection-less transport protocol such as UDP. over a connection-less transport protocol such as UDP.
Fast Retransmit: SCTP can quickly determine the loss of a packet, as Fast Retransmit: SCTP can quickly determine the loss of a packet,
a result of its usage of SACK and a mechanism which sends SACK because of its usage of SACK and a mechanism that sends SACK
messages faster than normal when losses are detected. The result messages faster than normal when losses are detected. The result
is that losses of SIP messages can be detected much faster than is that losses of SIP messages can be detected much faster than
when SIP is run over UDP (detection will take at least 500 ms, if when SIP is run over UDP (detection will take at least 500 ms, if
not more). Note that TCP SACK does exist as well, and TCP also not more). Note that TCP SACK exists as well, and TCP also has a
has a fast retransmit option. Over an existing connection, this fast retransmit option. Over an existing connection, this results
results in faster call setup times under conditions of packet in faster call setup times under conditions of packet loss, which
loss, which is very desirable. This is probably the most is very desirable. This is probably the most significant
significant advantage to SCTP for SIP transport. advantage of SCTP for SIP transport.
Congestion Control: SCTP maintains congestion control over the entire Congestion Control: SCTP maintains congestion control over the entire
association. For SIP, this means that the aggregate rate of association. For SIP, this means that the aggregate rate of
messages between two entities can be controlled. When SIP is run messages between two entities can be controlled. When SIP is run
over TCP, the same advantages are afforded. However, when run over TCP, the same advantages are afforded. However, when run
over UDP, SIP provides less effective congestion control. That is over UDP, SIP provides less effective congestion control. This is
because congestion state (measured in terms of the UDP retransmit because congestion state (measured in terms of the UDP retransmit
interval) is computed on a transaction by transaction basis, interval) is computed on a transaction-by-transaction basis,
rather than across all transactions. Congestion control rather than across all transactions. Thus, congestion control
performance is thus similar to opening N parallel TCP connections, performance is similar to opening N parallel TCP connections, as
as opposed to sending N messages over one TCP connection. opposed to sending N messages over one TCP connection.
Transport-Layer Fragmentation: SCTP and TCP provide transport-layer Transport-Layer Fragmentation: SCTP and TCP provide transport-layer
fragmentation. If a SIP message is larger than the MTU size it is fragmentation. If a SIP message is larger than the MTU size, it
fragmented at the transport layer. When UDP is used fragmentation is fragmented at the transport layer. When UDP is used,
occurs at the IP layer. IP fragmentation increases the likelihood fragmentation occurs at the IP layer. IP fragmentation increases
of having packet losses and makes it difficult (when not the likelihood of having packet losses and makes NAT and firewall
impossible) NAT and firewall traversal. This feature will become traversal difficult, if not impossible. This feature will become
important if the size of SIP messages grows dramatically. important if the size of SIP messages grows dramatically.
3.2 Advantages over TCP 3.2. Advantages over TCP
We have shown the advantages of SCTP and TCP over UDP. We now We have shown the advantages of SCTP and TCP over UDP. We now
analyze the advantages of SCTP over TCP. analyze the advantages of SCTP over TCP.
Head of the Line: SCTP is message based as opposed to TCP which is Head of the Line: SCTP is message-based, as opposed to TCP, which is
stream based. This allows SCTP to separate different signalling stream-based. This allows SCTP to separate different signalling
messages at the transport layer. TCP just understands bytes. messages at the transport layer. TCP only understands bytes.
Assembling received bytes to form signalling messages is performed Assembling received bytes to form signalling messages is performed
at the application layer. Therefore, TCP always delivers an at the application layer. Therefore, TCP always delivers an
ordered stream of bytes to the application. On the other hand, ordered stream of bytes to the application. On the other hand,
SCTP can deliver signalling messages to the application as soon as SCTP can deliver signalling messages to the application as soon as
they arrive (when using the unordered service). The loss of a they arrive (when using the unordered service). The loss of a
signalling message does not affect the delivery of the rest of the signalling message does not affect the delivery of the rest of the
messages. This avoids the head of line blocking problem in TCP, messages. This avoids the head of line blocking problem in TCP,
which occurs when multiple higher layer connections are which occurs when multiple higher layer connections are
multiplexed within a single TCP connection. A SIP transaction can multiplexed within a single TCP connection. A SIP transaction can
be considered an application layer connection. Between proxies be considered an application layer connection. There are multiple
there are multiple transactions running. The loss of a message in transactions running between proxies. The loss of a message in
one transaction should not adversely effect the ability of a one transaction should not adversely effect the ability of a
different transaction to send a message. Thus, if SIP is run different transaction to send a message. Thus, if SIP is run
between entities with many transactions occurring in parallel, between entities with many transactions occurring in parallel,
SCTP can provide improved performance over SIP over TCP (but not SCTP can provide improved performance over SIP over TCP (but not
SIP over UDP; but SIP over UDP is not ideal from a congestion SIP over UDP; SIP over UDP is not ideal from a congestion control
control standpoint, see above). standpoint; see above).
Easier Parsing: Another advantage of message based protocols such as Easier Parsing: Another advantage of message-based protocols, such as
SCTP and UDP over stream based protocols such as TCP is that they SCTP and UDP, over stream-based protocols, such as TCP, is that
allow easier parsing of messages at the application layer. There they allow easier parsing of messages at the application layer.
is not need of establishing boundaries (typically using There is no need to establish boundaries (typically using
Content-Length headers) between different messages. However, this Content-Length headers) between different messages. However, this
advantage is almost negligible. advantage is almost negligible.
Multihoming: An SCTP connection can be associated with multiple IP Multihoming: An SCTP connection can be associated with multiple IP
addresses on the same host. Data is always sent over one of the addresses on the same host. Data is always sent over one of the
addresses, but should it become unreachable, data sent to one can addresses, but if it becomes unreachable, data sent to one can
migrate to a different address. This improves fault tolerance; migrate to a different address. This improves fault tolerance;
network failures making one interface of the server unavailable do network failures making one interface of the server unavailable do
not prevent the service from continuing to operate. SIP servers not prevent the service from continuing to operate. SIP servers
are likely to have substantial fault tolerance requirements. It are likely to have substantial fault tolerance requirements. It
is worth noting that because SIP is message oriented, and not is worth noting that, because SIP is message oriented and not
stream oriented, the existing SRV (Service Selection) procedures stream oriented, the existing SRV (Service Selection) procedures
defined in [5] can accomplish the same goal, even when SIP is run defined in [5] can accomplish the same goal, even when SIP is run
over TCP. In fact, SRV records allow the 'connection' to fail over TCP. In fact, SRV records allow the 'connection' to fail
over to a separate host. Since SIP proxies can run statelessly, over to a separate host. Since SIP proxies can run statelessly,
failover can be accomplished without data synchronization between failover can be accomplished without data synchronization between
the primary and its backups. Thus, the multihoming capabilities the primary and its backups. Thus, the multihoming capabilities
of SCTP provide marginal benefits. of SCTP provide marginal benefits.
It is important to note that most of the benefits of SCTP for SIP It is important to note that most of the benefits of SCTP for SIP
occur under loss conditions. Therefore, under a zero loss condition, occur under loss conditions. Therefore, under a zero loss condition,
SCTP transport of SIP should perform on par with TCP transport. SCTP transport of SIP should perform on par with TCP transport.
Research is needed to evaluate under what loss conditions the Research is needed to evaluate under what loss conditions the
improvements in setup times and throughput will be observed. improvements in setup times and throughput will be observed.
4. Transport Parameters 4. Transport Parameter
A SIP URIs can carry a transport parameter indicating the transport
protocol to be used. RFC 3261 defines the value "sctp" for SCTP but
does not define the value for the transport parameter for TLS over
SCTP. Note that the value "tls", defined by RFC 3261, is intended
for TLS over TCP.
Here we define the value "tls-sctp" for the SIP URI transport
parameter to be used for messages to be sent over TLS over SCTP [8].
The updated augmented BNF (Backus-Naur Form) [2] for this parameter
is the following (the original BNF for this parameter can be found in
RFC 3261):
transport-param = "transport="
( "udp" / "tcp" / "sctp" / "tls" / "tls-sctp"
/ other-transport)
The following are examples of SIP URIs using "sctp" and "tls-sctp" in
their transport parameters:
sip:Bob.Johnson@example.com;transport=sctp
sip:Bob.Johnson@example.com;transport=tls-sctp
Via header fields also carry a transport protocol identifier. RFC Via header fields carry a transport protocol identifier. RFC 3261
3261 defines the value "SCTP" for SCTP but does not define the value defines the value "SCTP" for SCTP, but does not define the value for
for the transport parameter for TLS over SCTP. Note that the value the transport parameter for TLS over SCTP. Note that the value
"TLS", defined by RFC 3261, is intended for TLS over TCP. "TLS", defined by RFC 3261, is intended for TLS over TCP.
Here we define the value "TLS-SCTP" for the transport part of the Via Here we define the value "TLS-SCTP" for the transport part of the Via
header field to be used for requests sent over TLS over SCTP [8]. header field to be used for requests sent over TLS over SCTP [8].
The updated augmented BNF (Backus-Naur Form) [2] for this parameter The updated augmented BNF (Backus-Naur Form) [2] for this parameter
is the following (the original BNF for this parameter can be found in is the following (the original BNF for this parameter can be found in
RFC 3261): RFC 3261):
transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP"
/ other-transport / other-transport
skipping to change at page 6, line 37 skipping to change at page 5, line 34
Via: SIP/2.0/SCTP ws1234.example.com:5060 Via: SIP/2.0/SCTP ws1234.example.com:5060
Via: SIP/2.0/TLS-SCTP ws1234.example.com:5060 Via: SIP/2.0/TLS-SCTP ws1234.example.com:5060
5. SCTP Usage 5. SCTP Usage
Rules for sending a request over SCTP are identical to TCP. The only 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 difference is that an SCTP sender has to choose a particular stream
within an association in order to send the request (see Section 5.1). within an association in order to send the request (see Section 5.1).
Note that no SCTP identifier needs to be defined for SIP messages. Note that no SCTP identifier needs to be defined for SIP messages.
Therefore, the Payload Protocol Indentifier in SCTP DATA chunks Therefore, the Payload Protocol Identifier in SCTP DATA chunks
transporting SIP messages MUST be set to zero. transporting SIP messages MUST be set to zero.
The SIP transport layers of both peers are responsible for managing The SIP transport layers of both peers are responsible for managing
the persistent SCTP connection between them. On the sender side the the persistent SCTP connection between them. On the sender side, the
core or a client (or server) transaction generates a request (or core or a client (or server) transaction generates a request (or
response) and passes it to the transport layer. The transport sends response) and passes it to the transport layer. The transport sends
the request to the peer's transaction layer. The peer's transaction the request to the peer's transaction layer. The peer's transaction
layer is responsible for delivering the incoming request (or layer is responsible for delivering the incoming request (or
response) to the proper existing server (or client) transaction. If response) to the proper existing server (or client) transaction. If
no server (or client) transaction exists for the incoming message the no server (or client) transaction exists for the incoming message,
transport layer passes the request (or response) to the core, which the transport layer passes the request (or response) to the core,
may decide to construct a new server (or client) transaction. which may decide to construct a new server (or client) transaction.
5.1 Mapping of SIP Transactions into SCTP Streams 5.1. Mapping of SIP Transactions into SCTP Streams
SIP transactions need to be mapped into SCTP streams in a way that SIP transactions need to be mapped into SCTP streams in a way that
avoids Head Of the Line (HOL) blocking. Among all the different ways avoids Head Of the Line (HOL) blocking. Among the different ways of
of performing this mapping that fulfil this requirement, we have performing this mapping that fulfill this requirement, we have chosen
chosen the simplest one; a SIP entity SHOULD send every SIP message the simplest one; a SIP entity SHOULD send every SIP message (request
(request or response) over stream zero with the unordered flag set. or response) over stream zero with the unordered flag set. On the
On the receiving side, a SIP entity MUST be ready to receive SIP receiving side, a SIP entity MUST be ready to receive SIP messages
messages over any stream. over any stream.
In the past, it was proposed to use SCTP stream IDs as lightweight In the past, it was proposed that SCTP stream IDs be used as
SIP transaction identifiers. That proposal was withdrawn because lightweight SIP transaction identifiers. That proposal was
SIP now provides (as defined in RFC 3261 [5]) a transaction withdrawn because SIP now provides (as defined in RFC 3261 [5]) a
identifier in the branch parameter of the Via entries. This transaction identifier in the branch parameter of the Via entries.
transaction identifier, missing in the previous SIP spec [9], This transaction identifier, missing in the previous SIP spec [9],
makes it unnecessary to use the SCTP stream IDs to demultiplex SIP makes it unnecessary to use the SCTP stream IDs to demultiplex SIP
traffic. traffic.
SIP has many circumstances in which the use of TLS [3] is required, In many circumstances, SIP requires the use of TLS [3], for instance,
for instance, for routing a SIPS URI [5]. As defined in RFC 3436 when routing a SIPS URI [5]. As defined in RFC 3436 [8], TLS running
[8], TLS running over SCTP MUST NOT use the SCTP unordered delivery over SCTP MUST NOT use the SCTP unordered delivery service.
service. Moreover, any SIP use of an extra layer between the Moreover, any SIP use of an extra layer between the transport layer
transport layer and SIP that requires ordered delivery of messages and SIP that requires ordered delivery of messages MUST NOT use the
MUST NOT use the SCTP unordered delivery service. SCTP unordered delivery service.
SIP applications that require ordered delivery of messages from the SIP applications that require ordered delivery of messages from the
transport layer (e.g., TLS) SHOULD send SIP messages belonging to the transport layer (e.g., TLS) SHOULD send SIP messages belonging to the
same SIP transaction over the same SCTP stream. Additionally, they same SIP transaction over the same SCTP stream. Additionally, they
SHOULD send messages belonging to different SIP transactions over SHOULD send messages belonging to different SIP transactions over
different SCTP streams, as long as there are enough available different SCTP streams, as long as there are enough available
streams. streams.
A common scenario where the above mechanism should be used A common scenario where the above mechanism should be used
consists of two proxies exchanging SIP traffic over a TLS consists of two proxies exchanging SIP traffic over a TLS
skipping to change at page 8, line 8 skipping to change at page 6, line 48
recommendation, when a request arrives over a particular stream, the recommendation, when a request arrives over a particular stream, the
server is free to return responses over a different stream. This server is free to return responses over a different stream. This
way, both sides manage the available streams in the sending way, both sides manage the available streams in the sending
direction, independently of the streams chosen by the other side to direction, independently of the streams chosen by the other side to
send a particular SIP message. This avoids undesirable collisions send a particular SIP message. This avoids undesirable collisions
when seizing a particular stream. when seizing a particular stream.
6. Locating a SIP Server 6. Locating a SIP Server
The primary issue when sending a request is determining whether the The primary issue when sending a request is determining whether the
next hop server supports SCTP, so that an association can be opened. next hop server supports SCTP so that an association can be opened.
SIP entities follow normal SIP procedures to discover [6] a server SIP entities follow normal SIP procedures to discover [6] a server
that supports SCTP. that supports SCTP.
However, in order to be able to use TLS on top of SCTP, an extra However, in order to use TLS on top of SCTP, an extra definition is
definition is needed. RFC 3263 defines the NAPTR (Naming Authority needed. RFC 3263 defines the NAPTR (Naming Authority Pointer) [7]
Pointer) [7] service value "SIP+D2S" for SCTP but fails to define a service value "SIP+D2S" for SCTP, but fails to define a value for TLS
value for TLS over SCTP. Here we define the NAPTR service value over SCTP. Here we define the NAPTR service value "SIPS+D2S" for
"SIPS+D2S" for servers that support TLS over SCTP [8]. servers that support TLS over SCTP [8].
7. Security Considerations 7. Security Considerations
The security issues raised in RFC 3261 [5] are not worsened by SCTP, The security issues raised in RFC 3261 [5] are not worsened by SCTP,
provided the advice in Section 5.1 is followed and TLS over SCTP [8] provided the advice in Section 5.1 is followed and TLS over SCTP [8]
is used where TLS would be required in RFC 3261 [5] or in RFC 3263 is used where TLS would be required in RFC 3261 [5] or in RFC 3263
[6]. So, the mechanisms described in RFC 3436 [8] MUST be used when [6]. So, the mechanisms described in RFC 3436 [8] MUST be used when
SIP runs on top of TLS [3] and SCTP. SIP runs on top of TLS [3] and SCTP.
8. IANA Considerations 8. IANA Considerations
This document defines a new value (tls-sctp) for the SIP and SIPS URI This document defines a new NAPTR service field value (SIPS+ D2S).
transport parameter. The IANA is requested to add a reference to The IANA has registered this value under the "Registry for the SIP
this document to the entry of the transport parameter in the SRV Resource Record Services Field". The resulting entry is as
"SIP/SIPS URI Parameters" subregistry, which is located under the follows:
"Session Initiation Protocol (SIP) Parameters" registry. The
reference should appear in double-brackets, as indicated in RFC 3969
[11]. The resulting entry should be:
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
transport Yes [RFC3261] [[RFCXXXX]]
This document also defines a new NAPTR service field value
(SIPS+D2S). The IANA is requested to register this value under the
"Registry for the SIP SRV Resource Record Services Field". The
resulting entry should be:
Services Field Protocol Reference Services Field Protocol Reference
-------------------- -------- --------- -------------------- -------- ---------
SIPS+D2S SCTP [RFCXXXX] SIPS+D2S SCTP [RFC4168]
9. References 9. References
9.1 Normative References 9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999. 2246, January 1999.
[4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000. "Stream Control Transmission Protocol", RFC 2960, October 2000.
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002. Session Initiation Protocol", RFC 3261, June 2002.
[6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol [6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002. (SIP): Locating SIP Servers", RFC 3263, June 2002.
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part
Three: The Domain Name System (DNS) Database", RFC 3403, October Three: The Domain Name System (DNS) Database", RFC 3403, October
2002. 2002.
[8] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer [8] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436, Security over Stream Control Transmission Protocol", RFC 3436,
December 2002. December 2002.
9.2 Informative References 9.2. Informative References
[9] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, [9] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999. "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[10] Coene, L., "Stream Control Transmission Protocol Applicability [10] Coene, L., "Stream Control Transmission Protocol Applicability
Statement", RFC 3257, April 2002. Statement", RFC 3257, April 2002.
[11] Camarillo, G., "The Internet Assigned Number Authority (IANA) [11] Camarillo, G., "The Internet Assigned Number Authority (IANA)
Uniform Resource Identifier (URI) Parameter Registry for the Uniform Resource Identifier (URI) Parameter Registry for the
Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December
2004. 2004.
[12] Camarillo, G., Schulrinne, H. and R. Kantola, "Evaluation of [12] Camarillo, G., Schulrinne, H., and R. Kantola, "Evaluation of
Transport Protocols for the Session Initiation Protocol", IEEE Transport Protocols for the Session Initiation Protocol", IEEE,
Network vol. 17, no. 5, 2003. Network vol. 17, no. 5, 2003.
Authors' Addresses Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
Cisco Systems Cisco Systems
600 Lanidex Plaza 600 Lanidex Plaza
Parsippany, NJ 07054 Parsippany, NJ 07054
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Henning Schulzrinne Henning Schulzrinne
Columbia University Columbia University
M/S 0401 M/S 0401
1214 Amsterdam Ave. 1214 Amsterdam Ave.
New York, NY 10027-7003 New York, NY 10027-7003
US US
EMail: schulzrinne@cs.columbia.edu EMail: schulzrinne@cs.columbia.edu
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
EMail: Gonzalo.Camarillo@ericsson.com EMail: Gonzalo.Camarillo@ericsson.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at ietf-
ietf-ipr@ietf.org. ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 47 change blocks. 
190 lines changed or deleted 135 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/