Network Working Group                                       J. Rosenberg
Request for Comments: 4168                                 Cisco Systems
Category: Standards Track                                 H. Schulzrinne
                                                     Columbia University
                                                            G. Camarillo
                                                            October 2005
            The Stream Control Transmission Protocol (SCTP)
        as a Transport for the Session Initiation Protocol (SIP)

Status of This Memo


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.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。このメモの配布は無制限です。

Copyright Notice


Copyright (C) The Internet Society (2005).




This document specifies a mechanism for usage of SCTP (the Stream Control Transmission Protocol) as the transport mechanism between SIP (Session Initiation Protocol) entities. SCTP is a new protocol that provides several features that may prove beneficial for transport between SIP entities that 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.

この文書では、SIP(セッション開始プロトコル)エンティティ間の転送メカニズムとしてSCTP(ストリーム制御伝送プロトコル)の使用のためのメカニズムを指定します。 SCTPはゲートウェイやプロキシなど、大量のメッセージを交換SIPエンティティ間の輸送のために有用であることが証明されるいくつかの機能を提供する新しいプロトコルです。 SIPは、トランスポートに依存しているとして、SCTPのサポートは、TCPのサポートとほぼ同じ、比較的簡単なプロセスです。

Table of Contents


   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Potential Benefits ..............................................2
      3.1. Advantages over UDP ........................................3
      3.2. Advantages over TCP ........................................3
   4. Transport Parameter .............................................5
   5. SCTP Usage ......................................................5
      5.1. Mapping of SIP Transactions into SCTP Streams ..............5
   6. Locating a SIP Server ...........................................6
   7. Security Considerations .........................................7
   8. IANA Considerations .............................................7
   9. References ......................................................7
      9.1. Normative References .......................................7
      9.2. Informative References .....................................8
1. Introduction
1. はじめに

The Stream Control Transmission Protocol (SCTP) [4] 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) [5], which is used to initiate and manage interactive sessions on the Internet.

ストリーム制御伝送プロトコル(SCTP)[4] TCPとUDPと同じ層に新しいトランスポートインターネットプロトコル(またはイントラネット)として設計されています。 SCTPは、心の中でシグナリングメッセージをレガシーSS7の輸送に設計されています。我々は、インターネット上の対話型セッションを開始し、管理するために使用される、[5]そのようなシグナリングのトランスポートをサポートするように設計された機能の多くは、SIP(セッション開始プロトコル)の輸送のためにも有用であることを観察しました。

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. This document defines transport of SIP over SCTP.


2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。

3. Potential Benefits

RFC 3257 presents some of the key benefits of SCTP [10]. We summarize some of these benefits here and analyze how they relate to SIP (a more detailed analysis can be found in [12]).

RFC 3257はSCTP [10]の主な利点のいくつかを紹介します。ここでは、これらの利点のいくつかを要約し、それらがSIP(より詳細な分析は、[12]に記載されています)にどのように関係するかを分析します。

3.1. Advantages over UDP
3.1. 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, because of its usage of SACK and a mechanism that 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 500 ms, if not more). Note that TCP SACK exists 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 of SCTP for SIP transport.

高速再送:SCTPはすぐに、そのSACKの使用量と損失が検出されたときに、通常よりも早くSACKメッセージを送り機構を、パケットの損失を決定することができます。結果は、SIPメッセージの損失はSIPが(検出がない場合より、少なくとも500ミリ秒かかります)UDP上で実行されたときよりもはるかに高速に検出することができるということです。 TCP SACKが同様に存在し、TCPはまた、高速再送信オプションを持っていることに注意してください。既存の接続を介して、これは非常に望ましいパケット損失、の条件の下でより高速呼設定時間になります。これはおそらく、SIPの輸送のためのSCTPの最も重要な利点です。

Congestion Control: SCTP maintains congestion control over the entire 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. This 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. Thus, congestion control performance is similar to opening N parallel TCP connections, as opposed to sending N messages over one TCP connection.

輻輳制御:SCTPは、全協会にわたり輻輳制御を維持します。 SIPの場合、これは2つのエンティティ間のメッセージの集約レートを制御することができることを意味しています。 SIPは、TCP上で実行されると、同じ利点を与えています。 UDP上で実行した場合しかし、SIPは、あまり効果的な輻輳制御を提供します。輻輳状態が(UDP再送信間隔で測定)ではなく、すべてのトランザクション間よりも、トランザクションごとに計算されるためです。 1つのTCP接続を介してNメッセージの送信とは対照的に、このように、輻輳制御性能は、開口部Nの並列TCP接続と同様です。

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 makes NAT and firewall traversal difficult, if not impossible. This feature will become important if the size of SIP messages grows dramatically.

トランスポート・レイヤ・フラグメンテーション:SCTPとTCPはトランスポート層の断片化を提供します。 SIPメッセージがMTUサイズよりも大きい場合、それはトランスポート層で断片化されます。 UDPを使用する場合は、断片化は、IPレイヤで発生します。 IPフラグメンテーションは、パケットロスを持つ可能性を高め、不可能ではないにしても、NATやファイアウォール越えを困難にします。 SIPメッセージのサイズが劇的に増大した場合、この機能が重要になります。

3.2. Advantages over TCP
3.2. 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, which is stream-based. This allows SCTP to separate different signalling messages at the transport layer. TCP only 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. There are multiple transactions running between proxies. 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; SIP over UDP is not ideal from a congestion control standpoint; see above).

ラインのヘッド:ストリームベースであるTCP、とは対照的に、SCTPは、メッセージベースです。これは、SCTPは、トランスポート層で異なるシグナリングメッセージを分離することを可能にします。 TCPはバイトのみを理解しています。シグナリングメッセージを形成するために受信したバイトをアセンブルするアプリケーション層で行われます。したがって、TCPは常にアプリケーションバイトの順序付けられたストリームを配信します。 (順不同サービスを使用している場合)一方、SCTPは、すぐに彼らが到着すると、アプリケーションへのシグナリングメッセージを配信することができます。シグナリングメッセージの損失は、メッセージの残りの配信には影響しません。これは、複数の上位レイヤの接続は、単一のTCP接続内で多重化されたときに発生する、TCPの行ブロッキング問題の頭を回避します。 SIPトランザクションは、アプリケーションレイヤ接続とみなすことができます。プロキシ間で実行されている複数のトランザクションがあります。 1つのトランザクションでのメッセージの損失に悪影響メッセージを送信するために異なるトランザクションの能力に影響を与えるべきではありません。 SIPは、並列に発生する多くのトランザクションとエンティティ間で実行された場合したがって、SCTPは、TCP上のSIPにわたって改善された性能を提供することができる(ただし、UDP上SIPない; UDPは輻輳制御の観点から理想的ではない上にSIP;上記参照)。

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 no need to establish boundaries (typically using Content-Length headers) between different messages. However, this advantage is almost negligible.


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 if it becomes 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 (Service Selection) procedures 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 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 benefits.

マルチホーミング:SCTP接続は、同じホスト上の複数のIPアドレスに関連付けることができます。データは常にアドレスのいずれかを介して送信されているが、それが到達不能になった場合、1に送信されたデータが別のアドレスに移動することができます。これは、フォールトトレランスが向上します。サーバーの一つのインタフェースが使用できなくなってネットワーク障害が動作し続けることからサービスを防ぐことはできません。 SIPサーバは、かなりのフォールトトレランスの要件を持っている可能性があります。 SIPメッセージ指向していないストリーム指向、で定義されている既存のSRV(サービス選択)手順[5] SIPは、TCP上で実行されていても同じ目標を達成することができているので、ことは注目に値します。実際には、SRVレコードは、「接続」は別のホストにフェイルオーバーすることができます。 SIPプロキシは、ステートレス実行することができるので、フェイルオーバーは、プライマリとバックアップの間でデータの同期なしに達成することができます。このように、SCTPのマルチホーミング機能は、限界利益をもたらします。

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.


4. Transport Parameter

Via header fields carry a transport protocol identifier. 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.

ヘッダフィールドを介してトランスポート・プロトコル識別子を運びます。 RFC 3261はSCTPのために、「SCTP」の値を定義しますが、SCTP上のTLSのためのトランスポート・パラメータの値を定義していません。 RFC 3261で定義された値「TLS」が、TCP上のTLSのために意図されていることに注意してください。

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]. 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):

ここでは、[8] SCTP上TLSを介して送信されるリクエストのために使用されるViaヘッダーフィールドの搬送部の値「TLS-SCTP」を定義します。更新された拡張BNF(バッカス - ナウア記法)[2]このパラメータは、次の(このパラメータの元のBNFは、RFC 3261に見出すことができる)です。

transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" / other-transport

輸送= "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" /他の輸送

The following are examples of Via header fields using "SCTP" and "TLS-SCTP":


Via: SIP/2.0/SCTP Via: SIP/2.0/TLS-SCTP

ビア:SIP / 2.0 / SCTP経由:SIP / 2.0 / TLS-SCTPの

5. SCTP Usage
5. 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 (see Section 5.1).


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


The SIP transport layers of both peers are responsible for managing the persistent SCTP connection between them. On the sender side, the core or a client (or server) transaction generates a request (or response) and passes it to the transport layer. The transport sends the request to the peer's transaction layer. The peer's transaction layer is responsible for delivering the incoming request (or response) to the proper existing server (or client) transaction. If no server (or client) transaction exists for the incoming message, the transport layer passes the request (or response) to the core, which may decide to construct a new server (or client) transaction.


5.1. Mapping of SIP Transactions into SCTP Streams
5.1. SCTPストリームにSIPトランザクションのマッピング

SIP transactions need to be mapped into SCTP streams in a way that avoids Head Of the Line (HOL) blocking. Among the different ways of performing this mapping that fulfill this requirement, we have chosen the simplest one; a SIP entity SHOULD send every SIP message (request or response) over stream zero with the unordered flag set. On the receiving side, a SIP entity MUST be ready to receive SIP messages over any stream.

SIPトランザクションは、SCTPは、ライン(HOL)ブロッキングの頭部を回避するようにストリームにマッピングされる必要があります。この要件を満たすこのマッピングを実行するさまざまな方法の中で、私たちは、最も単純なものを選びました。 SIPエンティティは、順序付けられていないフラグを設定してストリームゼロ上すべてのSIPメッセージ(要求または応答)を送信すべきです。受信側では、SIPエンティティは、任意のストリーム上のSIPメッセージを受信する準備ができなければなりません。

In the past, it was proposed that SCTP stream IDs be used as lightweight SIP transaction identifiers. That proposal was withdrawn because SIP now provides (as defined in RFC 3261 [5]) a transaction identifier in the branch parameter of the Via entries. This transaction identifier, missing in the previous SIP spec [9], makes it unnecessary to use the SCTP stream IDs to demultiplex SIP traffic.

過去には、それはSCTPストリームIDが軽量SIPトランザクション識別子として使用することが提案されました。 SIPは現在提供しているため(RFC 3261で定義されている[5])が提案は撤回されたビア・エントリの分岐パラメータのトランザクション識別子。このトランザクション識別子は、以前のSIP仕様[9]に欠けている、それは不必要なSIPトラフィックを分離するためにSCTPストリームIDを使用することができます。

In many circumstances, SIP requires the use of TLS [3], for instance, when routing a SIPS URI [5]. As defined in RFC 3436 [8], TLS running over SCTP MUST NOT use the SCTP unordered delivery service. Moreover, any SIP use of an extra layer between the transport layer and SIP that requires ordered delivery of messages MUST NOT use the SCTP unordered delivery service.

SIPS URIをルーティングする際に多くの状況では、SIPは、[5]、例えば、[3] TLSの使用を必要とします。 RFC 3436で定義されている[8]、TLSはSCTP上で動作するSCTP順不同配信サービスを使用してはいけません。また、メッセージの順序付き配信を要求するトランスポート層とSIPの間に余分な層の任意のSIPを使用することは、SCTP順不同配信サービスを使用してはなりません。

SIP applications that require ordered delivery of messages from the 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.

上記メカニズムが使用されるべき一般的なシナリオでは、トランスポートプロトコルとしてSCTPを使用してTLS接続を介してSIPトラフィックを交換する2つのプロキシから成ります。 2つのプロキシ間のSIPトランザクションのすべて1つのSCTPアソシエーション内で確立することができますので、これは動作します。

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 direction, independently of the streams chosen by the other side to send a particular SIP message. This avoids undesirable collisions when seizing a particular stream.


6. Locating a SIP Server
6. SIPサーバーの検索

The primary issue when sending a request is determining whether the next hop server supports SCTP so that an association can be opened. SIP entities follow normal SIP procedures to discover [6] a server that supports SCTP.

協会が開くことができるように、主要な問題の要求を送信するネクストホップサーバがSCTPをサポートしているかどうかを判断されます。 SIPエンティティは、SCTPをサポートしています[6]のサーバを発見するために、通常のSIPの手順に従ってください。

However, in order to use TLS on top of SCTP, an extra definition is needed. RFC 3263 defines the NAPTR (Naming Authority Pointer) [7] service value "SIP+D2S" for SCTP, but fails to define a value for TLS over SCTP. Here we define the NAPTR service value "SIPS+D2S" for servers that support TLS over SCTP [8].

しかし、SCTPの上にTLSを使用するためには、余分な定義が必要とされています。 RFC 3263はSCTPためNAPTR(機関ポインタ命名)[7]サービス値「SIP + D2S」を定義するが、SCTP上のTLSの値を定義することができません。ここでは、[8] SCTP上でTLSをサポートするサーバーのためのNAPTRサービス値「SIPS + D2S」を定義します。

7. Security Considerations

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] 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 SIP runs on top of TLS [3] and SCTP.

RFC 3261に上げ、セキュリティの問題が[5] SCTPによって悪化されていない、第5.1節にアドバイスがSCTPにわたって追跡およびTLSが提供される[8]は使用されているTLSは、RFC 3261に必要とされる場合、[5]またはRFC 3263 [6 ]。したがって、メカニズムはRFC 3436に記載され[8] SIPはTLS [3]、SCTPの上で実行する際に使用されなければなりません。

8. IANA Considerations
8. IANAの考慮事項

This document defines a new NAPTR service field value (SIPS+ D2S). The IANA has registered this value under the "Registry for the SIP SRV Resource Record Services Field". The resulting entry is as follows:

この文書は、新しいNAPTRサービスフィールド値(SIPS + D2S)を定義します。 IANAは、「SIP SRVリソースレコードのフィールドサービスのレジストリ」の下で、この値が登録されています。次のように結果のエントリは次のとおりです。

   Services Field        Protocol  Reference
   --------------------  --------  ---------
   SIPS+D2S              SCTP      [RFC4168]
9. References
9.1. Normative References
9.1. 引用規格

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[2]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF:ABNF"、RFC 2234、1997年11月。

[3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.

[3]ダークス、T.とC.アレン、 "TLSプロトコルバージョン1.0"、RFC 2246、1999年1月。

[4] 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]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、RFC 2960、2000年10月。

[5] 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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP:セッション開始プロトコル" 、RFC 3261、2002年6月。

[6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.

[6]ローゼンバーグ、J.、およびH. Schulzrinneと、 "セッション開始プロトコル(SIP):SIPサーバの検索"、RFC 3263、2002年6月。

[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.

[7] Mealling、M.、 "ダイナミックな委譲発見システム(DDDS)パート3:ドメインネームシステム(DNS)データベース"、RFC 3403、2002年10月。

[8] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002.

[8] Jungmaier、A.、レスコラ、E.、およびM. Tuexen、 "ストリーム制御伝送プロトコルを介してトランスポート層セキュリティ"、RFC 3436、2002年12月。

9.2. Informative References
9.2. 参考文献

[9] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.

[9]ハンドレー、M.、Schulzrinneと、H.、学生はE.、およびJ.ローゼンバーグ、 "SIP:セッション開始プロトコル"、RFC 2543、1999年3月。

[10] Coene, L., "Stream Control Transmission Protocol Applicability Statement", RFC 3257, April 2002.

[10] Coene、L.、 "ストリーム制御伝送プロトコルの適用性に関する声明"、RFC 3257、2002年4月。

[11] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004.

[11]カマリロ、G.、BCP 99、RFC 3969、2004年12月 "セッション開始プロトコル(SIP)のための番号機関(IANA)のURI(Uniform Resource Identifier)パラメータレジストリの割り当てインターネット"。

[12] Camarillo, G., Schulrinne, H., and R. Kantola, "Evaluation of Transport Protocols for the Session Initiation Protocol", IEEE, Network vol. 17, no. 5, 2003.

[12]キャマリロ、G.、Schulrinne、H.、およびR. Kantola、 "セッション開始プロトコルのためのトランスポートプロトコルの評価"、IEEE、ネットワーク容量。 17、ありません。 5、2003。

Authors' Addresses


Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US

ジョナサン・ローゼンバーグシスコシステムズ600 Lanidexプラザパーシッパニー、NJ 07054米国

Phone: +1 973 952-5000 EMail: URI:

電話:+1 973 952-5000 Eメール URI:

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

ヘニングSchulzrinneとコロンビア大学のM / S 0401 1214アムステルダムアベニュー。ニューヨーク、NY 10027-7003米国



Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland

ゴンサロ・カマリロエリクソンHirsalantie 11 Jorvas 02420フィンランド



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.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、(もしあれば)後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

Intellectual Property


The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in 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.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any 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


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。



Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。