[要約] RFC 4168は、SCTPをSIPの輸送プロトコルとして使用するためのガイドラインを提供します。このRFCの目的は、SIPの信頼性とパフォーマンスを向上させるために、SCTPを使用する方法を示すことです。
Network Working Group J. Rosenberg
Request for Comments: 4168 Cisco Systems
Category: Standards Track H. Schulzrinne
Columbia University
G. Camarillo
Ericsson
October 2005
The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）の輸送としてのストリーム制御伝送プロトコル（SCTP）
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).
Copyright（c）The Internet Society（2005）。
Abstract
概要
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
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シグナル伝達メッセージの輸送を念頭に置いて設計されています。このようなシグナル伝達の輸送をサポートするように設計された機能の多くは、SIP（セッション開始プロトコル）[5]の輸送にも役立つことを観察しました。
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.
SIP自体は輸送に依存しており、信頼性の高いまたは信頼性の低いメッセージまたはストリームトランスポートを実行できます。ただし、手順は、UDPおよびTCPを介した輸送に対してのみ定義されます。このドキュメントでは、SCTP上のSIPの輸送を定義しています。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [1]に記載されているように解釈される。
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]にあります）。
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.
SCTPがSIP輸送に関するUDPよりも持つすべての利点もTCPによって共有されています。以下に、TCPやSCTPなどの接続指向のトランスポートプロトコルが、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は、サックの使用法と、損失が検出されたときに通常よりも速くサックメッセージを送信するメカニズムのため、パケットの損失を迅速に決定できます。その結果、SIPメッセージの損失は、SIPがUDP上で実行されたときよりもはるかに速く検出できます（検出には少なくとも500ミリ秒かかりますが、それ以上ではありません）。TCPサックも存在し、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メッセージのサイズが劇的に増加すると、この機能が重要になります。
We have shown the advantages of SCTP and TCP over UDP. We now analyze the advantages of SCTP over TCP.
UDPよりもSCTPとTCPの利点を示しました。次に、TCPよりもSCTPの利点を分析します。
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).
LINEのヘッド：SCTPは、TCPとは対照的に、ストリームベースのTCPとは対照的です。これにより、SCTPは輸送層で異なる信号メッセージを分離できます。TCPはバイトのみを理解しています。受信したバイトを組み立ててシグナリングメッセージを形成することは、アプリケーションレイヤーで実行されます。したがって、TCPは常に順序付けられたバイトのストリームをアプリケーションに提供します。一方、SCTPは、到着するとすぐに[順序付けされていないサービスを使用する場合）に信号メッセージをアプリケーションに配信できます。信号メッセージの喪失は、残りのメッセージの配信に影響しません。これにより、TCPのラインブロッキング問題のヘッドが回避されます。これは、単一のTCP接続内で複数の高層接続が多重化されている場合に発生します。SIPトランザクションは、アプリケーションレイヤー接続と見なすことができます。プロキシ間で複数のトランザクションが実行されています。あるトランザクションでメッセージを失うことは、異なるトランザクションがメッセージを送信する能力に悪影響を与えるべきではありません。したがって、SIPが多くのトランザクションが並行して発生しているエンティティ間で実行される場合、SCTPはTCPよりもSIPよりも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.
簡単な解析：TCPなどのストリームベースのプロトコルよりも、SCTPやUDPなどのメッセージベースのプロトコルのもう1つの利点は、アプリケーションレイヤーでのメッセージの簡単な解析を可能にすることです。異なるメッセージ間で境界（通常はコンテンツ長ヘッダーを使用）を確立する必要はありません。ただし、この利点はほとんど無視できます。
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.
Multihoming：SCTP接続は、同じホストの複数のIPアドレスに関連付けられます。データは常にアドレスのいずれかを介して送信されますが、到達不可能になった場合、送信されたデータは別のアドレスに移行できます。これにより、断層の許容度が向上します。ネットワークの障害サーバーの1つのインターフェイスを利用できなくても、サービスが動作し続けるのを妨げません。SIPサーバーには、かなりの障害トレランス要件がある可能性があります。SIPはメッセージ指向であり、ストリーム指向ではないため、[5]で定義されている既存のSRV（サービス選択）手順は、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.
SIPに対するSCTPの利点のほとんどは、損失条件下で発生することに注意することが重要です。したがって、ゼロ損失条件下では、SIPのSCTP輸送はTCP輸送と同等の実行を行う必要があります。セットアップ時間とスループットの改善がどのような損失条件の下で評価されるかを評価するには、研究が必要です。
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):
ここでは、SCTPを介してTLSを介して送信されたリクエストに使用されるVIAヘッダーフィールドの輸送部分の値「TLS-SCTP」を定義します[8]。このパラメーターの更新された拡張BNF（Backus-Naurフォーム）[2]は次のとおりです（このパラメーターの元のBNFは、RFC 3261にあります）：
transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP"
/ other-transport
The following are examples of Via header fields using "SCTP" and "TLS-SCTP":
以下は、「SCTP」と「TLS-SCTP」を使用したVia Headerフィールドの例です。
Via: SIP/2.0/SCTP ws1234.example.com:5060
Via: SIP/2.0/TLS-SCTP ws1234.example.com:5060
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).
SCTPを介してリクエストを送信するためのルールは、TCPと同じです。唯一の違いは、SCTP送信者がリクエストを送信するために、関連付け内の特定のストリームを選択する必要があることです（セクション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.
SIPメッセージに対してSCTP識別子を定義する必要はないことに注意してください。したがって、SCTPデータの輸送チャンクのペイロードプロトコル識別子は、ゼロに設定する必要があります。
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.
両方のピアのSIP輸送層は、それらの間の永続的なSCTP接続を管理する責任があります。送信者側では、コアまたはクライアント（またはサーバー）トランザクションがリクエスト（または応答）を生成し、輸送層に渡します。トランスポートは、リクエストをピアのトランザクションレイヤーに送信します。ピアのトランザクションレイヤーは、適切な既存のサーバー（またはクライアント）トランザクションに着信要求（または応答）を配信する責任があります。着信メッセージに対してサーバー（またはクライアント）トランザクションが存在しない場合、トランスポートレイヤーはリクエスト（または応答）をコアに渡し、新しいサーバー（またはクライアント）トランザクションを構築することを決定する場合があります。
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トランザクションは、ラインヘッド（HOL）ブロッキングを回避する方法でSCTPストリームにマッピングする必要があります。この要件を満たすこのマッピングを実行するさまざまな方法の中で、私たちは最も単純な要件を選択しました。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]で定義されている）、VIAエントリのブランチパラメーターのトランザクション識別子を提供しているため、その提案が撤回されました。前のSIP仕様[9]に欠落しているこのトランザクション識別子は、SCTPストリームIDを使用してSIPトラフィックをDemultlexで使用する必要はありません。
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.
多くの状況で、SIPでは、たとえばSIPS URI [5]をルーティングするときに、TLS [3]の使用が必要です。RFC 3436 [8]で定義されているように、SCTPを介して実行されているTLSは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.
トランスポートレイヤー（TLSなど）からのメッセージの配信が必要なSIPアプリケーションは、同じSCTPストリームで同じSIPトランザクションに属するSIPメッセージを送信する必要があります。さらに、利用可能なストリームが十分にある限り、異なるSCTPストリームを介して異なるSIPトランザクションに属するメッセージを送信する必要があります。
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.
協会の両側がこの推奨事項に従う場合、特定のストリームにリクエストが届くと、サーバーは異なるストリームで応答を自由に返すことができます。このようにして、両側は、特定の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エンティティは、通常のSIP手順に従って、[6] SCTPをサポートするサーバーを発見します。
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の値を定義できません。ここでは、SCTPよりもTLSをサポートするサーバーのNAPTRサービス値「SIPS D2S」を定義します[8]。
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のアドバイスが守られ、RFC 3261 [5]またはRFC 3263 [6でTLSが必要な場合、SCTP [8]を介したTLSが使用されています。]。したがって、RFC 3436 [8]に記載されているメカニズムは、SIPがTLS [3]およびSCTPの上で実行される場合に使用する必要があります。
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 Resource Record Servicesフィールドのレジストリ」の下でこの値を登録しています。結果のエントリは次のとおりです。
Services Field Protocol Reference
-------------------- -------- ---------
SIPS+D2S SCTP [RFC4168]
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[2] Crocker、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] Dierks、T。およびC. Allen、「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] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV. Paxson、「ストリーム制御伝送プロトコル」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、RFC 3261、2002年6月。
[6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[6] Rosenberg、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。、「Dynamic Delogation Discovery System（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.、Rescorla、E。、およびM. Tuexen、「ストリーム制御伝送プロトコルを介した輸送層セキュリティ」、RFC 3436、2002年12月。
[9] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999.
[9] Handley、M.、Schulzrinne、H.、Schooler、E。、およびJ. Rosenberg、「SIP：SESSION INTIATION Protocol」、RFC 2543、1999年3月。
[10] Coene, L., "Stream Control Transmission Protocol Applicability Statement", RFC 3257, April 2002.
[10] Coene、L。、「Stream Control Transmission Protocol Applicabilityステートメント」、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] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）のための数字権権（IANA）のユニフォームリソース識別子（URI）パラメーターレジストリ」、BCP 99、RFC 3969、2004年12月。
[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] Camarillo、G.、Schulrinne、H。、およびR. Kantola、「セッション開始プロトコルの輸送プロトコルの評価」、IEEE、Network Vol。17、いいえ。5、2003。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
ジョナサンローゼンバーグシスコシステム600ラニデックスプラザパルシッパニー、ニュージャージー07054米国
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 US
ヘニングシュルツリンヌコロンビア大学M/S 0401 1214 AMSTERDAM AVE. NEW YORK、NY 10027-7003 US
EMail: schulzrinne@cs.columbia.edu
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland
Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: Gonzalo.Camarillo@ericsson.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
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に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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 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 http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。