RFC4168 日本語訳

Network Working Group                                       J. Rosenberg
Request for Comments: 4168                                 Cisco Systems
Category: Standards Track                                 H. Schulzrinne
                                                     Columbia University
                                                            G. Camarillo
                                                                Ericsson
                                                            October 2005

コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 4168年のシスコシステムズカテゴリ: 標準化過程H.Schulzrinneコロンビア大学G.キャマリロエリクソン2005年10月

            The Stream Control Transmission Protocol (SCTP)
        as a Transport for the Session Initiation Protocol (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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(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(セッションInitiationプロトコル)実体の間の移送機構としてSCTP(Stream Control Transmissionプロトコル)の使用法にメカニズムを指定します。 SCTPは多量のメッセージを交換するSIP実体の間の輸送に有益であると判明するかもしれないいくつかの特徴を提供する新しいプロトコルです、ゲートウェイとプロキシを含んでいて。 SIPが輸送から独立しているとき、SCTPのサポートはTCPのためにサポートするためにほとんど同じ比較的簡単なプロセスです。

Rosenberg, et al.           Standards Track                     [Page 1]

RFC 4168              SCTP as a Transport for SIP           October 2005

ローゼンバーグ、他 規格は2005年10月に一口のための輸送としてRFC4168SCTPを追跡します[1ページ]。

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. 序論…2 2. 用語…2 3. 可能性は利益を得ます…2 3.1. UDPより利点…3 3.2. TCPより利点…3 4. パラメタを輸送してください…5 5. SCTP用法…5 5.1. SCTPへの一口トランザクションに関するマッピングは流れます…5 6. 一口サーバの場所を見つけます…6 7. セキュリティ問題…7 8. IANA問題…7 9. 参照…7 9.1. 標準の参照…7 9.2. 有益な参照…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.

Stream Control Transmissionプロトコル(SCTP)[4]はインターネット(または、イントラネット)への新しいトランスポート・プロトコルとしてTCPとUDPと同じ層に設計されています。 SCTPはレガシーSS7シグナリングメッセージの輸送で念頭に設計されています。 私たちは、また、そのようなシグナリングの輸送をサポートするように設計された特徴の多くもインターネットの対話的なセッションを開始して、管理するのに使用されるSIP(Session Initiationプロトコル)[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の輸送を定義します。

2.  Terminology

2. 用語

   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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?

3.  Potential Benefits

3. 潜在的利益

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

RFC3257はSCTP[10]の主要な利益のいくつかを提示します。 私たちは、これらの利益のいくつかをここへまとめて、それらがどうSIPに関連するかを分析します。([12])で、より詳細な分析は見つけることができます。

Rosenberg, et al.           Standards Track                     [Page 2]

RFC 4168              SCTP as a Transport for SIP           October 2005

ローゼンバーグ、他 規格は2005年10月に一口のための輸送としてRFC4168SCTPを追跡します[2ページ]。

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.

また、SCTPがUDPの上にSIP輸送に関して持っているすべての利点が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はすぐにパケットの損失を決定できます、SACKの使用法と損失が検出されるとき標準より速くメッセージをSACKに送るメカニズムのために。 結果はSIPがUDPの上に実行される(検出が少なくとも500msを取るでしょう、以上でないなら)時よりはるかに速くSIPメッセージの損失を検出できるということです。 また、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つの実体の間のメッセージの集合レートを制御できることを意味します。 TCPの上にSIPを実行すると、同じ利点を提供します。 しかしながら、UDPの上に実行されると、SIPはそれほど有効でない輻輳制御を提供します。 これは混雑状態(UDPに関して測定されて、間隔を再送する)がトランザクションごとのすべてのトランザクションの向こう側にというよりむしろベースで計算されるからです。 したがって、混雑管理性能はN初めの平行なTCP接続と同様です、1つ以上のTCP接続をNメッセージに送ることと対照的に。

   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.

私たちは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

線のヘッド: SCTPはTCPと対照的にメッセージベースです。TCPはストリームベースです。 これで、SCTPはトランスポート層で異なった合図メッセージを切り離すことができます。 TCPはバイトを理解しているだけです。 形成するためにメッセージに合図しながら容認されたバイトを組み立てるのは応用層で実行されます。 したがって、TCPはいつも配送します。

Rosenberg, et al.           Standards Track                     [Page 3]

RFC 4168              SCTP as a Transport for SIP           October 2005

ローゼンバーグ、他 規格は2005年10月に一口のための輸送としてRFC4168SCTPを追跡します[3ページ]。

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

アプリケーションへのバイトの命令されたストリーム。 他方では、到着すると(順不同のサービスを利用するとき)すぐに、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.

より簡単な構文解析: SCTPやUDPなどのメッセージベースのプロトコルの別の利点は応用層にメッセージの、より簡単な構文解析を許容するというTCPなどのストリームベースのプロトコルの上でことです。 異なったメッセージの間で境界を確立する(Content-長さのヘッダーを通常使用します)必要は全くありません。 しかしながら、この利点はほとんど取るにたらないです。

   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.

マルチホーミング: 同じホストに関する複数のIPアドレスにSCTP接続を関連づけることができます。 いつもアドレスの1つ以上をデータに送りますが、手が届かなくなるなら、1つに送られたデータは異なったアドレスにわたることができます。 これは耐障害性を改良します。 サーバの1つのインタフェースを入手できなくするネットワーク失敗は、サービスが、作動し続けているのを防ぎません。 SIPサーバはかなりの耐障害性要件を持っていそうです。 適応するストリームではなく、SIPが適応するメッセージであるのでSRV(サービスSelection)手順が[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.

SIPのためのSCTPの利益の大部分が損失条件のもとで起こることに注意するのは重要です。 したがって、ゼロの下で、損失状態、SIPのSCTP輸送はTCP輸送がある平価に働くべきです。 研究が、セットアップ時間とスループットにおける改良がどんな損失条件のもとで観測されるかを評価するのに必要です。

Rosenberg, et al.           Standards Track                     [Page 4]

RFC 4168              SCTP as a Transport for SIP           October 2005

ローゼンバーグ、他 規格は2005年10月に一口のための輸送としてRFC4168SCTPを追跡します[4ページ]。

4.  Transport Parameter

4. 輸送パラメタ

   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.

ヘッダーフィールドで、輸送プロトコル識別子を運んでください。 RFC3261はSCTPのために値の"SCTP"を定義しますが、SCTPの上のTLSのための輸送パラメタのために値は定義しません。 RFC3261によって定義された値の「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):

ここで、私たちが輸送のための"TLS-SCTP"が離れている値を定義する、ヘッダーフィールドで、要求に使用されるのはSCTP[8]の上をTLSを移動しました。 このパラメタのためのアップデートされた増大しているBNF(BN記法)[2]は以下(RFC3261でこのパラメタのためのオリジナルのBNFを見つけることができる)です:

   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":

↓これは"SCTP"と"TLS-SCTP"を使用するViaヘッダーフィールドに関する例です:

     Via: SIP/2.0/SCTP ws1234.example.com:5060
     Via: SIP/2.0/TLS-SCTP ws1234.example.com:5060

以下を通って SIP/2.0/SCTP ws1234.example.com: 5060Via: SIP/2.0/TLS-SCTP ws1234.example.com: 5060

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

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.

どんなSCTP識別子も、SIPメッセージのために定義される必要でないことに注意してください。 したがって、SIPメッセージを輸送するSCTP DATA塊における有効搭載量プロトコルIdentifierはゼロに用意ができなければなりません。

   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接続を管理するのに原因となります。 送付者側では、コアかクライアント(または、サーバ)トランザクションが、要求(または、応答)を生成して、それをトランスポート層に通過します。 輸送は同輩のトランザクション層に要求を送ります。 同輩のトランザクション層は適切な既存のサーバ(または、クライアント)トランザクションに入って来る要求(または、応答)を提供するのに原因となります。 サーバ(または、クライアント)トランザクションが全く入力メッセージのために存在していないなら、トランスポート層は要求(または、応答)にコアに合格します。(それは、新しいサーバ(または、クライアント)トランザクションを構成すると決めるかもしれません)。

5.1.  Mapping of SIP Transactions into SCTP Streams

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

SIPトランザクションは、立ち塞がりながらHead Of線(HOL)を避ける方法でSCTPストリームに写像される必要があります。 この要件を実現させるこのマッピングを実行する異なった方法の中では、私たちは選びました。

Rosenberg, et al.           Standards Track                     [Page 5]

RFC 4168              SCTP as a Transport for SIP           October 2005

ローゼンバーグ、他 規格は2005年10月に一口のための輸送としてRFC4168SCTPを追跡します[5ページ]。

   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.

最も簡単なもの。 SHOULDが順不同の旗のセットがあるストリームゼロの上のあらゆる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が現在提供するので、その提案は引き下がりました。(RFC3261で[5]) Viaエントリーのブランチパラメタのトランザクション識別子を定義するので。 この前のSIP仕様[9]でなくなったトランザクション識別子で、SCTPストリームIDをdemultiplex SIPトラフィックに使用するのは不要になります。

   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[5]を発送するとき、SIPはTLS[3]の使用を必要とします。 RFC3436[8]で定義されるように、SCTP MUST NOTをひく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.

SHOULDトランスポート層(例えば、TLS)からのメッセージの命令された配送を必要とするSIPアプリケーションで、SIPメッセージは同じSCTPストリームの上で同じSIPトランザクションに属します。 さらに、それら、SHOULDはメッセージに異なった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つのプロキシから成ります。 これは、1つのSCTP協会の中に2つのプロキシの間のSIPトランザクションのすべてを設立できるので、働いています。

   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メッセージを送るために送付方向に利用可能なストリームを管理します。 特定のストリームを捕らえるとき、これは望ましくない衝突を避けます。

6.  Locating a SIP Server

6. 一口サーバの場所を見つけます。

   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実体は、[6] SCTPをサポートするサーバを発見するために正常なSIP手順に従います。

Rosenberg, et al.           Standards Track                     [Page 6]

RFC 4168              SCTP as a Transport for SIP           October 2005

ローゼンバーグ、他 規格は2005年10月に一口のための輸送としてRFC4168SCTPを追跡します[6ページ]。

   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を使用するために、付加的な定義が必要です。 RFC3263はSCTPのためにNAPTR(Authority Pointerを命名する)[7]サービス価値の「一口+D2S」を定義しますが、SCTPの上のTLSのために値は定義しません。 ここで、私たちはSCTP[8]の上でTLSをサポートするサーバのためにNAPTRサービス値の「一口+D2S」を定義します。

7.  Security Considerations

7. セキュリティ問題

   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.

RFC3261[5]で提起された安全保障問題はSCTPによって悪化させられていません、セクション5.1でのアドバイスが従われていて、SCTP[8]の上のTLSがTLSがRFC3261[5]かRFC3263[6]で必要であるところで使用されるなら。 それで、SIPがTLS[3]とSCTPの上で稼働するとき、RFC3436[8]で説明されたメカニズムを使用しなければなりません。

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]

分野プロトコル参照を修理します。-------------------- -------- --------- 一口+D2S SCTP[RFC4168]

9.  References

9. 参照

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.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

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

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

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

[3] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。

   [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.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「ストリーム制御伝動プロトコル」、RFC2960(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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。

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

[6] ローゼンバーグ、J.、およびH.Schulzrinne、「セッション開始は(一口)について議定書の中で述べます」。 「一口サーバの場所を見つけます」、RFC3263、2002年6月。

Rosenberg, et al.           Standards Track                     [Page 7]

RFC 4168              SCTP as a Transport for SIP           October 2005

ローゼンバーグ、他 規格は2005年10月に一口のための輸送としてRFC4168SCTPを追跡します[7ページ]。

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

[7] 食事、M.、「ダイナミックな委譲発見システム(DDDS)は3を分けます」。 「ドメインネームシステム(DNS)データベース」、RFC3403、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、「ストリーム制御伝動プロトコルの上のトランスポート層セキュリティ」、RFC3436、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.ローゼンバーグは「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC2543、1999年3月。

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

[10]Coene、L.、「ストリーム制御伝動プロトコル適用性証明」、RFC3257、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.、「セッション開始プロトコル(一口)のためのISOCの機関の一つで(IANA)Uniform Resource Identifier(URI)パラメタ登録」、BCP99、RFC3969(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] キャマリロ、G.、Schulrinne、H.、およびR.Kantola、「セッション開始プロトコルのためのトランスポート・プロトコルの評価」、IEEE、Network vol.17、No.5、2003。

Rosenberg, et al.           Standards Track                     [Page 8]

RFC 4168              SCTP as a Transport for SIP           October 2005

ローゼンバーグ、他 規格は2005年10月に一口のための輸送としてRFC4168SCTPを追跡します[8ページ]。

Authors' Addresses

作者のアドレス

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

ジョナサンローゼンバーグシスコシステムズ600Lanidex Plazaニュージャージー07054パーシッパニー(米国)

   Phone: +1 973 952-5000
   EMail: jdrosen@cisco.com
   URI:   http://www.jdrosen.net

以下に電話をしてください。 +1 973 952-5000 メールしてください: jdrosen@cisco.com ユリ: http://www.jdrosen.net

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

ヘニングSchulzrinneコロンビア大学M/S0401 1214アムステルダムAve。 ニューヨーク、ニューヨーク10027-7003米国

   EMail: schulzrinne@cs.columbia.edu

メール: schulzrinne@cs.columbia.edu

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

ゴンサロキャマリロエリクソンHirsalantie11Jorvas02420フィンランド

   EMail: Gonzalo.Camarillo@ericsson.com

メール: Gonzalo.Camarillo@ericsson.com

Rosenberg, et al.           Standards Track                     [Page 9]

RFC 4168              SCTP as a Transport for SIP           October 2005

ローゼンバーグ、他 規格は2005年10月に一口のための輸送としてRFC4168SCTPを追跡します[9ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 Editor機能のための基金は現在、インターネット協会によって提供されます。

Rosenberg, et al.           Standards Track                    [Page 10]

ローゼンバーグ、他 標準化過程[10ページ]