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
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)
WebSocket协议作为会话启动协议（SIP）的传输
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的应用程序中客户端和服务器之间的双向实时通信。本文档将WebSocket子策略指定为会话启动协议（SIP）实体之间的可靠传输机制，以支持在面向web的部署中使用SIP。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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）的产品。它代表了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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
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)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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
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浏览器包括一个WebSocket客户端堆栈，它符合W3C指定的WebSocket API[WS-API]。预计其他客户端应用程序（在个人计算机和智能手机等设备上运行的应用程序）也将提供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服务器传输必须在top Via报头中添加“received”参数。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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服务器：一个SIP实体，能够监听来自WebSocket客户端的入站连接，并使用本文档定义的WebSocket 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
WebSocket协议[RFC6455]是TCP（可选地使用TLS[RFC5246]进行保护）之上的传输层，其中客户端和服务器在两个方向上交换消息单元。协议
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子策略和扩展协商、用于发送应用程序和控制数据的帧格式、屏蔽机制以及用于指示断开原因的状态代码。
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 Subtocol是指分层在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
SIP WebSocket客户端和SIP WebSocket服务器在[RFC6455]第1.3节中定义的WebSocket握手过程中协商WebSocket SIP子策略的使用。客户必须
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.
在其握手请求中包含Sec WebSocket协议头中的值“sip”。来自服务器的101应答必须在其相应的Sec WebSocket协议头中包含“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握手示例，其中客户端从服务器请求WebSocket SIP子策略支持：
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
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
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请求和响应以外的消息不得通过此连接传输。
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请求和响应中的文本和二进制体。因此，SIPWebSocket客户端和SIPWebSocket服务器必须同时接受文本和二进制帧。
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
如果整个SIP消息（包括头和正文）中至少有一个非UTF-8符号，则整个消息必须在WebSocket二进制消息中发送。鉴于
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.
在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]是一个可靠的协议；因此，本文档定义的SIPWebSocket子目录是可靠的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消息中，并且WebSocket消息不能包含多个SIP消息。由于WebSocket传输保留消息边界，因此在使用WebSocket子目录传输SIP消息时，不需要在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消息解析。不需要使用消息之间的内容长度头来建立消息边界。其他SIP传输，如UDP和流控制传输协议（SCTP）[RFC4168]，也提供了这一优势。
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消息中的Via头字段带有传输协议标识符。本文档定义了用于通过普通WebSocket连接的请求的值“WS”，以及用于通过安全WebSocket连接的请求的值“WSS”（其中WebSocket连接是使用TLS[RFC5246]和TCP传输建立的）。
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"
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 URI[RFC3986]的传输参数值，该SIP URI[RFC3986]将使用SIP WebSocket子目录作为传输进行联系。
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"
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”参数的值。如果“发送人”字段的主机部分包含域名，或者如果它包含与数据包源地址不同的IP地址，则服务器必须通过报头字段值向其添加“已接收”参数。此参数必须包含从中接收数据包的源地址。
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连接握手重用现有HTTP基础结构，其中SIP WebSocket客户端和服务器之间可能存在未知数量的HTTP代理和/或TCP负载平衡器，因此服务器将写入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服务器接收到请求时，它可能会决定不将“received”参数添加到顶部Via头。因此，无论Via“sent by”字段是否包含域名，SIP WebSocket客户端都必须接受顶部Via头中没有此类参数的响应。
The following is stated in [RFC3261], Section 18, "Transport":
[RFC3261]第18节“运输”中规定了以下内容：
All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols.
所有SIP元素都必须实现UDP和TCP。SIP元素可以实现其他协议。
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
此传输的规范使SIP能够在无法使用为SIP定义的任何其他传输协议的情况下用作会话建立协议。因为
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元素将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).
在编写本文档时，常见的WebSocket客户端堆栈（在JavaScript引擎和web浏览器中）无法执行DNS NAPTR/服务记录（SRV）查询。
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”方案和“ws”传输参数的SIP URI的默认端口为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.
SIP WebSocket客户端和服务器可通过发送[RFC6455]第5.5.2节所述的定期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服务器可以使用通用HTTP服务器可用的任何客户端身份验证机制，如cookie、HTTP身份验证或TLS身份验证。
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:
以下列表公开了SIP WebSocket客户端和服务器的强制实现和可选机制，以便在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浏览器中运行（或其行为类似于浏览网站的浏览器）并且之前已从其URL域与WebSocket URI中的域匹配的web服务器检索到会话cookie时，它必须准备好添加会话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 在执行WebSocket握手时，SIP 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连接中时）作为可选的身份验证机制。
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客户端身份验证由HTTP协议的规则而不是SIP的规则控制。
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 当WebSocket握手请求中存在会话cookie时，SIP WebSocket服务器必须准备好读取会话cookie，并使用此类cookie值来确定WebSocket连接是否由在与SIP WebSocket服务器相同的域（或子域）中导航网站的HTTP客户端启动。
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协议定义的基本/摘要质询来拒绝带有HTTP 401状态码的WebSocket握手请求。
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 (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).
Alice使用她的web浏览器加载网页，并检索实现本文档中定义的WebSocket SIP子脚本的JavaScript代码。JavaScript代码（SIP WebSocket客户端）在proxy.example.com上与SIP代理/注册器（SIP WebSocket服务器）建立安全的WebSocket连接。在WebSocket连接时，Alice构造并发送SIP注册请求，包括出站[RFC5626]和全局可路由用户代理URI（GRUU）[RFC5627]支持。由于浏览器中的JavaScript堆栈无法确定进行WebSocket连接的本地地址，因此此实现为Via标头“sent by”参数和Contact标头中URI的主机端口使用随机“.invalid”域名（见附录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握手）Alice->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
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)
F2 101交换协议proxy.example.com->Alice（TLS）
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: sip
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注册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>"
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
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 |
| |---------------------------->|
| | |
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.
在相同的场景中，Alice调用Bob的记录地址（AOR）。proxy.example.com上的SIP WebSocket服务器充当SIP代理，将邀请路由到Bob的联系人地址（该地址恰好使用通过UDP传输的SIP）。鲍勃接了电话，然后终止了通话。
Message details (authentication and SDP bodies are omitted for simplicity):
消息详细信息（为简单起见，省略了身份验证和SDP正文）：
F1 INVITE Alice -> proxy.example.com (transport WSS)
F1邀请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
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正在尝试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
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
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)
F4 200 OK Bob->proxy.example.com（传输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
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
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确认Alice->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
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)
F7 ACK proxy.example.com->Bob（传输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
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再见Bob->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
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拜拜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
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 Alice->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
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)
F11 200 OK proxy.example.com->Bob（传输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
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域证书的过程。适用于TCP上的TLS上的SIP的证书可能不适用于安全WebSocket上的SIP连接。
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.
SIPURI中的“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的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:
本文档定义了两个新的NAPTR服务字段值（SIP+D2W和SIPS+D2W），IANA已在“会话启动协议（SIP）NAPTR资源记录服务字段注册表”下注册了这些值。参赛作品如下：
Services Field Protocol Reference
-------------- -------- ---------
SIP+D2W WS [RFC7118]
SIPS+D2W WS [RFC7118]
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已在“会话启动协议（SIP）参数”注册表中的“SIP/SIPS URI参数”子区添加了对本文件的引用：
Parameter Name Predefined Values Reference
-------------- ----------------- ---------
transport Yes [RFC3261][RFC7118]
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在“会话启动协议（SIP）参数”注册表中的“标题字段”子区域下添加了对本文件的引用：
Header Name compact Reference
----------- ------- ---------
Via v [RFC3261][RFC7118]
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在“会话启动协议（SIP）参数”注册表中的“标题字段参数和参数值”子区域下添加了对本文件的引用：
Predefined
Header Field Parameter Name Values Reference
------------ -------------- ------ ---------
Via received No [RFC3261][RFC7118]
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:
本文档在“会话启动协议（SIP）参数”注册表中添加了一个新的子区域“SIP传输”。其格式和初始值如下表所示：
+------------+------------------------+
| Transport | Reference |
+------------+------------------------+
| UDP | [RFC3261] |
| TCP | [RFC3261] |
| TLS | [RFC3261] |
| SCTP | [RFC3261], [RFC4168] |
| TLS-SCTP | [RFC4168] |
| WS | [RFC7118] |
| WSS | [RFC7118] |
+------------+------------------------+
+------------+------------------------+
| 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工作组邮件列表讨论并提供想法和/或详细评论（列表可能不完整）的人员：Hadriel Kaplan、Paul Kyzivat、Robert Sparks、Adam Roach、Ranjit Avasarala、Xavier Marjou、Nataraju A.B.Martin Vopatek、Alexey Melnikov、，艾伦·约翰斯顿、克里斯特·霍姆伯格、萨尔瓦托·洛雷托、凯文·P·弗莱明、苏雷什·克里希南、亚龙·谢弗、理查德·巴恩斯、巴里·莱巴、斯蒂芬·法雷尔、特德·莱蒙、贝诺特·克莱斯、皮特·雷斯尼克、比诺德·P.G.和索尔·伊巴拉·科雷奇。
[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.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年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，“会话启动协议（SIP）：定位SIP服务器”，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.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC34032002年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，“在RFCs中编写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，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011.
[RFC6265]Barth，A.，“HTTP状态管理机制”，RFC6265，2011年4月。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, December 2011.
[RFC6455]Fette，I.和A.Melnikov，“WebSocket协议”，RFC 64552011年12月。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999.
[RFC2606]Eastlake，D.和A.Panitz，“保留顶级DNS名称”，BCP 32，RFC 26061999年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]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——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，“统一资源标识符（URI）：通用语法”，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，“在会话启动协议（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.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理URI（GRUUs）”，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，“会话启动协议（SIP）中的域证书”，RFC 59222010年6月。
[RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", RFC 6223, April 2011.
[RFC6223]Holmberg，C.，“维持生命支持的指示”，RFC 62232011年4月。
[WS-API] W3C and I. Hickson, Ed., "The WebSocket API", September 2012.
[WS-API]W3C和I.Hickson主编，“WebSocket API”，2012年9月。
The sections below briefly describe some SIP over WebSocket scenarios in which authentication takes place in different ways.
以下各节简要描述了一些通过WebSocket的SIP场景，在这些场景中，身份验证以不同的方式进行。
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专用分支交换（PBX）模型A实现本规范定义的SIP WebSocket传输。它的实现完全不依赖于网站，因为它不与向浏览器提供HTML代码的web服务器共享信息，这意味着SIP WebSocket服务器（此处为PBX型号A）不了解网站内的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).
在这个简单的场景中，SIPWebSocket服务器不检查WebSocket握手HTTP GET请求中的字段，例如请求URL、源标头值、主机标头值或Cookie标头值（如果存在）。但是，可以检查其中一些字段以进行最低限度的验证（即，PBX型号a可能要求源标题值包含特定的URL，这样只有浏览此类网站的用户才能与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连接，PBX模型A将为通过该连接的每个SIP请求请求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到PSTN（公共交换电话网）提供商为登录其网站的客户提供电话服务。出于安全/隐私原因，提供商不希望将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标识（SIP URI）和会话临时令牌字符串（以及SIP WebSocket客户端JavaScript应用程序和SIP设置）。web服务器将SIP标识和会话令牌存储到数据库中。
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
web应用程序在WebSocket握手请求中添加SIP标识和会话令牌作为URL查询参数，并尝试连接。SIPWebSocket服务器检查握手请求并验证会话令牌是否与数据库中存储的给定SIP标识的值匹配。如果值匹配，WebSocket连接将获得该SIP标识的“身份验证”。然后SIPWebSocket客户端可以注册并进行调用。啜饮
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).
然而，WebSocket服务器将验证这些SIP请求中的标识（即From URI值）是否与WebSocket连接关联的SIP标识匹配（否则，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标识和会话令牌元组，并通知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应用程序尝试针对网站的同一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标识相关联，该标识必须由通过该连接的每个SIP请求来满足。
No SIP authentication takes place in this scenario but just common cookie usage as widely deployed in the World Wide Web.
在这种情况下不会进行SIP身份验证，只会使用在万维网中广泛部署的常见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.
让我们假设一个场景，其中用户使用其web浏览器（可能在NAT后面）访问intranet上服务器提供的应用程序，通过输入用户标识符和凭据登录，并检索实现SIP WebSocket客户端的JavaScript应用程序（以及HTML）。
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堆栈连接到给定的SIPWebSocket服务器（一个出站SIP代理，也实现了UDP和TCP等经典SIP传输）。web浏览器为WebSocket握手发送的HTTP GET方法请求包括一个Cookie[RFC6265]头，该头的值在成功登录过程后由服务器先前提供。然后WebSocket服务器检查cookie值以授权连接。一旦建立了WebSocket连接，SIP WebSocket客户端将向SIP注册服务器执行SIP注册，该服务器可通过代理访问。注册后，SIPWebSocket客户端和服务器会像通常预期的那样交换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用户代理（UAs）连接到代理的场景非常相似，并且必须为传入请求重用相同的TCP连接（因为代理无法直接访问这些请求）。在这两种情况下，SIP UAs只能通过其所连接的代理进行访问。
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.
如果参考请求被发送到第三SIP用户代理，包括sipwebsocket客户端的联系人URI作为其参考头字段中的目标，则仅当第三SIP UA是全局可路由URI时，该URI才可由第三SIP UA访问。GRUU（全局可路由用户代理URI）是这些场景的解决方案，它将导致来自第三个SIP用户代理的传入请求发送到SIP注册器，SIP注册器将通过出站边缘代理将请求路由到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客户端可以构造一个域名，该域名由随机令牌和“.invalid”顶级域名组成，如[RFC2606]中所述，并在其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 UAs提供的联系人URI不用于将请求路由到这些UAs，因此在联系人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.
出站规范和GRUU规范都要求SIP UA在联系人标头的“+SIP.instance”参数中包含统一资源名（URN），其中包括SIP注册请求。客户端设备负责为此目的生成或收集适当的值。
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值的合适值。此场景表明，在浏览器中运行的web应用程序第一次加载JavaScript SIP堆栈代码时，根据[RFC5626]第4.1节生成值，然后将其存储为浏览器中的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 WebSocket服务器来发送和接收SIP消息。
Authors' Addresses
作者地址
Inaki Baz Castillo Versatica Barakaldo, Basque Country Spain
西班牙巴斯克地区的伊纳基·巴兹·卡斯蒂略·范思蒂卡·巴拉卡多（Inaki Baz Castillo Versatica Barakaldo）
EMail: ibc@aliax.net
EMail: ibc@aliax.net
Jose Luis Millan Villegas Versatica Bilbao, Basque Country Spain
何塞·路易斯·米兰·维莱加斯·范思蒂卡·毕尔巴鄂，巴斯克国家西班牙
EMail: jmillan@aliax.net
EMail: jmillan@aliax.net
Victor Pascual Quobis Spain
维克多·帕斯夸尔·库比斯西班牙
EMail: victor.pascual@quobis.com
EMail: victor.pascual@quobis.com