The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP)
Extracted elements (26)
The RFC 3261 requirement to add a "received" parameter to the top Via header is relaxed for WebSocket because HTTP proxies and TCP load balancers may sit between client and server, making the recorded source address that of an intermediary rather than the client—potentially revealing sensitive internal topology information.
The SIP Outbound extension (RFC 5626) and GRUU (RFC 5627) are recommended for WebSocket SIP deployments because WebSocket clients behind NAT are only reachable through the proxy to which they are connected, making them analogous to SIP UAs that must reuse a TCP connection for incoming requests.
UTF-8 encoding is RECOMMENDED for SIP messages over WebSocket because JavaScript and the WebSocket API are natively oriented toward text; the entire SIP message (including headers and body) must be sent as a binary frame if any non-UTF-8 byte is present.
At the time of writing, DNS NAPTR/SRV queries could not be performed by commonly available WebSocket client stacks (JavaScript engines and web browsers), making direct connection using default ports the practical deployment approach.
Because the WebSocket transport preserves message boundaries, the Content-Length header in SIP messages is not necessary when transported using the WebSocket subprotocol, simplifying parsing for both clients and servers.
SIP WebSocket Clients running in web browsers, which cannot discover the local transport address used for WebSocket connections, SHOULD use a random token followed by the ".invalid" top-level domain for Via and Contact header "sent-by" and hostport values.
A SIP element acting as a SIP WebSocket Client is not mandated to implement UDP and TCP, relaxing the RFC 3261 requirement, because some environments do not enable SIP elements to use UDP and TCP as transport protocols.
A SIP WebSocket Client MUST be ready to be challenged with an HTTP 401 status code (RFC 2617) by the SIP WebSocket Server when performing the WebSocket handshake.
A SIP WebSocket Server MUST be ready to read session cookies when present in the WebSocket handshake request and use the cookie value to determine whether the connection was initiated by an HTTP client navigating a website in the same domain.
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 HTTP.
Client and server transactions using WebSocket for transport MUST follow the procedures and timer values for reliable transports as defined in RFC 3261, since WebSocket is a reliable protocol.
Each SIP message MUST be carried within a single WebSocket message, and a WebSocket message MUST NOT contain more than one SIP message.
Messages other than SIP requests and responses MUST NOT be transmitted over a WebSocket connection using the SIP subprotocol.
SIP WebSocket Clients and SIP WebSocket Servers MUST accept both text and binary WebSocket frames. If there is at least one non-UTF-8 symbol in the SIP message, the whole message MUST be sent within a WebSocket binary message.
The SIP WebSocket Client MUST include the value "sip" in the Sec-WebSocket-Protocol header in its handshake request, and the 101 reply from the server MUST contain "sip" in its corresponding Sec-WebSocket-Protocol header.
When a SIP WebSocket Server receives a request, it MAY decide not to add a "received" parameter to the top Via header. 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.
Default port for a SIP URI using the "sip" scheme and "ws" transport parameter is 80; default port for the "sips" scheme with "ws" transport parameter is 443.
NAPTR service values "SIP+D2W" and "SIPS+D2W" are defined for locating SIP WebSocket Servers supporting plain and secure WebSocket connections, respectively, per RFC 3263 procedures.
The SIP URI transport parameter value "ws" is defined for contacting a SIP entity using the WebSocket SIP subprotocol. The augmented BNF extension is: transport-param =/ "transport=" "ws".
The Via transport parameter values "WS" and "WSS" are defined for SIP requests over plain and secure WebSocket connections, respectively. The augmented BNF extension is: transport =/ "WS" / "WSS".
IANA created a new "SIP Transport" subregistry within the "Session Initiation Protocol (SIP) Parameters" registry, with initial values UDP, TCP, TLS, SCTP, TLS-SCTP, WS, and WSS; policy for new registrations is "Standards Action".
IANA registered the WebSocket SIP subprotocol under the "WebSocket Subprotocol Name" registry with subprotocol identifier "sip", common name "WebSocket Transport for SIP", and definition reference RFC 7118.
IANA registered two new NAPTR service field values "SIP+D2W" (WS protocol) and "SIPS+D2W" (WS protocol) under the "Registry for the Session Initiation Protocol (SIP) NAPTR Resource Record Services Field".
If the "sips" URI scheme is used, dictating that the entire request path to the target be secure, any WebSocket connection in that path MUST be a secure WebSocket connection.
It is RECOMMENDED that SIP traffic over WebSocket be protected using a secure WebSocket connection (TLS over TCP). When establishing a connection using SIP over secure WebSocket, the client MUST authenticate the server using the server's certificate according to the WebSocket validation procedure in RFC 6455.
Server operators should note that TLS certificate authentication for SIP over WebSocket follows WebSocket (RFC 6455) validation procedures, which differ from SIP domain certificate procedures in RFC 5922; certificates valid for SIP over TLS/TCP may not be appropriate for SIP over secure WebSocket.