[要約] RFC 8124は、SDPにおけるWebSocket接続URI属性に関する仕様であり、SDPセッションのWebSocket接続情報を提供するための目的で作成されました。
Internet Engineering Task Force (IETF) R. Ravindranath
Request for Comments: 8124 G. Salgueiro
Category: Standards Track Cisco
ISSN: 2070-1721 March 2017
The Session Description Protocol (SDP) WebSocket Connection URI Attribute
セッション記述プロトコル（SDP）WebSocket接続URI属性
Abstract
概要
The WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications. This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport.
WebSocketプロトコルは、Webベースのアプリケーションでクライアントとサーバー間の双方向のリアルタイム通信を可能にします。このドキュメントでは、トランスポートとしてWebSocketを使用するアプリケーションプロトコルのセッション記述プロトコル（SDP）の拡張について説明します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8124.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8124で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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 ....................................................2
2. Terminology .....................................................3
3. SDP Considerations ..............................................3
3.1. General ....................................................3
3.2. "websocket-uri" SDP Attribute ..............................4
3.3. "websocket-uri" Multiplexing Considerations ................4
4. SDP Offer/Answer Procedures .....................................5
4.1. General ....................................................5
4.2. Generating the Initial Offer ...............................5
4.3. Generating the Answer ......................................6
4.4. Offerer Processing of the Answer ...........................7
4.5. Modifying the Session ......................................7
4.6. Offerless INVITE Scenarios .................................8
5. Procedures at WebSocket Client ..................................8
6. Security Considerations .........................................9
7. IANA Considerations .............................................9
7.1. Registration of the "websocket-uri" SDP Media Attribute ....9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Acknowledgements ..................................................12
Authors' Addresses ................................................12
The WebSocket protocol [RFC6455] enables bidirectional 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 Hypertext Transfer Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket protocol to reuse existing HTTP infrastructure.
WebSocketプロトコル[RFC6455]は、永続的なTCP接続（オプションでトランスポート層セキュリティ（TLS）[RFC5246]で保護されている）上でのクライアントとサーバー間の双方向メッセージ交換を可能にします。最初のプロトコルハンドシェイクは、ハイパーテキスト転送プロトコル（HTTP）[RFC7230]セマンティクスを利用して、WebSocketプロトコルが既存のHTTPインフラストラクチャを再利用できるようにします。
Modern web browsers include a WebSocket client stack compliant with the WebSocket API [WS-API] as specified by the W3C. It is expected that other client applications (e.g., those running on personal computers, mobile devices, etc.) will also make a WebSocket client stack available. Several specifications have been written that define how different applications can use a WebSocket subprotocol as a reliable transport mechanism.
最新のWebブラウザーには、W3Cで指定されているWebSocket API [WS-API]に準拠したWebSocketクライアントスタックが含まれています。他のクライアントアプリケーション（パーソナルコンピュータ、モバイルデバイスなどで実行されているもの）でも、WebSocketクライアントスタックを利用できるようになることが期待されます。さまざまなアプリケーションが信頼できる転送メカニズムとしてWebSocketサブプロトコルを使用する方法を定義するいくつかの仕様が作成されています。
For example, [RFC7118] defines a WebSocket subprotocol as a reliable transport mechanism between Session Initiation Protocol (SIP)[RFC3261] entities to enable use of SIP in web-oriented deployments. Additionally, [RFC7977] defines a new WebSocket subprotocol as a reliable transport mechanism between Message Session Relay Protocol (MSRP) clients and relays. [RFC7395] defines a WebSocket subprotocol for the Extensible Messaging and Presence Protocol (XMPP). Similarly, [BFCP-WEBSOCKET] defines a WebSocket subprotocol as a reliable transport mechanism between Binary Floor Control Protocol (BFCP) [BFCP] entities to enable usage of BFCP in new scenarios.
たとえば、[RFC7118]では、WebSocketサブプロトコルを、Session Initiation Protocol（SIP）[RFC3261]エンティティ間の信頼できるトランスポートメカニズムとして定義し、Web指向のデプロイメントでSIPを使用できるようにしています。さらに、[RFC7977]は、新しいWebSocketサブプロトコルをメッセージセッションリレープロトコル（MSRP）クライアントとリレー間の信頼できるトランスポートメカニズムとして定義しています。 [RFC7395]は、Extensible Messaging and Presence Protocol（XMPP）のWebSocketサブプロトコルを定義しています。同様に、[BFCP-WEBSOCKET]は、WebSocketサブプロトコルをBinary Floor Control Protocol（BFCP）[BFCP]エンティティ間の信頼できるトランスポートメカニズムとして定義し、新しいシナリオでBFCPを使用できるようにします。
When a WebSocket subprotocol is used as a transport mechanism between a server and client, there needs to be a way to indicate the connection URI from the server to the WebSocket client. For applications that use Session Description Protocol (SDP) [RFC4566] to negotiate, the connection URI can be indicated by means of an SDP attribute. This specification defines new SDP attributes to indicate the connection URI for the WebSocket client. Applications that use SDP for negotiation and WebSocket as a transport protocol can use this specification to advertise the WebSocket client connection URI.
WebSocketサブプロトコルがサーバーとクライアント間のトランスポートメカニズムとして使用される場合、サーバーからWebSocketクライアントへの接続URIを示す方法が必要です。セッション記述プロトコル（SDP）[RFC4566]を使用してネゴシエートするアプリケーションの場合、接続URIはSDP属性を使用して示すことができます。この仕様では、WebSocketクライアントの接続URIを示す新しいSDP属性を定義しています。ネゴシエーションにSDPを使用し、トランスポートプロトコルとしてWebSocketを使用するアプリケーションは、この仕様を使用してWebSocketクライアント接続URIを通知できます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "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」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこの文書の "は、[RFC2119]で説明されているように解釈されます。
Applications that use the SDP Offer/Answer mechanism [RFC3264] for negotiating media and also use WebSocket or secure WebSocket as a transport protocol MAY indicate the connection URI for the WebSocket client via a new SDP "a=" media-level attribute defined in Section 3.2.
メディアのネゴシエーションにSDPオファー/アンサーメカニズム[RFC3264]を使用し、トランスポートプロトコルとしてWebSocketまたはセキュアWebSocketも使用するアプリケーションは、セクションで定義された新しいSDP "a ="メディアレベル属性を介してWebSocketクライアントの接続URIを示す場合があります。 3.2。
This section defines a new SDP media-level attribute, "websocket-uri", which can appear in any of the media sections.
このセクションでは、任意のメディアセクションに表示できる新しいSDPメディアレベル属性「websocket-uri」を定義します。
Example:
例：
a=websocket-uri:wss://example.com/chat
Where "wss://example.com/chat" is the ws-URI defined in Section 3 of [RFC6455].
ここで、「wss：//example.com/chat」は、[RFC6455]のセクション3で定義されているws-URIです。
When the "websocket-uri" attribute is present in the media section of the SDP, the IP address in "c=" line SHALL be ignored and the full URI SHALL be used instead to open the WebSocket connection. The clients MUST ensure that they use the URI to open the WebSocket connection and ignore the IP address in the "c=" line and the port in the "m=" line.
「websocket-uri」属性がSDPのメディアセクションにある場合、「c =」行のIPアドレスは無視され、代わりに完全なURIを使用してWebSocket接続を開く必要があります。クライアントは、URIを使用してWebSocket接続を開き、「c =」行のIPアドレスと「m =」行のポートを無視することを確認する必要があります。
Multiplexing characteristics of SDP attributes are described in [SDP-MUX]. Various SDP attribute multiplexing categories are introduced there.
SDP属性の多重化特性は、[SDP-MUX]で説明されています。そこでは、さまざまなSDP属性多重化カテゴリーが導入されています。
o The multiplexing category of the "a=websocket-uri" attribute is CAUTION.
o 「a = websocket-uri」属性の多重化カテゴリーは注意です。
There are no multiplexing rules specified for the "websocket-uri" SDP media-level attribute. Additionally, the specification of multiplexing rules for the "websocket-uri" attribute is outside the scope of this document.
「websocket-uri」SDPメディアレベル属性に指定された多重化ルールはありません。さらに、「websocket-uri」属性の多重化ルールの仕様は、このドキュメントの範囲外です。
While it is technically possible to bundle WebSocket, there are a variety of reasons that make it impractical; thus, it is considered unlikely to be used in practice. Therefore, the "websocket-uri" SDP media-level attribute defined in Section 3.2 for using WebSocket as a transport protocol is not likely to be used with SDP bundle and is consequently categorized as CAUTION for multiplexing.
技術的にはWebSocketをバンドルすることは可能ですが、WebSocketを非実用的にするさまざまな理由があります。したがって、実際に使用される可能性は低いと考えられます。したがって、WebSocketをトランスポートプロトコルとして使用するためにセクション3.2で定義された「websocket-uri」SDPメディアレベル属性は、SDPバンドルでは使用されない可能性が高く、その結果、多重化の注意として分類されます。
If future extensions define how to bundle WebSocket, then multiplexing rules for the "a=websocket-uri" attribute need to be defined as well, for instance, in an extension of this SDP based WebSocket negotiation specification.
今後の拡張機能がWebSocketのバンドル方法を定義する場合、「a = websocket-uri」属性の多重化ルールも、たとえばこのSDPベースのWebSocketネゴシエーション仕様の拡張で定義する必要があります。
An endpoint (i.e., both the offerer and the answerer) that wishes to negotiate WebSocket as transport protocol MUST indicate that it wishes to use WebSocket or secure WebSocket in the "proto" field of the "m=" line. Furthermore, the server side, which could be either the offerer or answerer, MUST add an "a=websocket-uri" attribute in the media section whose value can be either "ws-URI" or "wss-URI", as defined in Section 3 of [RFC6455], depending on whether it wishes to use WebSocket or secure WebSocket. This new attribute MUST follow the syntax defined in Section 3. The procedures in this section apply to an "m=" line associated with any media stream that uses WebSocket or secure WebSocket as transport.
トランスポートプロトコルとしてWebSocketをネゴシエートすることを希望するエンドポイント（つまり、提供者と回答者の両方）は、「m =」行の「proto」フィールドでWebSocketまたはセキュアWebSocketを使用したいことを示さなければなりません（MUST）。さらに、サーバー側（提供者または回答者のいずれか）は、メディアセクションに「a = websocket-uri」属性を追加する必要があります。この属性の値は、「ws-URI」または「wss-URI」のいずれかです。 [RFC6455]のセクション3。WebSocketを使用するか、安全なWebSocketを使用するかによって異なります。この新しい属性は、セクション3で定義された構文に従う必要があります。このセクションの手順は、トランスポートとしてWebSocketまたはセキュアWebSocketを使用するメディアストリームに関連付けられた「m =」行に適用されます。
Both offerer or answerer can initiate a WebSocket connection. It is expected that, based on the topology (for example, if the client is behind NAT and server is on global IP address), the offerer and answerer applications decide on who will initiate the WebSocket connection and appropriately set the "setup" attribute in SDP following the procedures of [RFC4145].
提供者と回答者の両方がWebSocket接続を開始できます。トポロジに基づいて（たとえば、クライアントがNATの背後にあり、サーバーがグローバルIPアドレス上にある場合）、オファー側アプリケーションと応答側アプリケーションは、誰がWebSocket接続を開始するかを決定し、「セットアップ」属性を適切に設定することが予想されます。 [RFC4145]の手順に従うSDP。
In order to negotiate WebSocket as a transport, an SDP offerer MUST indicate that it wishes to use it in the "proto" field of the "m=" line. For example, to negotiate BFCP-over-WebSocket, the "proto" value in the "m=" line is TCP/WSS/BFCP if WebSocket is over TLS; else, it is TCP/WS/BFCP, as specified in [BFCP-WEBSOCKET].
トランスポートとしてWebSocketをネゴシエートするために、SDP提供者は、それを「m =」行の「proto」フィールドで使用したいことを示さなければなりません（MUST）。たとえば、BFCP-over-WebSocketをネゴシエートするには、WebSocketがTLSを介している場合、「m =」行の「proto」値はTCP / WSS / BFCPです。それ以外の場合は、[BFCP-WEBSOCKET]で指定されているTCP / WS / BFCPです。
The offerer SHOULD assign the SDP "setup" attribute with a value of "active" (the offerer will be the initiator of the outgoing TCP connection) or "passive" if the offerer wishes to be a receiver of an incoming connection. The offerer MUST NOT assign an SDP "setup" attribute with a "holdconn" value. The offerer MUST follow the procedures described in [RFC4145] while using the "setup" attribute. If the "setup" attribute has a value of "passive", it MUST have a URI in the "a=websocket-uri" attribute.
オファー側は、SDPの「セットアップ」属性に「アクティブ」（オファー側は発信TCP接続のイニシエーターになります）、またはオファー側が着信接続のレシーバーになりたい場合は「パッシブ」の値を割り当てる必要があります（SHOULD）。提案者は、「holdconn」値を使用してSDPの「セットアップ」属性を割り当ててはなりません（MUST NOT）。提案者は、「セットアップ」属性を使用している間、[RFC4145]で説明されている手順に従う必要があります。 「setup」属性の値が「passive」である場合、「a = websocket-uri」属性にURIが含まれている必要があります。
The following is an example of an "m=" line for a BFCP connection:
以下は、BFCP接続の「m =」行の例です。
Offer (browser):
m=application 9 TCP/WSS/BFCP *
a=setup:active
a=connection:new
a=floorctrl:c-only
m=audio 55000 RTP/AVP 0
m=video 55002 RTP/AVP 31
In the above example, the client is intending to set up the TLS/TCP connection; hence, the port is set to a value of 9, which is the discard port.
上記の例では、クライアントはTLS / TCP接続をセットアップしようとしています。したがって、ポートは値9に設定されます。これは廃棄ポートです。
If the answerer accepts the offered WebSocket transport connection, in the associated SDP answer, the answerer MUST assign an SDP "setup" attribute with a value of either "active" or "passive", according to the procedures in [RFC4145]. The answerer MUST NOT assign an SDP "setup" attribute with a value of "holdconn".
回答者が提供されたWebSocketトランスポート接続を受け入れる場合、関連するSDP回答で、[RFC4145]の手順に従って、回答者は「アクティブ」または「パッシブ」のいずれかの値でSDP「セットアップ」属性を割り当てる必要があります。回答者は、 "holdconn"の値を持つSDP "setup"属性を割り当ててはなりません（MUST NOT）。
If the answerer assigns an SDP "setup" attribute with a value of "active", the answerer MUST initiate the WebSocket connection handshake by acting as client on the negotiated media stream, towards the URI specified in the "a=websocket-uri" SDP attribute using the procedures described in Section 4 of [RFC6455].
応答側が「アクティブ」の値を持つSDP「セットアップ」属性を割り当てる場合、応答側は、「a = websocket-uri」SDPで指定されたURIに対して、ネゴシエートされたメディアストリームでクライアントとして機能することにより、WebSocket接続のハンドシェイクを開始する必要があります。 [RFC6455]のセクション4で説明されている手順を使用して属性を設定します。
If the answerer assigns an SDP "setup" attribute with a value of "passive", then it MUST have a value of "ws-URI" or "wss-URI", as defined in Section 3 of [RFC6455] in an "a=websocket-uri" SDP attribute, depending on whether the application uses WebSocket or secure WebSocket. This attribute MUST follow the syntax defined in Section 3.
[RFC6455]のセクション3で定義されているように、回答者が「パッシブ」の値でSDPの「セットアップ」属性を割り当てる場合は、「ws-URI」または「wss-URI」の値が必要です。 = websocket-uri "SDP属性。アプリケーションがWebSocketとセキュアWebSocketのどちらを使用するかによって異なります。この属性は、セクション3で定義された構文に従う必要があります。
The following example shows a case where the server responds with a BFCP media stream over a WebSocket connection running TLS. It shows an answer "m=" line for the BFCP connection. In this example, since WebSocket is running over TLS, the server answers back with an "a=websocket-uri" attribute in the media section of SDP having a "wss-URI" connection URI:
次の例は、サーバーがTLSを実行しているWebSocket接続を介してBFCPメディアストリームで応答する場合を示しています。これは、BFCP接続の応答「m =」行を示しています。この例では、WebSocketがTLSで実行されているため、サーバーは「wss-URI」接続URIを持つSDPのメディアセクションの「a = websocket-uri」属性で応答します。
Answer (server):
m=application 50000 TCP/WSS/BFCP *
a=setup:passive
a=connection:new
a=websocket-uri:wss://bfcp-ws.example.com?token=3170449312
a=floorctrl:s-only
a=confid:4321
a=userid:1234
a=floorid:1 m-stream:10
a=floorid:2 m-stream:11
m=audio 50002 RTP/AVP 0
a=label:10
m=video 50004 RTP/AVP 31
a=label:11
When the offerer receives an SDP answer, if the offerer ends up initiating the TCP connection, then it MUST follow the procedures in Section 5.
提案者がSDP回答を受信したときに、提案者が最終的にTCP接続を開始する場合、セクション5の手順に従う必要があります。
Once an offer/answer exchange has been completed, either endpoint MAY send a new offer in order to modify the session. The endpoints can reuse the existing WebSocket connection by adding an "a=connection:existing" attribute in the media section of the SDP following the rules mentioned in [RFC4145], if the "websocket-uri" SDP value and the transport parameters indicated by each endpoint are unchanged. Otherwise, following the rules for the initial offer/ answer exchange, the endpoints can negotiate and create a new WebSocket connection on top of TLS/TCP or TCP.
オファー/アンサーの交換が完了すると、どちらかのエンドポイントがセッションを変更するために新しいオファーを送信する場合があります。エンドポイントは、[websocket-uri] SDP値とトランスポートパラメータが次のように指定されている場合、[RFC4145]で述べられているルールに従ってSDPのメディアセクションに「a = connection：existing」属性を追加することにより、既存のWebSocket接続を再利用できます。各エンドポイントは変更されません。それ以外の場合、最初のオファー/アンサー交換のルールに従って、エンドポイントはTLS / TCPまたはTCPの上に新しいWebSocket接続をネゴシエートおよび作成できます。
In some scenarios, an endpoint (e.g., a browser) originating the call (a User Agent Client or UAC) can send an offerless INVITE to the server. The server will generate an offer in response to the INVITE. In such cases, the server MUST send an offer with the "setup" attribute with a value of "passive" so as to accept incoming connection and MUST include an "a=websocket-uri" attribute in the media section whose value MUST be either "ws-URI" or "wss-URI", depending on whether the server wishes to use WebSocket or secure WebSocket. The SDP offer sent by the server will look like the example in Section 4.3.
一部のシナリオでは、コールを発信するエンドポイント（ブラウザなど）（ユーザーエージェントクライアントまたはUAC）がオファーのないINVITEをサーバーに送信できます。サーバーは、INVITEに応答してオファーを生成します。そのような場合、サーバーは、着信接続を受け入れるために、値が「パッシブ」の「セットアップ」属性を含むオファーを送信する必要があり、メディアセクションに「a = websocket-uri」属性を含める必要があります。 「ws-URI」または「wss-URI」。サーバーがWebSocketまたはセキュアWebSocketのどちらを使用するかによって異なります。サーバーから送信されるSDPオファーは、セクション4.3の例のようになります。
The WebSocket client MUST always initiate the outgoing TCP connection; hence, the SDP "setup" attribute MUST always be "active" for the WebSocket client in its SDP offer/answer. In the example below, the WebSocket client is the offerer; hence, it assigns a "setup" attribute with a value of "active".
WebSocketクライアントは常に発信TCP接続を開始する必要があります。したがって、SDPの「セットアップ」属性は、SDPオファー/アンサーでWebSocketクライアントに対して常に「アクティブ」である必要があります。以下の例では、WebSocketクライアントが提供者です。したがって、「アクティブ」の値を持つ「セットアップ」属性を割り当てます。
The WebSocket server is a server on the Internet; hence, it MUST always assign an SDP "setup" attribute with a value of "passive". This also avoids the need to use Interactive Connectivity Establishment (ICE) between WebSocket client and WebSocket server, as the connection model here would be a typical client-to-server web connection.
WebSocketサーバーはインターネット上のサーバーです。したがって、常に「パッシブ」の値を持つSDP「セットアップ」属性を割り当てる必要があります。これにより、ここでの接続モデルは典型的なクライアントからサーバーへのWeb接続であるため、WebSocketクライアントとWebSocketサーバーの間でInteractive Connectivity Establishment（ICE）を使用する必要がなくなります。
Once the offer/answer is complete, the client MUST initiate the WebSocket connection handshake by sending a GET message on the negotiated media stream, towards the URI specified in an "a=websocket-uri" attribute, as per the procedures described in [RFC6455]. When no port is passed in the "a=websocket-uri" attribute, the default port (80 or 443) is used depending on whether the value was "ws-URI" or "wss-URI".
オファー/アンサーが完了すると、クライアントは、[RFC6455]で説明されている手順に従って、「a = websocket-uri」属性で指定されたURIに向けて、ネゴシエートされたメディアストリームでGETメッセージを送信することにより、WebSocket接続ハンドシェイクを開始する必要があります。 ]。 「a = websocket-uri」属性でポートが渡されない場合、値が「ws-URI」または「wss-URI」のどちらであったかに応じて、デフォルトのポート（80または443）が使用されます。
An attacker may attempt to add, modify, or remove an "a=websocket-uri" attribute from a session description. This could result in an application behaving undesirably. Consequently, it is RECOMMENDED that integrity protection be applied to the SDP session descriptions. For session descriptions carried in SIP [RFC3261], S/MIME is available to provide such end-to-end integrity protection.
攻撃者は、セッションの説明から「a = websocket-uri」属性を追加、変更、または削除しようとする可能性があります。これにより、アプリケーションが望ましくない動作をする可能性があります。したがって、SDPセッション記述に整合性保護を適用することをお勧めします。 SIP [RFC3261]で実行されるセッション記述の場合、S / MIMEを使用して、このようなエンドツーエンドの整合性保護を提供できます。
As described in Section 10 of [RFC6455], application signalling traffic being transported over WebSocket MUST support secure WebSocket and SHOULD employ it when communicating with their peers.
[RFC6455]のセクション10で説明されているように、WebSocketを介して転送されるアプリケーションシグナリングトラフィックはセキュアなWebSocketをサポートする必要があり、ピアと通信するときにそれを使用する必要があります。
The WebSocket clients have to initiate the TCP connection to the WebSocket server identified by the Fully Qualified Domain Name (FQDN) in an "a=websocket-uri" attribute. Further, as with any other web connection, the clients will verify the server's certificate. The WebSocket client MUST follow the procedures in [RFC7525] (including host name verification as per Section 6.1 in [RFC7525]) while setting up a TLS connection with a WebSocket server.
WebSocketクライアントは、「a = websocket-uri」属性の完全修飾ドメイン名（FQDN）で識別されるWebSocketサーバーへのTCP接続を開始する必要があります。さらに、他のWeb接続と同様に、クライアントはサーバーの証明書を検証します。 WebSocketクライアントは、WebSocketサーバーとのTLS接続をセットアップする間、[RFC7525]の手順（[RFC7525]のセクション6.1に基づくホスト名検証を含む）に従う必要があります。
This document defines a new SDP media-level attribute "websocket-uri" in Section 3.2; IANA has registered the following SDP att-field under the "Session Description Protocol (SDP) Parameters" registry as follows:
このドキュメントでは、セクション3.2で新しいSDPメディアレベル属性「websocket-uri」を定義しています。 IANAは、「Session Description Protocol（SDP）Parameters」レジストリの下に次のSDP att-fieldを次のように登録しています。
+---------------------+---------------------------------------------+
| Attribute name: | websocket-uri |
| Long-form attribute | WebSocket Connection URI |
| name: | |
| Type of attribute: | media |
| Mux category: | CAUTION |
| Charset Dependent: | No |
| Purpose: | The "websocket-uri" attribute is intended |
| | to be used as a connection URI for opening |
| | the WebSocket connection. |
| Appropriate values: | A ws-URI or wss-URI, as defined in Section |
| | 3 of [RFC6455] |
| Contact name: | Gonzalo Salgueiro |
| Contact email: | gsalguei@cisco.com |
| Reference: | RFC 8124 |
+---------------------+---------------------------------------------+
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in the Session Description Protocol (SDP)", RFC 4145, DOI 10.17487/RFC4145, September 2005, <http://www.rfc-editor.org/info/rfc4145>.
[RFC4145] Yon、D。、およびG. Camarillo、「セッション記述プロトコル（SDP）におけるTCPベースのメディアトランスポート」、RFC 4145、DOI 10.17487 / RFC4145、2005年9月、<http：//www.rfc-editor。 org / info / rfc4145>。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <http://www.rfc-editor.org/info/rfc6455>.
[RFC6455] Fette、I。およびA. Melnikov、「The WebSocket Protocol」、RFC 6455、DOI 10.17487 / RFC6455、2011年12月、<http://www.rfc-editor.org/info/rfc6455>。
[BFCP] Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. Eckel, "The Binary Floor Control Protocol (BFCP)", Work in Progress, draft-ietf-bfcpbis-rfc4582bis-16, November 2015.
[BFCP] Camarillo、G.、Drage、K.、Kristensen、T.、Ott、J。、およびC. Eckel、「The Binary Floor Control Protocol（BFCP）」、Work in Progress、draft-ietf-bfcpbis-rfc4582bis 2015年11月16日。
[BFCP-WEBSOCKET] Pascual, V., Roman, A., Cazeaux, S., Salgueiro, G., and R. R, "The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)", Work in Progress, draft-ietf-bfcpbis-bfcp-websocket-15, February 2017.
[BFCP-WEBSOCKET] Pascual、V.、Roman、A.、Cazeaux、S.、Salgueiro、G。、およびR.R、「バイナリフロアコントロールプロトコル（BFCP）のトランスポートとしてのWebSocketプロトコル」、進捗、draft-ietf-bfcpbis-bfcp-websocket-15、2017年2月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、DOI 10.17487 / RFC3261、2002年6月、<http://www.rfc-editor.org/info/rfc3261>。
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002, <http://www.rfc-editor.org/info/rfc3264>.
[RFC3264] Rosenberg、J。およびH. Schulzrinne、「セッション記述プロトコル（SDP）を備えたオファー/アンサーモデル」、RFC 3264、DOI 10.17487 / RFC3264、2002年6月、<http://www.rfc-editor.org / info / rfc3264>。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、DOI 10.17487 / RFC4566、2006年7月、<http://www.rfc-editor.org/ info / rfc4566>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info / rfc5246>。
[RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual, "The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)", RFC 7118, DOI 10.17487/RFC7118, January 2014, <http://www.rfc-editor.org/info/rfc7118>.
[RFC7118] Baz Castillo、I.、Millan Villegas、J。、およびV. Pascual、「Session Initiation Protocol（SIP）のトランスポートとしてのWebSocketプロトコル」、RFC 7118、DOI 10.17487 / RFC7118、2014年1月、<http ：//www.rfc-editor.org/info/rfc7118>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<http://www.rfc-editor.org/info/ rfc7230>。
[RFC7395] Stout, L., Ed., Moffitt, J., and E. Cestari, "An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket", RFC 7395, DOI 10.17487/RFC7395, October 2014, <http://www.rfc-editor.org/info/rfc7395>.
[RFC7395] Stout、L.、Ed。、Moffitt、J。、およびE. Cestari、「Extensible Messaging and Presence Protocol（XMPP）Subprotocol for WebSocket」、RFC 7395、DOI 10.17487 / RFC7395、2014年10月、<http： //www.rfc-editor.org/info/rfc7395>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<http://www.rfc-editor.org/info/rfc7525>。
[RFC7977] Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., and R. Ravindranath, "The WebSocket Protocol as a Transport for the Message Session Relay Protocol (MSRP)", RFC 7977, DOI 10.17487/RFC7977, September 2016, <http://www.rfc-editor.org/info/rfc7977>.
[RFC7977] Dunkley、P.、Llewellyn、G.、Pascual、V.、Salgueiro、G。、およびR. Ravindranath、「メッセージソケットリレープロトコル（MSRP）のトランスポートとしてのWebSocketプロトコル」、RFC 7977、DOI 10.17487 / RFC7977、2016年9月、<http://www.rfc-editor.org/info/rfc7977>。
[SDP-MUX] Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", Work in Progress, draft-ietf-mmusic-sdp-mux-attributes-16, December 2016.
[SDP-MUX] Nandakumar、S。、「多重化時のSDP属性のフレームワーク」、作業中、draft-ietf-mmusic-sdp-mux-attributes-16、2016年12月。
[WS-API] Hickson, I., Ed., "The WebSocket API", W3C Candidate Recommendation, September 2012, <https://www.w3.org/TR/2012/CR-websockets-20120920/>.
[WS-API] Hickson、I.、Ed。、 "The WebSocket API"、W3C Candidate Recommendation、September 2012、<https://www.w3.org/TR/2012/CR-websockets-20120920/>。
Acknowledgements
謝辞
Thanks to Christer Holmberg for raising the need for a BFCP-independent SDP attribute for WebSocket Connection URI.
WebSocket接続URIのBFCPに依存しないSDP属性の必要性を提起してくれたChrister Holmbergに感謝します。
The authors wish to acknowledge Paul Kyzivat, Suhas Nandakumar, Christer Holmberg, Charles Eckel, Dan Wing, Alissa Cooper, and Joel Halpern for their invaluable suggestions and review comments.
著者は、Paul Kyzivat、Suhas Nandakumar、Christer Holmberg、Charles Eckel、Dan Wing、Alissa Cooper、およびJoel Halpernの貴重な提案とレビューコメントに感謝します。
Thanks to Mirja Kuehlewind, Alexey Melnikov, Ben Campbell, and Kathleen Moriarty for their comments and feedback during IESG reviews.
IESGレビューでのコメントとフィードバックについて、Mirja Kuehlewind、Alexey Melnikov、Ben Campbell、Kathleen Moriartyに感謝します。
Authors' Addresses
著者のアドレス
Ram Mohan Ravindranath Cisco Systems, Inc. Cessna Business Park, Kadabeesanahalli Village, Varthur Hobli, Sarjapur-Marathahalli Outer Ring Road Bangalore, Karnataka 560103 India
Ram Mohan Ravindranath Cisco Systems、Inc. Cessna Business Park、Kadabeesanahalli Village、Varthur Hobli、Sarjapur-Marathahalli Outer Ring Road Bangalore、Karnatakaインド
Email: rmohanr@cisco.com
Gonzalo Salgueiro Cisco Systems, Inc. 7200-12 Kit Creek Road Research Triangle Park, NC 27709 United States of America
Gonzalo Salgueiro Cisco Systems、Inc. 7200-12 Kit Creek Road Research Triangle Park、NC 27709アメリカ合衆国
Email: gsalguei@cisco.com