[要約] RFC 7118は、WebSocketプロトコルをセッション開始プロトコル（SIP）の輸送手段として使用する方法について説明しています。このRFCの目的は、SIPをWebSocketを介して効果的に転送するためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) I. Baz Castillo
Request for Comments: 7118 J. Millan Villegas
Category: Standards Track Versatica
ISSN: 2070-1721 V. Pascual
Quobis
January 2014
The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)
セッション開始プロトコル（SIP）のトランスポートとしてのWebSocketプロトコル
Abstract
概要
The WebSocket protocol enables two-way real-time communication between clients and servers in web-based applications. This document specifies a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP) entities to enable use of SIP in web-oriented deployments.
WebSocketプロトコルは、Webベースのアプリケーションでクライアントとサーバー間の双方向のリアルタイム通信を可能にします。このドキュメントでは、Web指向の展開でSIPを使用できるようにするために、Session Initiation Protocol（SIP）エンティティ間の信頼できるトランスポートメカニズムとしてWebSocketサブプロトコルを指定しています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7118.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7118で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . 3
4. The WebSocket SIP Subprotocol . . . . . . . . . . . . . . . . 4
4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. SIP Encoding . . . . . . . . . . . . . . . . . . . . . . 5
5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 6
5.1. Via Transport Parameter . . . . . . . . . . . . . . . . . 6
5.2. SIP URI Transport Parameter . . . . . . . . . . . . . . . 6
5.3. Via "received" Parameter . . . . . . . . . . . . . . . . 7
5.4. SIP Transport Implementation Requirements . . . . . . . . 7
5.5. Locating a SIP Server . . . . . . . . . . . . . . . . . . 8
6. Connection Keep-Alive . . . . . . . . . . . . . . . . . . . . 8
7. Authentication . . . . . . . . . . . . . . . . . . . . . . . 8
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Registration . . . . . . . . . . . . . . . . . . . . . . 10
8.2. INVITE Dialog through a Proxy . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 16
9.2. Usage of "sips" Scheme . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10.1. Registration of the WebSocket SIP Subprotocol . . . . . 16
10.2. Registration of New NAPTR Service Field Values . . . . . 17
10.3. SIP/SIPS URI Parameters Subregistry . . . . . . . . . . 17
10.4. Header Fields Subregistry . . . . . . . . . . . . . . . 17
10.5. Header Field Parameters and Parameter Values Subregistry 17
10.6. SIP Transport Subregistry . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Authentication Use Cases . . . . . . . . . . . . . . 21
A.1. Just SIP Authentication . . . . . . . . . . . . . . . . . 21
A.2. Just Web Authentication . . . . . . . . . . . . . . . . . 21
A.3. Cookie-Based Authentication . . . . . . . . . . . . . . . 22
Appendix B. Implementation Guidelines . . . . . . . . . . . . . 22
B.1. SIP WebSocket Client Considerations . . . . . . . . . . . 23
B.2. SIP WebSocket Server Considerations . . . . . . . . . . . 24
The WebSocket protocol [RFC6455] enables message exchange between clients and servers on top of a persistent TCP connection (optionally secured with Transport Layer Security (TLS) [RFC5246]). The initial protocol handshake makes use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to reuse existing HTTP infrastructure.
WebSocketプロトコル[RFC6455]は、永続的なTCP接続（オプションでトランスポート層セキュリティ（TLS）[RFC5246]で保護されている）上のクライアントとサーバー間のメッセージ交換を可能にします。最初のプロトコルハンドシェイクはHTTP [RFC2616]セマンティクスを利用し、WebSocketプロトコルが既存のHTTPインフラストラクチャを再利用できるようにします。
Modern web browsers include a WebSocket client stack complying with the WebSocket API [WS-API] as specified by the W3C. It is expected that other client applications (those running in personal computers and devices such as smartphones) will also make a WebSocket client stack available. The specification in this document enables use of SIP in these scenarios.
最新のWebブラウザーには、W3Cで指定されているWebSocket API [WS-API]に準拠したWebSocketクライアントスタックが含まれています。他のクライアントアプリケーション（パーソナルコンピューターやスマートフォンなどのデバイスで実行されているもの）でも、WebSocketクライアントスタックを利用できるようになることが期待されます。このドキュメントの仕様により、これらのシナリオでSIPを使用できるようになります。
This specification defines a WebSocket subprotocol (as defined in Section 1.9 of [RFC6455]) for transporting SIP messages between a WebSocket client and server, a reliable and message-boundary-preserving transport for SIP, and DNS Naming Authority Pointer (NAPTR) [RFC3403] service values and procedures for SIP entities implementing the WebSocket transport. Media transport is out of the scope of this document.
この仕様では、WebSocketクライアントとサーバーの間でSIPメッセージを転送するためのWebSocketサブプロトコル（[RFC6455]のセクション1.9で定義）、SIPの信頼性が高くメッセージ境界を維持する転送、およびDNS命名機関ポインタ（NAPTR）[RFC3403 ] WebSocketトランスポートを実装するSIPエンティティのサービス値と手順。メディア転送はこのドキュメントの範囲外です。
Section 3 in this specification relaxes the requirement in [RFC3261] by which the SIP server transport MUST add a "received" parameter in the top Via header in certain circumstances.
この仕様のセクション3は、[RFC3261]の要件を緩和します。これにより、SIPサーバートランスポートは、特定の状況でトップViaヘッダーに「受信」パラメーターを追加する必要があります。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
SIP WebSocket Client: A SIP entity capable of opening outbound connections to WebSocket servers and communicating using the WebSocket SIP subprotocol as defined by this document.
SIP WebSocketクライアント：WebSocketサーバーへの送信接続を開き、このドキュメントで定義されているWebSocket SIPサブプロトコルを使用して通信できるSIPエンティティ。
SIP WebSocket Server: A SIP entity capable of listening for inbound connections from WebSocket clients and communicating using the WebSocket SIP subprotocol as defined by this document.
SIP WebSocketサーバー：WebSocketクライアントからのインバウンド接続をリッスンし、このドキュメントで定義されているWebSocket SIPサブプロトコルを使用して通信できるSIPエンティティ。
The WebSocket protocol [RFC6455] is a transport layer on top of TCP (optionally secured with TLS [RFC5246]) in which both client and server exchange message units in both directions. The protocol defines a connection handshake, WebSocket subprotocol and extensions negotiation, a frame format for sending application and control data, a masking mechanism, and status codes for indicating disconnection causes.
WebSocketプロトコル[RFC6455]は、TCP上のトランスポート層（オプションでTLS [RFC5246]で保護されています）であり、クライアントとサーバーの両方が双方向でメッセージユニットを交換します。このプロトコルは、接続ハンドシェイク、WebSocketサブプロトコルと拡張ネゴシエーション、アプリケーションと制御データを送信するためのフレームフォーマット、マスキングメカニズム、および切断の原因を示すステータスコードを定義します。
The WebSocket connection handshake is based on HTTP [RFC2616] and utilizes the HTTP GET method with an "Upgrade" request. This is sent by the client and then answered by the server (if the negotiation succeeded) with an HTTP 101 status code. Once the handshake is completed, the connection upgrades from HTTP to the WebSocket protocol. This handshake procedure is designed to reuse the existing HTTP infrastructure. During the connection handshake, the client and server agree on the application protocol to use on top of the WebSocket transport. Such an application protocol (also known as a "WebSocket subprotocol") defines the format and semantics of the messages exchanged by the endpoints. This could be a custom protocol or a standardized one (as defined by the WebSocket SIP subprotocol in this document). Once the HTTP 101 response is processed, both the client and server reuse the underlying TCP connection for sending WebSocket messages and control frames to each other. Unlike plain HTTP, this connection is persistent and can be used for multiple message exchanges.
WebSocket接続ハンドシェイクはHTTP [RFC2616]に基づいており、「アップグレード」リクエストでHTTP GETメソッドを利用します。これはクライアントから送信され、サーバーによって（ネゴシエーションが成功した場合）HTTP 101ステータスコードで応答されます。ハンドシェイクが完了すると、接続はHTTPからWebSocketプロトコルにアップグレードされます。このハンドシェイク手順は、既存のHTTPインフラストラクチャを再利用するように設計されています。接続ハンドシェイク中に、クライアントとサーバーは、WebSocketトランスポート上で使用するアプリケーションプロトコルに同意します。このようなアプリケーションプロトコル（「WebSocketサブプロトコル」とも呼ばれます）は、エンドポイントによって交換されるメッセージの形式とセマンティクスを定義します。これは、カスタムプロトコルまたは標準化されたプロトコル（このドキュメントのWebSocket SIPサブプロトコルで定義）の可能性があります。 HTTP 101応答が処理されると、クライアントとサーバーの両方が基になるTCP接続を再利用して、WebSocketメッセージとコントロールフレームを相互に送信します。プレーンHTTPとは異なり、この接続は永続的であり、複数のメッセージ交換に使用できます。
WebSocket defines message units to be used by applications for the exchange of data, so it provides a message-boundary-preserving transport layer. These message units can contain either UTF-8 text or binary data and can be split into multiple WebSocket text/binary transport frames as needed by the WebSocket stack.
WebSocketは、アプリケーションがデータ交換に使用するメッセージユニットを定義するため、メッセージ境界を保持するトランスポート層を提供します。これらのメッセージユニットには、UTF-8テキストまたはバイナリデータを含めることができ、WebSocketスタックの必要に応じて、複数のWebSocketテキスト/バイナリトランスポートフレームに分割できます。
The WebSocket API [WS-API] for web browsers only defines callbacks to be invoked upon receipt of an entire message unit, regardless of whether it was received in a single WebSocket frame or split across multiple frames.
Webブラウザー用のWebSocket API [WS-API]は、単一のWebSocketフレームで受信されたか、複数のフレームに分割されたかに関係なく、メッセージユニット全体の受信時に呼び出されるコールバックのみを定義します。
The term WebSocket subprotocol refers to an application-level protocol layered on top of a WebSocket connection. This document specifies the WebSocket SIP subprotocol for carrying SIP requests and responses through a WebSocket connection.
WebSocketサブプロトコルという用語は、WebSocket接続の上にあるアプリケーションレベルのプロトコルを指します。このドキュメントでは、WebSocket接続を介してSIP要求と応答を伝送するためのWebSocket SIPサブプロトコルを指定します。
The SIP WebSocket Client and SIP WebSocket Server negotiate usage of the WebSocket SIP subprotocol during the WebSocket handshake procedure as defined in Section 1.3 of [RFC6455]. The client MUST include the value "sip" in the Sec-WebSocket-Protocol header in its handshake request. The 101 reply from the server MUST contain "sip" in its corresponding Sec-WebSocket-Protocol header.
[RFC6455]のセクション1.3で定義されているように、SIP WebSocketクライアントとSIP WebSocketサーバーは、WebSocketハンドシェイク手順中にWebSocket SIPサブプロトコルの使用をネゴシエートします。クライアントは、ハンドシェイク要求のSec-WebSocket-Protocolヘッダーに値「sip」を含める必要があります。サーバーからの101応答では、対応するSec-WebSocket-Protocolヘッダーに「sip」が含まれている必要があります。
The WebSocket client initiates a WebSocket connection when attempting to send a SIP request (unless there is an already established WebSocket connection for sending the SIP request). In case there is no HTTP 101 response during the WebSocket handshake, it is considered a transaction error as per [RFC3261], Section 8.1.3.1., "Transaction Layer Errors".
WebSocketクライアントは、SIPリクエストを送信しようとすると、WebSocket接続を開始します（SIPリクエストを送信するための確立済みのWebSocket接続がない場合）。 WebSocketハンドシェイク中にHTTP 101応答がない場合、[RFC3261]のセクション8.1.3.1「トランザクションレイヤーエラー」に従ってトランザクションエラーと見なされます。
Below is an example of a WebSocket handshake in which the client requests the WebSocket SIP subprotocol support from the server:
以下は、クライアントがサーバーからWebSocket SIPサブプロトコルサポートを要求するWebSocketハンドシェイクの例です。
GET / HTTP/1.1
Host: sip-ws.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://www.example.com
Sec-WebSocket-Protocol: sip
Sec-WebSocket-Version: 13
The handshake response from the server accepting the WebSocket SIP subprotocol would look as follows:
WebSocket SIPサブプロトコルを受け入れるサーバーからのハンドシェイク応答は、次のようになります。
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: sip
Once the negotiation has been completed, the WebSocket connection is established and can be used for the transport of SIP requests and responses. Messages other than SIP requests and responses MUST NOT be transmitted over this connection.
ネゴシエーションが完了すると、WebSocket接続が確立され、SIP要求および応答の転送に使用できます。 SIP接続以外のメッセージは、この接続を介して送信してはなりません（MUST NOT）。
WebSocket messages can be transported in either UTF-8 text frames or binary frames. SIP [RFC3261] allows both text and binary bodies in SIP requests and responses. Therefore, SIP WebSocket Clients and SIP WebSocket Servers MUST accept both text and binary frames.
WebSocketメッセージは、UTF-8テキストフレームまたはバイナリフレームで転送できます。 SIP [RFC3261]では、SIP要求と応答でテキストとバイナリの両方の本文を使用できます。したがって、SIP WebSocketクライアントとSIP WebSocketサーバーは、テキストフレームとバイナリフレームの両方を受け入れる必要があります。
If there is at least one non-UTF-8 symbol in the whole SIP message (including headers and the body), then the whole message MUST be sent within a WebSocket binary message. Given the nature of JavaScript and the WebSocket API, it is RECOMMENDED to use UTF-8 encoding (or ASCII, which is a subset of UTF-8) for SIP messages carried over a WebSocket connection.
SIPメッセージ全体（ヘッダーと本文を含む）に少なくとも1つの非UTF-8シンボルがある場合、メッセージ全体をWebSocketバイナリメッセージ内で送信する必要があります。 JavaScriptとWebSocket APIの性質上、WebSocket接続を介して伝送されるSIPメッセージには、UTF-8エンコーディング（またはASCII、UTF-8のサブセット）を使用することをお勧めします。
WebSocket [RFC6455] is a reliable protocol; therefore, the SIP WebSocket subprotocol defined by this document is a reliable SIP transport. Thus, client and server transactions using WebSocket for transport MUST follow the procedures and timer values for reliable transports as defined in [RFC3261].
WebSocket [RFC6455]は信頼できるプロトコルです。したがって、このドキュメントで定義されているSIP WebSocketサブプロトコルは、信頼性の高いSIPトランスポートです。したがって、トランスポートにWebSocketを使用するクライアントとサーバーのトランザクションは、[RFC3261]で定義されている信頼性の高いトランスポートの手順とタイマー値に従う必要があります。
Each SIP message MUST be carried within a single WebSocket message, and a WebSocket message MUST NOT contain more than one SIP message. Because the WebSocket transport preserves message boundaries, the use of the Content-Length header in SIP messages is not necessary when they are transported using the WebSocket subprotocol.
各SIPメッセージは単一のWebSocketメッセージ内で運ばれなければならず（MUST）、WebSocketメッセージには複数のSIPメッセージが含まれていてはなりません（MUST NOT）。 WebSocketトランスポートはメッセージ境界を保持するため、WebSocketサブプロトコルを使用してトランスポートされる場合、SIPメッセージでContent-Lengthヘッダーを使用する必要はありません。
This simplifies the parsing of SIP messages for both clients and servers. There is no need to establish message boundaries using Content-Length headers between messages. Other SIP transports, such as UDP and the Stream Control Transmission Protocol (SCTP) [RFC4168], also provide this benefit.
これにより、クライアントとサーバーの両方のSIPメッセージの解析が簡素化されます。メッセージ間のContent-Lengthヘッダーを使用してメッセージ境界を確立する必要はありません。 UDPやストリーム制御伝送プロトコル（SCTP）[RFC4168]などの他のSIPトランスポートもこの利点を提供します。
Via header fields in SIP messages carry a transport protocol identifier. This document defines the value "WS" to be used for requests over plain WebSocket connections and "WSS" for requests over secure WebSocket connections (in which the WebSocket connection is established using TLS [RFC5246] with TCP transport).
SIPメッセージのヘッダーフィールドを介して、トランスポートプロトコル識別子が伝達されます。このドキュメントでは、プレーンなWebSocket接続を介したリクエストに使用される値「WS」と、セキュアなWebSocket接続を介したリクエストに「WSS」という値を定義しています（この場合、TCPトランスポートでTLS [RFC5246]を使用してWebSocket接続が確立されます）。
The updated augmented BNF (Backus-Naur Form) [RFC5234] for this parameter is the following (the original BNF for this parameter can be found in [RFC3261], which was then updated by [RFC4168]):
このパラメーターの更新された拡張BNF（バッカスナウア形式）[RFC5234]は次のとおりです（このパラメーターの元のBNFは[RFC3261]にあり、[RFC4168]によって更新されました）。
transport =/ "WS" / "WSS"
This document defines the value "ws" as the transport parameter value for a SIP URI [RFC3986] to be contacted using the SIP WebSocket subprotocol as transport.
このドキュメントでは、値「ws」を、SIP WebSocketサブプロトコルをトランスポートとして使用して接続するSIP URI [RFC3986]のトランスポートパラメータ値として定義しています。
The updated augmented BNF for this parameter is the following (the original BNF for this parameter can be found in [RFC3261]):
このパラメーターの更新された拡張BNFは次のとおりです（このパラメーターの元のBNFは[RFC3261]にあります）。
transport-param =/ "transport=" "ws"
The following is stated in [RFC3261], Section 18.2.1, "Receiving Requests":
[RFC3261]のセクション18.2.1、「リクエストの受信」には次のように記載されています。
When the server transport receives a request over any transport, it MUST examine the value of the "sent-by" parameter in the top Via header field value. If the host portion of the "sent-by" field contains a domain name, or if it contains an IP address that differs from the packet source address, the server MUST add a "received" parameter to that Via header field value. This parameter MUST contain the source address from which the packet was received.
サーバートランスポートがトランスポートを介して要求を受信する場合、上部のViaヘッダーフィールド値の "sent-by"パラメーターの値を検査する必要があります。 「sent-by」フィールドのホスト部分にドメイン名が含まれている場合、またはパケットの送信元アドレスとは異なるIPアドレスが含まれている場合、サーバーはそのViaヘッダーフィールド値に「received」パラメーターを追加する必要があります。このパラメーターには、パケットの受信元の送信元アドレスを含める必要があります。
The requirement of adding the "received" parameter does not fit well into the WebSocket protocol design. The WebSocket connection handshake reuses the existing HTTP infrastructure in which there could be an unknown number of HTTP proxies and/or TCP load balancers between the SIP WebSocket Client and Server, so the source address the server would write into the Via "received" parameter would be the address of the HTTP/TCP intermediary in front of it. This could reveal sensitive information about the internal topology of the server's network to the client.
「received」パラメータを追加するという要件は、WebSocketプロトコルの設計にうまく適合しません。 WebSocket接続のハンドシェイクは、SIP WebSocketクライアントとサーバーの間に不明な数のHTTPプロキシやTCPロードバランサーが存在する可能性がある既存のHTTPインフラストラクチャを再利用するため、サーバーがVia "received"パラメーターに書き込む送信元アドレスはその前にあるHTTP / TCP仲介のアドレス。これにより、サーバーのネットワークの内部トポロジに関する機密情報がクライアントに明らかになる可能性があります。
Given the fact that SIP responses can only be sent over the existing WebSocket connection, the Via "received" parameter is of little use. Therefore, in order to allow hiding possible sensitive information about the SIP WebSocket Server's network, this document updates [RFC3261], Section 18.2.1 by stating:
SIP応答は既存のWebSocket接続を介してのみ送信できるという事実を考慮すると、Viaの「received」パラメーターはほとんど役に立ちません。したがって、SIP WebSocketサーバーのネットワークに関する機密情報を非表示にできるようにするために、このドキュメントは[RFC3261]のセクション18.2.1を更新して次のように述べています。
When a SIP WebSocket Server receives a request, it MAY decide not to add a "received" parameter to the top Via header. Therefore, SIP WebSocket Clients MUST accept responses without such a parameter in the top Via header regardless of whether the Via "sent-by" field contains a domain name.
SIP WebSocketサーバーがリクエストを受信すると、「受信」パラメーターを上部のViaヘッダーに追加しないことを決定する場合があります。したがって、SIP WebSocketクライアントは、Viaの「送信者」フィールドにドメイン名が含まれているかどうかに関係なく、上部のViaヘッダーにこのようなパラメーターがない応答を受け入れる必要があります。
The following is stated in [RFC3261], Section 18, "Transport":
以下は、[RFC3261]のセクション18「Transport」に記載されています。
All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols.
すべてのSIP要素はUDPとTCPを実装する必要があります。 SIP要素は他のプロトコルを実装してもよい（MAY）。
The specification of this transport enables SIP to be used as a session establishment protocol in scenarios where none of the other transport protocols defined for SIP can be used. Since some environments do not enable SIP elements to use UDP and TCP as SIP transport protocols, a SIP element acting as a SIP WebSocket Client is not mandated to implement support of UDP and TCP.
このトランスポートの仕様により、SIPに定義されている他のトランスポートプロトコルを使用できないシナリオで、セッション確立プロトコルとしてSIPを使用できます。一部の環境では、SIP要素がUDPおよびTCPをSIPトランスポートプロトコルとして使用できないため、SIP WebSocketクライアントとして機能するSIP要素は、UDPおよびTCPのサポートを実装する必要がありません。
[RFC3263] specifies the procedures that should be followed by SIP entities for locating SIP servers. This specification defines the NAPTR service value "SIP+D2W" for SIP WebSocket Servers that support plain WebSocket connections and "SIPS+D2W" for SIP WebSocket Servers that support secure WebSocket connections.
[RFC3263]は、SIPサーバーを見つけるためにSIPエンティティが従うべき手順を指定します。この仕様では、プレーンWebSocket接続をサポートするSIP WebSocketサーバーのNAPTRサービス値「SIP + D2W」と、セキュアWebSocket接続をサポートするSIP WebSocketサーバーの「SIPS + D2W」を定義しています。
At the time this document was written, DNS NAPTR/Service Record (SRV) queries could not be performed by commonly available WebSocket client stacks (in JavaScript engines and web browsers).
このドキュメントが作成された時点では、DNS NAPTR /サービスレコード（SRV）クエリは、一般に利用可能なWebSocketクライアントスタック（JavaScriptエンジンおよびWebブラウザー）では実行できませんでした。
In the absence of DNS SRV resource records or an explicit port, the default port for a SIP URI using the "sip" scheme and the "ws" transport parameter is 80, and the default port for a SIP URI using the "sips" scheme and the "ws" transport parameter is 443.
DNS SRVリソースレコードまたは明示的なポートがない場合、「sip」スキームと「ws」トランスポートパラメータを使用するSIP URIのデフォルトポートは80であり、「sips」スキームを使用するSIP URIのデフォルトポート「ws」トランスポートパラメータは443です。
SIP WebSocket Clients and Servers may keep their WebSocket connections open by sending periodic WebSocket "Ping" frames as described in [RFC6455], Section 5.5.2.
[RFC6455]のセクション5.5.2で説明されているように、SIP WebSocketクライアントおよびサーバーは、定期的なWebSocket「Ping」フレームを送信することにより、WebSocket接続を開いたままにできます。
The WebSocket API [WS-API] does not provide a mechanism for applications running in a web browser to control whether or not periodic WebSocket "Ping" frames are sent to the server. The implementation of such a keep-alive feature is the decision of each web browser manufacturer and may also depend on the configuration of the web browser.
WebSocket API [WS-API]は、Webブラウザーで実行されているアプリケーションが定期的なWebSocket「Ping」フレームをサーバーに送信するかどうかを制御するメカニズムを提供していません。このようなキープアライブ機能の実装は、各Webブラウザーの製造元の決定であり、Webブラウザーの構成にも依存する場合があります。
The indication and use of the CRLF NAT keep-alive mechanism defined for SIP connection-oriented transports in [RFC5626], Section 3.5.1 or [RFC6223] are, of course, usable over the transport defined in this specification.
[RFC5626]、セクション3.5.1、または[RFC6223]でSIP接続指向のトランスポート用に定義されたCRLF NATキープアライブメカニズムの表示と使用は、もちろん、この仕様で定義されたトランスポート上で使用できます。
This section describes how authentication is achieved through the requirements in [RFC6455], [RFC6265], [RFC2617], and [RFC3261].
このセクションでは、[RFC6455]、[RFC6265]、[RFC2617]、および[RFC3261]の要件によって認証がどのように達成されるかについて説明します。
The WebSocket protocol [RFC6455] does not define an authentication mechanism; instead, it exposes the following text in Section 10.5, "WebSocket Client Authentication":
WebSocketプロトコル[RFC6455]は認証メカニズムを定義していません。代わりに、セクション10.5「WebSocketクライアント認証」で次のテキストを公開します。
This protocol doesn't prescribe any particular way that servers can authenticate clients during the WebSocket handshake. The WebSocket server can use any client authentication mechanism available to a generic HTTP server, such as cookies, HTTP authentication, or TLS authentication.
このプロトコルは、サーバーがWebSocketハンドシェイク中にクライアントを認証できる特定の方法を規定していません。 WebSocketサーバーは、Cookie、HTTP認証、TLS認証など、一般的なHTTPサーバーが使用できる任意のクライアント認証メカニズムを使用できます。
The following list exposes mandatory-to-implement and optional mechanisms for SIP WebSocket Clients and Servers in order to get interoperability at the WebSocket authentication level:
次のリストは、WebSocket認証レベルで相互運用性を実現するために、SIP WebSocketクライアントおよびサーバーの必須から実装へのオプションのメカニズムを公開しています。
o A SIP WebSocket Client MUST be ready to add a session cookie when it runs in a web browser (or behaves like a browser navigating a website) and has previously retrieved a session cookie from the web server whose URL domain matches the domain in the WebSocket URI. This mechanism is defined by [RFC6265].
o SIP WebSocketクライアントは、Webブラウザーで実行される（またはWebサイトをナビゲートするブラウザーのように動作する）セッションCookieを追加する準備ができていなければならず、以前に、URLドメインがWebSocket URIのドメインと一致するWebサーバーからセッションCookieを取得しました。 。このメカニズムは[RFC6265]によって定義されています。
o A SIP WebSocket Client MUST be ready to be challenged with an HTTP 401 status code [RFC2617] by the SIP WebSocket Server when performing the WebSocket handshake.
o SIP WebSocketクライアントは、WebSocketハンドシェイクを実行するときに、SIP WebSocketサーバーによってHTTP 401ステータスコード[RFC2617]でチャレンジを受ける準備ができている必要があります。
o A SIP WebSocket Client MAY use TLS client authentication (when in a secure WebSocket connection) as an optional authentication mechanism.
o SIP WebSocketクライアントは、オプションの認証メカニズムとしてTLSクライアント認証（安全なWebSocket接続の場合）を使用してもよい（MAY）。
Note, however, that TLS client authentication in the WebSocket protocol is governed by the rules of the HTTP protocol rather than the rules of SIP.
ただし、WebSocketプロトコルのTLSクライアント認証は、SIPのルールではなく、HTTPプロトコルのルールによって管理されることに注意してください。
o A SIP WebSocket Server MUST be ready to read session cookies when present in the WebSocket handshake request and use such a cookie value for determining whether the WebSocket connection has been initiated by an HTTP client navigating a website in the same domain (or subdomain) as the SIP WebSocket Server.
o SIP WebSocketサーバーは、WebSocketハンドシェイク要求に存在するときにセッションCookieを読み取る準備ができていなければならず、そのようなCookie値を使用して、WebSocket接続が同じドメイン（またはサブドメイン）のWebサイトをナビゲートするHTTPクライアントによって開始されたかどうかを判断します。 SIP WebSocketサーバー。
o A SIP WebSocket Server SHOULD be able to reject a WebSocket handshake request with an HTTP 401 status code by providing a Basic/Digest challenge as defined for the HTTP protocol.
o SIP WebSocketサーバーは、HTTPプロトコル用に定義されたBasic / Digestチャレンジを提供することにより、HTTP 401ステータスコードでWebSocketハンドシェイク要求を拒否できる必要があります（SHOULD）。
Regardless of whether or not the SIP WebSocket Server requires authentication during the WebSocket handshake, authentication MAY be requested at the SIP level.
SIP WebSocketサーバーがWebSocketハンドシェイク中に認証を要求するかどうかに関係なく、認証はSIPレベルで要求される場合があります。
Some authentication use cases are exposed in Appendix A.
一部の認証の使用例は、付録Aで公開されています。
Alice (SIP WSS) proxy.example.com
| |
|HTTP GET (WS handshake) F1 |
|---------------------------->|
|101 Switching Protocols F2 |
|<----------------------------|
| |
|REGISTER F3 |
|---------------------------->|
|200 OK F4 |
|<----------------------------|
| |
Alice loads a web page using her web browser and retrieves JavaScript code implementing the WebSocket SIP subprotocol defined in this document. The JavaScript code (a SIP WebSocket Client) establishes a secure WebSocket connection with a SIP proxy/registrar (a SIP WebSocket Server) at proxy.example.com. Upon WebSocket connection, Alice constructs and sends a SIP REGISTER request, including Outbound [RFC5626] and Globally Routable User Agent URI (GRUU) [RFC5627] support. Since the JavaScript stack in a browser has no way to determine the local address from which the WebSocket connection was made, this implementation uses a random ".invalid" domain name for the Via header "sent-by" parameter and for the hostport of the URI in the Contact header (see Appendix B.1).
アリスは彼女のWebブラウザーを使用してWebページをロードし、このドキュメントで定義されているWebSocket SIPサブプロトコルを実装するJavaScriptコードを取得します。 JavaScriptコード（SIP WebSocketクライアント）は、proxy.example.comでSIPプロキシ/レジストラ（SIP WebSocketサーバー）との安全なWebSocket接続を確立します。 WebSocket接続時に、アリスはアウトバウンド[RFC5626]とグローバルにルーティング可能なユーザーエージェントURI（GRUU）[RFC5627]サポートを含むSIP REGISTERリクエストを作成して送信します。ブラウザーのJavaScriptスタックにはWebSocket接続が行われたローカルアドレスを判別する方法がないため、この実装では、Viaヘッダーの "sent-by"パラメーターとホストポートのホストポートにランダムな ".invalid"ドメイン名を使用しますContactヘッダーのURI（付録B.1を参照）。
Message details (authentication and Session Description Protocol (SDP) bodies are omitted for simplicity):
メッセージの詳細（認証とセッション記述プロトコル（SDP）の本文は簡略化のために省略されています）：
F1 HTTP GET (WS handshake) Alice -> proxy.example.com (TLS)
F1 HTTP GET（WSハンドシェイク）アリス-> proxy.example.com（TLS）
GET / HTTP/1.1
Host: proxy.example.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: https://www.example.com
Sec-WebSocket-Protocol: sip
Sec-WebSocket-Version: 13
F2 101 Switching Protocols proxy.example.com -> Alice (TLS)
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: sip
F3 REGISTER Alice -> proxy.example.com (transport WSS)
F3 REGISTER Alice-> proxy.example.com（トランスポートWSS）
REGISTER sip:proxy.example.com SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf
From: sip:alice@example.com;tag=65bnmj.34asd
To: sip:alice@example.com
Call-ID: aiuy7k9njasd
CSeq: 1 REGISTER
Max-Forwards: 70
Supported: path, outbound, gruu
Contact: <sip:alice@df7jal23ls0d.invalid;transport=ws>
;reg-id=1
;+sip.instance="<urn:uuid:f81-7dec-14a06cf1>"
F4 200 OK proxy.example.com -> Alice (transport WSS)
F4 200 OK proxy.example.com-> Alice（トランスポートWSS）
SIP/2.0 200 OK
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf
From: sip:alice@example.com;tag=65bnmj.34asd
To: sip:alice@example.com;tag=12isjljn8
Call-ID: aiuy7k9njasd
CSeq: 1 REGISTER
Supported: outbound, gruu
Contact: <sip:alice@df7jal23ls0d.invalid;transport=ws>
;reg-id=1
;+sip.instance="<urn:uuid:f81-7dec-14a06cf1>"
;pub-gruu="sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1"
;temp-gruu="sip:87ash54=3dd.98a@example.com;gr"
;expires=3600
Alice (SIP WSS) proxy.example.com (SIP UDP) Bob
| | |
|INVITE F1 | |
|---------------------------->| |
|100 Trying F2 | |
|<----------------------------| |
| |INVITE F3 |
| |---------------------------->|
| |200 OK F4 |
| |<----------------------------|
|200 OK F5 | |
|<----------------------------| |
| | |
|ACK F6 | |
|---------------------------->| |
| |ACK F7 |
| |---------------------------->|
| | |
| Bidirectional RTP Media |
|<=========================================================>|
| | |
| |BYE F8 |
| |<----------------------------|
|BYE F9 | |
|<----------------------------| |
|200 OK F10 | |
|---------------------------->| |
| |200 OK F11 |
| |---------------------------->|
| | |
In the same scenario, Alice places a call to Bob's Address of Record (AOR). The SIP WebSocket Server at proxy.example.com acts as a SIP proxy, routing the INVITE to Bob's contact address (which happens to be using SIP transported over UDP). Bob answers the call and then terminates it.
同じシナリオで、アリスはボブの記録の住所（AOR）に電話をかけます。 proxy.example.comにあるSIP WebSocketサーバーはSIPプロキシとして機能し、INVITEをBobの連絡先アドレスにルーティングします（これはたまたまUDPで転送されたSIPを使用しています）。ボブは通話に応答してから終了します。
Message details (authentication and SDP bodies are omitted for simplicity): F1 INVITE Alice -> proxy.example.com (transport WSS)
メッセージの詳細（簡単にするため、認証とSDPの本文は省略されています）：F1 INVITE Alice-> proxy.example.com（トランスポートWSS）
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
From: sip:alice@example.com;tag=asdyka899
To: sip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Supported: path, outbound, gruu
Route: <sip:proxy.example.com:443;transport=ws;lr>
Contact: <sip:alice@example.com
;gr=urn:uuid:f81-7dec-14a06cf1;ob>
Content-Type: application/sdp
F2 100 Trying proxy.example.com -> Alice (transport WSS)
F2 100 Trying proxy.example.com-> Alice（トランスポートWSS）
SIP/2.0 100 Trying
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
From: sip:alice@example.com;tag=asdyka899
To: sip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
F3 INVITE proxy.example.com -> Bob (transport UDP)
F3 INVITE proxy.example.com-> Bob（トランスポートUDP）
INVITE sip:bob@203.0.113.22:5060 SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=udp;lr>,
<sip:h7kjh12s@proxy.example.com:443;transport=ws;lr>
From: sip:alice@example.com;tag=asdyka899
To: sip:bob@example.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Supported: path, outbound, gruu
Contact: <sip:alice@example.com
;gr=urn:uuid:f81-7dec-14a06cf1;ob>
Content-Type: application/sdp
F4 200 OK Bob -> proxy.example.com (transport UDP)
SIP/2.0 200 OK
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhjhjqw32c
;received=192.0.2.10
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=udp;lr>,
<sip:h7kjh12s@proxy.example.com:443;transport=ws;lr>
From: sip:alice@example.com;tag=asdyka899
To: sip:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sip:bob@203.0.113.22:5060;transport=udp>
Content-Type: application/sdp
F5 200 OK proxy.example.com -> Alice (transport WSS)
F5 200 OK proxy.example.com-> Alice（トランスポートWSS）
SIP/2.0 200 OK
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bK56sdasks
Record-Route: <sip:proxy.example.com;transport=udp;lr>,
<sip:h7kjh12s@proxy.example.com:443;transport=ws;lr>
From: sip:alice@example.com;tag=asdyka899
To: sip:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Contact: <sip:bob@203.0.113.22:5060;transport=udp>
Content-Type: application/sdp
F6 ACK Alice -> proxy.example.com (transport WSS)
F6 ACKアリス-> proxy.example.com（トランスポートWSS）
ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090
Route: <sip:h7kjh12s@proxy.example.com:443;transport=ws;lr>,
<sip:proxy.example.com;transport=udp;lr>,
From: sip:alice@example.com;tag=asdyka899
To: sip:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 70
F7 ACK proxy.example.com -> Bob (transport UDP)
ACK sip:bob@203.0.113.22:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP proxy.example.com;branch=z9hG4bKhwpoc80zzx
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKhgqqp090
From: sip:alice@example.com;tag=asdyka899
To: sip:bob@example.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 69
F8 BYE Bob -> proxy.example.com (transport UDP)
F8 BYEボブ-> proxy.example.com（トランスポートUDP）
BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0
Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
Route: <sip:proxy.example.com;transport=udp;lr>,
<sip:h7kjh12s@proxy.example.com:443;transport=ws;lr>
From: sip:bob@example.com;tag=bmqkjhsd
To: sip:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 70
F9 BYE proxy.example.com -> Alice (transport WSS)
F9 BYE proxy.example.com-> Alice（トランスポートWSS）
BYE sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1;ob SIP/2.0
Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5
Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
From: sip:bob@example.com;tag=bmqkjhsd
To: sip:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 69
F10 200 OK Alice -> proxy.example.com (transport WSS)
F10 200 OKアリス-> proxy.example.com（トランスポートWSS）
SIP/2.0 200 OK
Via: SIP/2.0/WSS proxy.example.com:443;branch=z9hG4bKmma01m3r5
Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
From: sip:bob@example.com;tag=bmqkjhsd
To: sip:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
F11 200 OK proxy.example.com -> Bob (transport UDP)
SIP/2.0 200 OK
Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
From: sip:bob@example.com;tag=bmqkjhsd
To: sip:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
It is RECOMMENDED that the SIP traffic transported over a WebSocket communication be protected by using a secure WebSocket connection (using TLS [RFC5246] over TCP).
安全なWebSocket接続を使用して（TCP上のTLS [RFC5246]を使用して）、WebSocket通信で転送されるSIPトラフィックを保護することをお勧めします。
When establishing a connection using SIP over secure WebSocket transport, the client MUST authenticate the server using the server's certificate according to the WebSocket validation procedure in [RFC6455].
セキュアなWebSocketトランスポート経由のSIPを使用して接続を確立する場合、クライアントは[RFC6455]のWebSocket検証手順に従ってサーバーの証明書を使用してサーバーを認証する必要があります。
Server operators should note that this authentication procedure is different from the procedure for SIP domain certificates defined in [RFC5922]. Certificates that are appropriate for SIP over TLS over TCP will probably not be appropriate for SIP over secure WebSocket connections.
サーバーオペレーターは、この認証手順が[RFC5922]で定義されているSIPドメイン証明書の手順とは異なることに注意する必要があります。 SIP over TLS over TCPに適した証明書は、SIP over Secure WebSocket接続にはおそらく適さないでしょう。
The "sips" scheme in a SIP URI dictates that the entire request path to the target be secure. If such a path includes a WebSocket connection, it MUST be a secure WebSocket connection.
SIP URIの「sips」スキームは、ターゲットへのリクエストパス全体が安全であることを指示します。そのようなパスにWebSocket接続が含まれている場合は、安全なWebSocket接続である必要があります。
IANA has registered the WebSocket SIP subprotocol under the "WebSocket Subprotocol Name" registry with the following data:
IANAは、「WebSocketサブプロトコル名」レジストリの下にWebSocket SIPサブプロトコルを次のデータで登録しました。
Subprotocol Identifier: sip
サブプロトコル識別子：sip
Subprotocol Common Name: WebSocket Transport for SIP (Session Initiation Protocol)
サブプロトコルの一般名：SIP（Session Initiation Protocol）のWebSocketトランスポート
Subprotocol Definition: [RFC7118]
サブプロトコルの定義：[RFC7118]
This document defines two new NAPTR service field values (SIP+D2W and SIPS+D2W) and IANA has registered these values under the "Registry for the Session Initiation Protocol (SIP) NAPTR Resource Record Services Field". The entries are as follows:
このドキュメントでは、2つの新しいNAPTRサービスフィールド値（SIP + D2WおよびSIPS + D2W）を定義し、IANAはこれらの値を「セッション開始プロトコル（SIP）NAPTRリソースレコードサービスフィールドのレジストリ」に登録しました。エントリは次のとおりです。
Services Field Protocol Reference
-------------- -------- ---------
SIP+D2W WS [RFC7118]
SIPS+D2W WS [RFC7118]
IANA has added a reference to this document under the "SIP/SIPS URI Parameters" subregistry within the "Session Initiation Protocol (SIP) Parameters" registry:
IANAは、「Session Initiation Protocol（SIP）Parameters」レジストリ内の「SIP / SIPS URI Parameters」サブレジストリの下にこのドキュメントへの参照を追加しました。
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
transport Yes [RFC3261][RFC7118]
IANA has added a reference to this document under the "Header Fields" subregistry within the "Session Initiation Protocol (SIP) Parameters" registry:
IANAは、「Session Initiation Protocol（SIP）Parameters」レジストリ内の「Header Fields」サブレジストリの下に、このドキュメントへの参照を追加しました。
Header Name compact Reference
----------- ------- ---------
Via v [RFC3261][RFC7118]
IANA has added a reference to this document under the "Header Field Parameters and Parameter Values" subregistry within the "Session Initiation Protocol (SIP) Parameters" registry:
IANAは、「Session Initiation Protocol（SIP）Parameters」レジストリ内の「Header Field Parameters and Parameter Values」サブレジストリの下に、このドキュメントへの参照を追加しました。
Predefined
Header Field Parameter Name Values Reference
------------ -------------- ------ ---------
Via received No [RFC3261][RFC7118]
This document adds a new subregistry, "SIP Transport", to the "Session Initiation Protocol (SIP) Parameters" registry. Its format and initial values are as shown in the following table:
このドキュメントは、「Session Initiation Protocol（SIP）Parameters」レジストリに「SIP Transport」という新しいサブレジストリを追加します。その形式と初期値は、次の表に示すとおりです。
+------------+------------------------+
| Transport | Reference |
+------------+------------------------+
| UDP | [RFC3261] |
| TCP | [RFC3261] |
| TLS | [RFC3261] |
| SCTP | [RFC3261], [RFC4168] |
| TLS-SCTP | [RFC4168] |
| WS | [RFC7118] |
| WSS | [RFC7118] |
+------------+------------------------+
The policy for registration of values in this registry is "Standards Action" [RFC5226].
このレジストリに値を登録するためのポリシーは、「標準アクション」[RFC5226]です。
Special thanks to the following people who participated in discussions on the SIPCORE and RTCWEB WG mailing lists and contributed ideas and/or provided detailed reviews (the list is likely to be incomplete): Hadriel Kaplan, Paul Kyzivat, Robert Sparks, Adam Roach, Ranjit Avasarala, Xavier Marjou, Nataraju A. B., Martin Vopatek, Alexey Melnikov, Alan Johnston, Christer Holmberg, Salvatore Loreto, Kevin P. Fleming, Suresh Krishnan, Yaron Sheffer, Richard Barnes, Barry Leiba, Stephen Farrell, Ted Lemon, Benoit Claise, Pete Resnick, Binod P.G., and Saul Ibarra Corretge.
SIPCOREおよびRTCWEB WGメーリングリストでのディスカッションに参加し、アイデアを提供したり、詳細なレビューを提供した以下の人々に特に感謝します（リストは不完全である可能性があります）：Hadriel Kaplan、Paul Kyzivat、Robert Sparks、Adam Roach、Ranjitアヴァサララ、ザビエルマルジュ、ナタラジュAB、マーティンヴォパテック、アレクセイメルニコフ、アランジョンストン、クリスターホルムバーグ、サルヴァトーレロレート、ケビンP.フレミング、スレッシュクリシュナン、ヤロンシェファー、リチャードバーンズ、バリーレイバ、スティーブンファレル、テッドレモン、ブノワクレーズ、ピートResnick、Binod PG、Saul Ibarra Corretge。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[RFC2617] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP Authentication：Basic and Digest Access Authentication」 、RFC 2617、1999年6月。
[RFC3261] 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.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、2002年6月。
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[RFC3263] Rosenberg、J。およびH. Schulzrinne、「Session Initiation Protocol（SIP）：Locating SIP Servers」、RFC 3263、2002年6月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[RFC3403] Mealling、M。、「Dynamic Delegation Discovery System（DDDS）Part Three：The Domain Name System（DNS）Database」、RFC 3403、2002年10月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265]バース、A。、「HTTP状態管理メカニズム」、RFC 6265、2011年4月。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011.
[RFC6455] Fette、I。およびA. Melnikov、「The WebSocket Protocol」、RFC 6455、2011年12月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]イーストレイクD.およびA.パニッツ、「予約済みトップレベルDNS名」、BCP 32、RFC 2606、1999年6月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「Hypertext Transfer Protocol-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002.
[RFC3327] Willis、D。およびB. Hoeneisen、「非隣接連絡先を登録するためのセッション開始プロトコル（SIP）拡張ヘッダーフィールド」、RFC 3327、2002年12月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)", RFC 4168, October 2005.
[RFC4168] Rosenberg、J.、Schulzrinne、H。、およびG. Camarillo、「セッション開始プロトコル（SIP）のトランスポートとしてのストリーム制御伝送プロトコル（SCTP）」、RFC 4168、2005年10月。
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626] Jennings、C.、Mahy、R。、およびF. Audet、「Managing Client-Initiated Connections in the Session Initiation Protocol（SIP）」、RFC 5626、2009年10月。
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009.
[RFC5627] Rosenberg、J。、「Session Initiation Protocol（SIP）でグローバルにルーティング可能なユーザーエージェントURI（GRUU）を取得して使用する」、RFC 5627、2009年10月。
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010.
[RFC5922] Gurbani、V.、Lawrence、S。、およびA. Jeffrey、「Session Initiation Protocol（SIP）のドメイン証明書」、RFC 5922、2010年6月。
[RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", RFC 6223, April 2011.
[RFC6223] Holmberg、C。、「Keep-Aliveのサポートの表示」、RFC 6223、2011年4月。
[WS-API] W3C and I. Hickson, Ed., "The WebSocket API", September 2012.
[WS-API] W3CおよびI. Hickson編、「The WebSocket API」、2012年9月。
The sections below briefly describe some SIP over WebSocket scenarios in which authentication takes place in different ways.
以下のセクションでは、認証がさまざまな方法で行われるいくつかのSIP over WebSocketシナリオについて簡単に説明します。
SIP Private Branch Exchange (PBX) model A implements the SIP WebSocket transport defined by this specification. Its implementation is 100% website agnostic as it does not share information with the web server providing the HTML code to browsers, meaning that the SIP WebSocket Server (here, PBX model A) has no knowledge about web login activity within the website.
SIP Private Branch Exchange（PBX）モデルAは、この仕様で定義されているSIP WebSocketトランスポートを実装しています。ブラウザにHTMLコードを提供するWebサーバーと情報を共有しないため、その実装は100％Webサイトに依存しません。つまり、SIP WebSocketサーバー（ここでは、PBXモデルA）は、Webサイト内のWebログインアクティビティについて認識していません。
In this simple scenario, the SIP WebSocket Server does not inspect fields in the WebSocket handshake HTTP GET request such as the request URL, the Origin header value, the Host header value, or the Cookie header value (if present). However, some of those fields could be inspected for a minimal validation (i.e., PBX model A could require that the Origin header value contains a specific URL so just users navigating such a website would be able to establish a WebSocket connection with PBX model A).
この単純なシナリオでは、SIP WebSocketサーバーは、リクエストURL、Originヘッダー値、Hostヘッダー値、またはCookieヘッダー値（存在する場合）などのWebSocketハンドシェイクHTTP GETリクエストのフィールドを検査しません。ただし、これらのフィールドの一部は最小限の検証で検査できます（つまり、PBXモデルAでは、Originヘッダーの値に特定のURLが含まれている必要があるため、そのようなWebサイトをナビゲートするユーザーだけがPBXモデルAとのWebSocket接続を確立できます）。 。
Once the WebSocket connection has been established, SIP authentication is requested by PBX model A for each SIP request coming over that connection. Therefore, SIP WebSocket Clients must be provisioned with their corresponding SIP password.
WebSocket接続が確立されると、その接続を介して着信する各SIP要求に対して、PBXモデルAによってSIP認証が要求されます。したがって、SIP WebSocketクライアントは、対応するSIPパスワードを使用してプロビジョニングする必要があります。
A SIP-to-PSTN (Public Switched Telephone Network) provider offers telephony service for clients logged into its website. The provider does not want to expose SIP passwords into the web for security/ privacy reasons.
SIP-to-PSTN（公衆交換電話網）プロバイダーは、Webサイトにログインしているクライアントにテレフォニーサービスを提供します。プロバイダーは、セキュリティ/プライバシー上の理由から、SIPパスワードをWebに公開することを望んでいません。
Once the user is logged into the web, the web server provides him with a SIP identity (SIP URI) and a session temporary token string (along with the SIP WebSocket Client JavaScript application and SIP settings). The web server stores the SIP identity and session token into a database.
ユーザーがWebにログインすると、WebサーバーはSIP ID（SIP URI）とセッション一時トークン文字列を（SIP WebSocketクライアントJavaScriptアプリケーションとSIP設定とともに）提供します。 Webサーバーは、SIP IDとセッショントークンをデータベースに保存します。
The web application adds the SIP identity and session token as URL query parameters in the WebSocket handshake request and attempts the connection. The SIP WebSocket Server inspects the handshake request and validates that the session token matches the value stored in the database for the given SIP identity. In case the value matches, the WebSocket connection gets "authenticated" for that SIP identity. The SIP WebSocket Client can then register and make calls. The SIP WebSocket Server would, however, verify that the identity in those SIP requests (i.e., the From URI value) matches the SIP identity the WebSocket connection is associated to (otherwise, the SIP request is rejected).
Webアプリケーションは、SIP IDとセッショントークンをWebSocketハンドシェイク要求のURLクエリパラメータとして追加し、接続を試みます。 SIP WebSocketサーバーはハンドシェイク要求を検査し、セッショントークンがデータベースに格納されている特定のSIP IDの値と一致することを検証します。値が一致する場合、WebSocket接続はそのSIP IDに対して「認証」されます。その後、SIP WebSocketクライアントは登録して呼び出しを行うことができます。ただし、SIP WebSocketサーバーは、これらのSIPリクエストのID（From URI値）がWebSocket接続が関連付けられているSIP IDと一致することを確認します（そうでない場合、SIPリクエストは拒否されます）。
When the user performs a logout action in the web, the web server removes the SIP identity and session token tuple from the database and notifies the SIP WebSocket Server, which revokes and closes the WebSocket connection.
ユーザーがWebでログアウトアクションを実行すると、WebサーバーはSIP IDとセッショントークンタプルをデータベースから削除し、SIP WebSocketサーバーに通知します。これにより、WebSocket接続が取り消されて閉じられます。
No SIP authentication takes place in this scenario.
このシナリオでは、SIP認証は行われません。
The Apache web server comes with a new module: mod_sip_websocket. In port 80, the web server is configured to listen for both HTTP common requests and WebSocket handshake requests. Therefore, both the web server and the SIP WebSocket Server are co-located within the same host and same domain.
Apache Webサーバーには、新しいモジュールmod_sip_websocketが付属しています。ポート80で、WebサーバーはHTTP共通要求とWebSocketハンドシェイク要求の両方をリッスンするように構成されています。したがって、WebサーバーとSIP WebSocketサーバーの両方が同じホストと同じドメイン内に共存しています。
Once the user is logged into the web, he is provided with the SIP WebSocket Client JavaScript application and SIP settings. The HTTP 200 response after the login procedure also contains a session cookie [RFC6265]. The web application then attempts a WebSocket connection against the same URL/domain of the website, and thus the session cookie is automatically added by the browser into the WebSocket handshake request (as the WebSocket protocol [RFC6455] states).
ユーザーがWebにログインすると、SIP WebSocketクライアントJavaScriptアプリケーションとSIP設定が提供されます。ログイン手順後のHTTP 200応答には、セッションCookie [RFC6265]も含まれています。次に、WebアプリケーションはWebサイトの同じURL /ドメインに対してWebSocket接続を試行します。したがって、セッションCookieは、ブラウザによってWebSocketハンドシェイク要求に自動的に追加されます（WebSocketプロトコル[RFC6455]の状態として）。
The web server inspects the cookie value (as it would do for a common HTTP request containing a session cookie so that the login procedure is not required again). If the cookie is valid, the WebSocket connection is authorized. And, as in the previous use case, the connection is also associated with a specific SIP identity that must be satisfied by every SIP request coming over that connection.
WebサーバーはCookie値を検査します（セッションCookieを含む一般的なHTTPリクエストの場合と同様に、ログイン手順は再度必要ありません）。 Cookieが有効な場合、WebSocket接続が承認されます。また、前の使用例と同様に、接続は特定のSIP IDにも関連付けられています。このSIP IDは、その接続を介して着信するすべてのSIP要求が満たす必要があります。
No SIP authentication takes place in this scenario but just common cookie usage as widely deployed in the World Wide Web.
このシナリオではSIP認証は行われず、World Wide Webで広く展開されている一般的なCookieの使用のみが行われます。
Let us assume a scenario in which the users access with their web browsers (probably behind NAT) an application provided by a server on an intranet, login by entering their user identifier and credentials, and retrieve a JavaScript application (along with the HTML) implementing a SIP WebSocket Client.
ユーザーが（おそらくNATの背後にある）Webブラウザーを使用してイントラネット上のサーバーによって提供されるアプリケーションにアクセスし、ユーザーIDと資格情報を入力してログインし、JavaScriptアプリケーション（HTMLとともに）を取得するシナリオを想定してみましょう。 SIP WebSocketクライアント。
Such a SIP stack connects to a given SIP WebSocket Server (an outbound SIP proxy that also implements classic SIP transports such as UDP and TCP). The HTTP GET method request sent by the web browser for the WebSocket handshake includes a Cookie [RFC6265] header with the value previously provided by the server after the successful login procedure. The cookie value is then inspected by the WebSocket server to authorize the connection. Once the WebSocket connection is established, the SIP WebSocket Client performs a SIP registration to a SIP registrar server that is reachable through the proxy. After registration, the SIP WebSocket Client and Server exchange SIP messages as would normally be expected.
このようなSIPスタックは、特定のSIP WebSocketサーバー（UDPやTCPなどの従来のSIPトランスポートも実装する発信SIPプロキシ）に接続します。 WebSocketハンドシェイクのためにWebブラウザによって送信されるHTTP GETメソッド要求には、ログイン手順が成功した後にサーバーによって以前に提供された値を含むCookie [RFC6265]ヘッダーが含まれています。次に、Cookie値はWebSocketサーバーによって検査され、接続が承認されます。 WebSocket接続が確立されると、SIP WebSocketクライアントは、プロキシを介して到達可能なSIPレジストラサーバーへのSIP登録を実行します。登録後、SIP WebSocketクライアントとサーバーは、通常予想されるようにSIPメッセージを交換します。
This scenario is quite similar to ones in which SIP user agents (UAs) behind NATs connect to a proxy and must reuse the same TCP connection for incoming requests (because they are not directly reachable by the proxy otherwise). In both cases, the SIP UAs are only reachable through the proxy to which they are connected.
このシナリオは、NATの背後にあるSIPユーザーエージェント（UA）がプロキシに接続し、着信要求に対して同じTCP接続を再利用する必要があるシナリオと非常に似ています（そうしないとプロキシから直接到達できないため）。どちらの場合も、SIP UAは、それらが接続されているプロキシを介してのみ到達可能です。
The SIP Outbound extension [RFC5626] seems an appropriate solution for this scenario. Therefore, these SIP WebSocket Clients and the SIP registrar implement both the Outbound and Path [RFC3327] extensions, and the SIP proxy acts as an Outbound Edge Proxy (as defined in [RFC5626], Section 3.4).
SIPアウトバウンド拡張[RFC5626]は、このシナリオに適したソリューションのようです。したがって、これらのSIP WebSocketクライアントとSIPレジストラは、アウトバウンドとパス[RFC3327]拡張の両方を実装し、SIPプロキシはアウトバウンドエッジプロキシとして機能します（[RFC5626]のセクション3.4で定義）。
SIP WebSocket Clients in this scenario receive incoming SIP requests via the SIP WebSocket Server to which they are connected. Therefore, in some call transfer cases, the use of GRUU [RFC5627] (which should be implemented in both the SIP WebSocket Clients and SIP registrar) is valuable.
このシナリオのSIP WebSocketクライアントは、接続先のSIP WebSocketサーバーを介して着信SIPリクエストを受信します。したがって、一部のコール転送のケースでは、GRUU [RFC5627]（SIP WebSocketクライアントとSIPレジストラの両方で実装する必要があります）の使用が重要です。
If a REFER request is sent to a third SIP user agent including the Contact URI of a SIP WebSocket Client as the target in its Refer-To header field, such a URI will be reachable by the third SIP UA only if it is a globally routable URI. GRUU (Globally Routable User Agent URI) is a solution for those scenarios and would cause the incoming request from the third SIP user agent to be sent to the SIP registrar, which would route the request to the SIP WebSocket Client via the Outbound Edge Proxy.
REFER要求が、Refer-ToヘッダーフィールドのターゲットとしてSIP WebSocketクライアントのContact URIを含む3番目のSIPユーザーエージェントに送信される場合、そのようなURIは、グローバルにルーティング可能な場合にのみ、3番目のSIP UAによって到達可能になります。 URI。 GRUU（Globally Routable User Agent URI）はこれらのシナリオのソリューションであり、3番目のSIPユーザーエージェントからの着信要求がSIPレジストラに送信され、SIPレジストラは要求をOutbound Edge Proxy経由でSIP WebSocketクライアントにルーティングします。
The JavaScript stack in web browsers does not have the ability to discover the local transport address used for originating WebSocket connections. A SIP WebSocket Client running in such an environment can construct a domain name consisting of a random token followed by the ".invalid" top-level domain name, as stated in [RFC2606], and uses it within its Via and Contact headers.
WebブラウザーのJavaScriptスタックには、発信元のWebSocket接続に使用されるローカルトランスポートアドレスを検出する機能がありません。このような環境で実行されているSIP WebSocketクライアントは、[RFC2606]に記載されているように、ランダムトークンとそれに続く「.invalid」トップレベルドメイン名で構成されるドメイン名を作成し、そのViaおよびContactヘッダー内で使用できます。
The Contact URI provided by SIP UAs requesting (and receiving) Outbound support is not used for routing requests to those UAs, thus it is safe to set a random domain in the Contact URI hostport.
アウトバウンドサポートを要求（および受信）するSIP UAによって提供される連絡先URIは、それらのUAへの要求のルーティングには使用されないため、連絡先URIホストポートにランダムドメインを設定しても安全です。
Both the Outbound and GRUU specifications require a SIP UA to include a Uniform Resource Name (URN) in a "+sip.instance" parameter of the Contact header in which they include their SIP REGISTER requests. The client device is responsible for generating or collecting a suitable value for this purpose.
Outbound仕様とGRUU仕様の両方で、SIP UAがSIP REGISTER要求を含むContactヘッダーの「+ sip.instance」パラメーターにUniform Resource Name（URN）を含める必要があります。クライアントデバイスは、この目的に適した値を生成または収集します。
In web browsers, it is difficult to generate or collect a suitable value to be used as an URN value from the browser itself. This scenario suggests that value is generated according to [RFC5626], Section 4.1 by the web application running in the browser the first time it loads the JavaScript SIP stack code, and then it is stored as a cookie within the browser.
Webブラウザーでは、ブラウザー自体からURN値として使用される適切な値を生成または収集することは困難です。このシナリオは、値が[RFC5626]のセクション4.1に従ってブラウザで実行されているWebアプリケーションによって最初に生成され、JavaScript SIPスタックコードが最初にロードされてから、ブラウザ内にCookieとして保存されることを示唆しています。
The SIP WebSocket Server in this scenario behaves as a SIP Outbound Edge Proxy, which involves support for Outbound [RFC5626] and Path [RFC3327].
このシナリオのSIP WebSocketサーバーは、SIPアウトバウンドエッジプロキシとして動作します。これには、アウトバウンド[RFC5626]とパス[RFC3327]のサポートが含まれます。
The proxy performs loose routing and remains in the path of dialogs as specified in [RFC3261]. If it did not do this, in-dialog requests would fail since SIP WebSocket Clients make use of their SIP WebSocket Server in order to send and receive SIP messages.
プロキシはルーズルーティングを実行し、[RFC3261]で指定されているダイアログのパスに残ります。これを行わなかった場合、SIP WebSocketクライアントはSIPメッセージを送受信するためにSIP WebSocketサーバーを利用するため、ダイアログ内の要求は失敗します。
Authors' Addresses
著者のアドレス
Inaki Baz Castillo Versatica Barakaldo, Basque Country Spain
Inaki Baz Castillo Versatica Barakaldo、バスク国スペイン
EMail: ibc@aliax.net
Jose Luis Millan Villegas Versatica Bilbao, Basque Country Spain
ホセルイスミランヴィルガスベルサティカビルバオ、バスク国スペイン
EMail: jmillan@aliax.net
Victor Pascual Quobis Spain
ビクターパスクアルクオビススペイン
EMail: victor.pascual@quobis.com