draft-ietf-sip-sctp-04.txt   draft-ietf-sip-sctp-05.txt 
SIP J. Rosenberg
Internet Engineering Task Force SIP WG Internet-Draft Cisco Systems
Internet Draft J. Rosenberg Expires: May 25, 2005 H. Schulzrinne
dynamicsoft Columbia University
H. Schulzrinne
Columbia U.
G. Camarillo G. Camarillo
Ericsson Ericsson
draft-ietf-sip-sctp-04.txt November 24, 2004
November 19, 2003
Expires: May, 2004
The Stream Control Transmission Protocol as a The Stream Control Transmission Protocol (SCTP) as a Transport for
Transport for the Session Initiation Protocol the Session Initiation Protocol (SIP)
draft-ietf-sip-sctp-05.txt
STATUS OF THIS MEMO Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. 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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as
Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress". material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
To view the list Internet-Draft Shadow Directories, see The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
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 entities. Control Transmission Protocol) as the transport between SIP (Session
SCTP is a new protocol which provides several features that may prove Initiation Protocol) entities. SCTP is a new protocol which provides
beneficial for transport between SIP entities which exchange a large several features that may prove beneficial for transport between SIP
amount of messages, including gateways and proxies. As SIP is entities which exchange a large amount of messages, including
transport independent, support of SCTP is a relatively gateways and proxies. As SIP is transport independent, support of
straightforward process, nearly identical to support for TCP. SCTP is a relatively straightforward process, nearly identical to
support for TCP.
Table of Contents Table of Contents
1 Introduction ........................................ 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Terminology ......................................... 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Potential Benefits .................................. 3 3. Potential Benefits . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Advantages over UDP ................................. 3 3.1 Advantages over UDP . . . . . . . . . . . . . . . . . . . 3
3.2 Advantages over TCP ................................. 4 3.2 Advantages over TCP . . . . . . . . . . . . . . . . . . . 4
4 Usage of SCTP ....................................... 5 4. Usage of SCTP . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Mapping of SIP Transactions into Streams ............ 6 4.1 Mapping of SIP Transactions into SCTP Streams . . . . . . 6
5 Locating a SIP server ............................... 7 5. Locating a SIP Server . . . . . . . . . . . . . . . . . . . . 7
6 Security Considerations ............................. 7 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7 Conclusion .......................................... 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8 Author's Addresses .................................. 7 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
9 Normative References ................................ 8 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 7
10 Informative References .............................. 8 8.2 Informative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
1 Introduction 1. Introduction
The Stream Control Transmission Protocol (SCTP) [1] has been designed The Stream Control Transmission Protocol (SCTP) [3] 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) [2], which is used to initiate and manage interactive Protocol) [4], 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. In order to encourage defined for transport over UDP and TCP. This document defines
experimentation and evaluation of the appropriateness of SCTP for SIP transport of SIP over SCTP.
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 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 [3]. 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 [4]. We Coene et. al. present some of the key benefits of SCTP [7]. 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 [5].) SIP (a more detailed analysis can be found in [9]).
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 Fast Retransmit: SCTP can quickly determine the loss of a packet, as
packet, as a result of its usage of SACK and a mechanism a result of its usage of SACK and a mechanism which sends SACK
which sends SACK messages faster than normal when losses messages faster than normal when losses are detected. The result
are detected. The result is that losses of SIP messages can is that losses of SIP messages can be detected much faster than
be detected much faster than when SIP is run over UDP when SIP is run over UDP (detection will take at least 500 ms, if
(detection will take at least 500ms, if not more). Note not more). Note that TCP SACK does exist as well, and TCP also
that TCP SACK does exist as well, and TCP also has a fast has a fast retransmit option. Over an existing connection, this
retransmit option. Over an existing connection, this results in faster call setup times under conditions of packet
results in faster call setup times under conditions of loss, which is very desirable. This is probably the most
packet loss, which is very desirable. This is probably the significant advantage to SCTP for SIP transport.
most significant advantage to SCTP for SIP transport.
Congestion Control: SCTP maintains congestion control over the Congestion Control: SCTP maintains congestion control over the entire
entire association. For SIP, this means that the aggregate association. For SIP, this means that the aggregate rate of
rate of messages between two entities can be controlled. messages between two entities can be controlled. When SIP is run
When SIP is run over TCP, the same advantages are afforded. over TCP, the same advantages are afforded. However, when run
However, when run over UDP, SIP provides less effective over UDP, SIP provides less effective congestion control. That is
congestion control. That is because congestion state because congestion state (measured in terms of the UDP retransmit
(measured in terms of the UDP retransmit interval) is interval) is computed on a transaction by transaction basis,
computed on a transaction by transaction basis, rather than rather than across all transactions. Congestion control
across all transactions. Congestion control performance is performance is thus similar to opening N parallel TCP connections,
thus similar to opening N parallel TCP connections, as as opposed to sending N messages over one TCP connection.
opposed to sending N messages over 1 TCP connection.
Transport layer fragmentation: SCTP and TCP provide transport Transport-Layer Fragmentation: SCTP and TCP provide transport-layer
layer fragmentation. If a SIP message is larger than the fragmentation. If a SIP message is larger than the MTU size it is
MTU size it is fragmented at the transport layer. When UDP fragmented at the transport layer. When UDP is used fragmentation
is used fragmentation occurs at the IP layer. IP occurs at the IP layer. IP fragmentation increases the likelihood
fragmentation increases the likelihood of having packet of having packet losses and makes it difficult (when not
losses and make it difficult (when not impossible) NAT and impossible) NAT and firewall traversal. This feature will become
firewall traversal. This feature will become important if important if the size of SIP messages grows dramatically.
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 analyze We have shown the advantages of SCTP and TCP over UDP. We now
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 that Head of the Line: SCTP is message based as opposed to TCP which is
is stream based. This allows SCTP to separate different stream based. This allows SCTP to separate different signalling
signalling messages at the transport layer. TCP just messages at the transport layer. TCP just understands bytes.
understands bytes. Assembling received bytes to form Assembling received bytes to form signalling messages is performed
signalling messages is performed at the application layer. at the application layer. Therefore, TCP always delivers an
Therefore, TCP always delivers an ordered stream of bytes ordered stream of bytes to the application. On the other hand,
to the application. On the other hand, SCTP can deliver SCTP can deliver signalling messages to the application as soon as
signalling messages to the application as soon as they they arrive (when using the unordered service). The loss of a
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 messages. This avoids the head of line blocking problem in TCP,
of the messages. This avoids the head of line blocking which occurs when multiple higher layer connections are
problem in TCP, which occurs when multiple higher layer multiplexed within a single TCP connection. A SIP transaction can
connections are multiplexed within a single TCP connection. be considered an application layer connection. Between proxies
A SIP transaction can be considered an application layer there are multiple transactions running. The loss of a message in
connection. Between proxies there are multiple transactions one transaction should not adversely effect the ability of a
running. The loss of a message in one transaction should different transaction to send a message. Thus, if SIP is run
not adversely effect the ability of a different transaction between entities with many transactions occurring in parallel,
to send a message. Thus, if SIP is run between entities SCTP can provide improved performance over SIP over TCP (but not
with many transactions occurring in parallel, SCTP can SIP over UDP; but SIP over UDP is not ideal from a congestion
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). control standpoint, see above).
Easier Parsing: Another advantage of message based protocols Easier Parsing: Another advantage of message based protocols such as
such as SCTP and UDP over stream based protocols such as SCTP and UDP over stream based protocols such as TCP is that they
TCP is that they allow easier parsing of messages at the allow easier parsing of messages at the application layer. There
application layer. There is not need of establishing is not need of establishing boundaries (typically using
boundaries (typically using Content-Length headers) between Content-Length headers) between different messages. However, this
different messages. However, this advantage is almost advantage is almost negligible.
negligible.
Multihoming: An SCTP connection can be associated with multiple Multihoming: An SCTP connection can be associated with multiple IP
IP addresses on the same host. Data is always sent over one addresses on the same host. Data is always sent over one of the
of the addresses, but should it become unreachable, data addresses, but should it become unreachable, data sent to one can
sent to one can migrate to a different address. This migrate to a different address. This improves fault tolerance;
improves fault tolerance; network failures making one network failures making one interface of the server unavailable do
interface of the server unavailable do not prevent the not prevent the service from continuing to operate. SIP servers
service from continuing to operate. SIP servers are likely are likely to have substantial fault tolerance requirements. It
to have substantial fault tolerance requirements. It is is worth noting that because SIP is message oriented, and not
worth noting that because SIP is message-oriented, and not stream oriented, the existing SRV (Service Selection) procedures
stream oriented, the existing SRV procedures defined in [2] defined in [4] can accomplish the same goal, even when SIP is run
can accomplish the same goal, even when SIP is run over over TCP. In fact, SRV records allow the 'connection' to fail
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 failover can be accomplished without data synchronization between
statelessly, failover can be accomplished without data the primary and its backups. Thus, the multihoming capabilities
synchronization between the primary and its backups. Thus, of SCTP provide marginal benefits.
the multihoming capabilities 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. The improvements in setup times and throughput will be observed.
purpose of this draft is to enable such experimentation in order to
provide concrete data on its applicability to SIP.
4 Usage of SCTP 4. Usage of SCTP
Usage of SCTP requires no additional headers or syntax in SIP. Below 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 we show an example of a SIP URL with a transport parameter and an
example of a via header field. In both examples SCTP is the transport example of a Via header field. In both examples SCTP is the
protocol. transport protocol.
sip:Bob.Johnson@example.com;transport=sctp sip:Bob.Johnson@example.com;transport=sctp
Via: SIP/2.0/SCTP ws1234.example.com:5060 Via: SIP/2.0/SCTP ws1234.example.com:5060
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 4.1). within an association in order to send the request (see Section 4.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 Indentifier in SCTP DATA chunks
transporting SIP messages MUST be set to zero. transporting SIP messages MUST be set to zero.
skipping to change at page 6, line 17 skipping to change at page 6, line 5
Via: SIP/2.0/SCTP ws1234.example.com:5060 Via: SIP/2.0/SCTP ws1234.example.com:5060
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 4.1). within an association in order to send the request (see Section 4.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 Indentifier 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 to manage the The SIP transport layers of both peers are responsible for managing
persistent SCTP connection between them. On the sender side the core the persistent SCTP connection between them. On the sender side the
or a client (or server) transaction generates a request (or response) core or a client (or server) transaction generates a request (or
and passes it to the transport layer. The transport sends the request response) and passes it to the transport layer. The transport sends
to the peer's transaction layer. The peer's transaction layer is the request to the peer's transaction layer. The peer's transaction
responsible of delivering the incoming request (or response) to the layer is responsible for delivering the incoming request (or
proper existing server (or client) transaction. If no server (or response) to the proper existing server (or client) transaction. If
client) transaction exists for the incoming message the transport no server (or client) transaction exists for the incoming message the
layer passes the request (or response) to the core, which may decide transport layer passes the request (or response) to the core, which
to construct a new server (or client) transaction. may decide to construct a new server (or client) transaction.
4.1 Mapping of SIP Transactions into Streams 4.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 all the different ways
of performing this mapping that fulfill this requirement, we have of performing this mapping that fulfil this requirement, we have
chosen the simplest one; a SIP entity SHOULD send every SIP message chosen the simplest one; a SIP entity SHOULD send every SIP message
(request or response) over stream zero with the unordered flag set. (request or response) over stream zero with the unordered flag set.
On the receiving side, a SIP entity MUST be ready to receive SIP On the receiving side, a SIP entity MUST be ready to receive SIP
messages over any stream. messages over any stream.
Note that previous versions of this document proposed to In the past, it was proposed to use SCTP stream IDs as lightweight
use SCTP stream IDs as lightweight SIP transaction SIP transaction identifiers. That proposal was withdrawn because
identifiers. That proposal has been withdrawn because SIP SIP now provides (as defined in RFC 3261 [4]) a transaction
now provides a transaction identifier in the branch identifier in the branch parameter of the Via entries. This
parameter of the Via entries. This transaction identifier, transaction identifier, missing in the previous SIP spec [8],
missing in the previous SIP spec [6], makes it unnecessary makes it unnecessary to use the SCTP stream IDs to demultiplex SIP
to use the SCTP stream IDs to demultiplex SIP traffic. traffic.
Some applications introduce an extra layer between the transport SIP has many circumstances in which the use of TLS [2] is required,
layer and SIP (e.g., compression and/or encryption). This extra layer for instance, for routing a SIPS URI [4]. As defined in RFC 3436
sometimes requires ordered delivery of messages from the transport [6], TLS running over SCTP MUST NOT use the SCTP unordered delivery
layer (e.g., TLS [7]). In this case, it is RECOMMENDED that SIP service. Moreover, any SIP use of an extra layer between the
messages belonging to the same transaction are sent over the same transport layer and SIP that requires ordered delivery of messages
stream and messages belonging to different transactions are sent over MUST NOT use the SCTP unordered delivery service.
different streams. Note that if both sides of the association follow
this recommendation, if a request arrives over a particular stream, SIP applications that require ordered delivery of messages from the
the server is free to return responses over a different stream. This transport layer (e.g., TLS) SHOULD send SIP messages belonging to the
same SIP transaction over the same SCTP stream. Additionally, they
SHOULD send messages belonging to different SIP transactions over
different SCTP streams, as long as there are enough available
streams.
A common scenario where the above mechanism should be used
consists of two proxies exchanging SIP traffic over a TLS
connection using SCTP as the transport protocol. This works
because all of the SIP transactions between the two proxies can be
established within one SCTP association.
Note that if both sides of the association follow this
recommendation, when a request arrives over a particular stream, the
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.
5 Locating a SIP server 5. 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 [8] a server SIP entities follow normal SIP procedures to discover [5] a server
that supports SCTP. that supports SCTP.
6 Security Considerations 6. Security Considerations
No extra security risk outside these specified by [2] are foreseen. The security issues raised in RFC 3261 [4] are not worsened by SCTP,
provided the advice in Section 4.1 is followed and SCTP over TLS [6]
is used where TLS would be required in RFC 3261 [4]. So, the
mechanisms described in RFC 3436 [6] MUST be used when SIP runs on
top of TLS [2] and SCTP.
7 Conclusion 7. IANA Considerations
This draft has presented a discussion on the applicability of SCTP to This document has no IANA considerations.
SIP transport, and provided a mechanism for allowing two SCTP-capable
entities to use an SCTP association to exchange SIP traffic.
8 Author's Addresses 8. References
8.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[3] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer,
H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson,
"Stream Control Transmission Protocol", RFC 2960, October 2000.
[4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[5] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol
(SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] Jungmaier, A., Rescorla, E. and M. Tuexen, "Transport Layer
Security over Stream Control Transmission Protocol", RFC 3436,
December 2002.
8.2 Informative References
[7] Coene, L., "Stream Control Transmission Protocol Applicability
Statement", RFC 3257, April 2002.
[8] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg,
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
[9] Camarillo, G., Schulrinne, H. and R. Kantola, "Evaluation of
Transport Protocols for the Session Initiation Protocol", IEEE
Network vol. 17, no. 5, 2003.
Authors' Addresses
Jonathan Rosenberg Jonathan Rosenberg
dynamicsoft Cisco Systems
200 Executive Drive 600 Lanidex Plaza
Suite 120 Parsippany, NJ 07054
West Orange, NJ 07052 US
email: jdrosen@dynamicsoft.com
Phone: +1 973 952-5000
EMail: jdrosen@dynamicsoft.com
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
email: schulzrinne@cs.columbia.edu US
EMail: schulzrinne@cs.columbia.edu
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
Advanced Signalling Research Lab. Hirsalantie 11
FIN-02420 Jorvas Jorvas 02420
Finland Finland
Phone: +358 9 299 3371
Fax: +358 9 299 3052
Email: Gonzalo.Camarillo@ericsson.com
9 Normative References EMail: Gonzalo.Camarillo@ericsson.com
[1] R. J. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Schwarzbauer, Intellectual Property Statement
T. Taylor, I. Rytina, and M. Kalla, "Stream control transmission
protocol," RFC 2960, Internet Engineering Task Force, Oct. 2000.
[2] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. R. Johnston, J. The IETF takes no position regarding the validity or scope of any
Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: session Intellectual Property Rights or other rights that might be claimed to
initiation protocol," RFC 3261, Internet Engineering Task Force, June pertain to the implementation or use of the technology described in
2002. 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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
[3] S. Bradner, "Key words for use in RFCs to indicate requirement Copies of IPR disclosures made to the IETF Secretariat and any
levels," RFC 2119, Internet Engineering Task Force, Mar. 1997. 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
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
10 Informative References The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
[4] L. Coene, "Stream control transmission protocol applicability Disclaimer of Validity
statement," RFC 3257, Internet Engineering Task Force, Apr. 2002.
[5] G. Camarillo, H. Schulzrinne, and R. Kantola, "Evaluation of This document and the information contained herein are provided on an
transport protocols for the session initiation protocol," IEEE "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
Network , vol. 17, no. 5, 2003. 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.
[6] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: Copyright Statement
session initiation protocol," RFC 2543, Internet Engineering Task
Force, Mar. 1999.
[7] T. Dierks and C. Allen, "The TLS protocol version 1.0," RFC 2246, Copyright (C) The Internet Society (2004). This document is subject
Internet Engineering Task Force, Jan. 1999. to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
[8] J. Rosenberg and H. Schulzrinne, "Session initiation protocol Acknowledgment
(SIP): locating SIP servers," RFC 3263, Internet Engineering Task
Force, June 2002. Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 

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