draft-ietf-sipcore-sip-websocket-09.txt   rfc7118.txt 
SIPCORE Working Group I. Baz Castillo Internet Engineering Task Force (IETF) I. Baz Castillo
Internet-Draft J. Millan Villegas Request for Comments: 7118 J. Millan Villegas
Updates: 3261 (if approved) Versatica Category: Standards Track Versatica
Intended status: Standards Track V. Pascual ISSN: 2070-1721 V. Pascual
Expires: December 15, 2013 Acme Packet Quobis
June 13, 2013 January 2014
The WebSocket Protocol as a Transport for the Session Initiation The WebSocket Protocol as a Transport for the
Protocol (SIP) Session Initiation Protocol (SIP)
draft-ietf-sipcore-sip-websocket-09
Abstract Abstract
The WebSocket protocol enables two-way realtime communication between The WebSocket protocol enables two-way real-time communication
clients and servers in web-based applications. This document between clients and servers in web-based applications. This document
specifies a WebSocket sub-protocol as a reliable transport mechanism specifies a WebSocket subprotocol as a reliable transport mechanism
between SIP (Session Initiation Protocol) entities to enable usage of between Session Initiation Protocol (SIP) entities to enable use of
SIP in web-oriented deployments. This document normatively updates SIP in web-oriented deployments.
RFC 3261.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 15, 2013. 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.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 5 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . 3
4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 5 4. The WebSocket SIP Subprotocol . . . . . . . . . . . . . . . . 4
4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. SIP Encoding . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. SIP Encoding . . . . . . . . . . . . . . . . . . . . . . 5
5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 7 5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 6
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Via Transport Parameter . . . . . . . . . . . . . . . . . 6
5.2. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . 7 5.2. SIP URI Transport Parameter . . . . . . . . . . . . . . . 6
5.2.1. Via Transport Parameter . . . . . . . . . . . . . . . 7 5.3. Via "received" Parameter . . . . . . . . . . . . . . . . 7
5.2.2. SIP URI Transport Parameter . . . . . . . . . . . . . 7 5.4. SIP Transport Implementation Requirements . . . . . . . . 7
5.2.3. Via received Parameter . . . . . . . . . . . . . . . . 8 5.5. Locating a SIP Server . . . . . . . . . . . . . . . . . . 8
5.2.4. SIP Transport Implementation Requirements . . . . . . 8 6. Connection Keep-Alive . . . . . . . . . . . . . . . . . . . . 8
5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 9 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . 8
6. Connection Keep-Alive . . . . . . . . . . . . . . . . . . . . 9 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . 10
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.2. INVITE Dialog through a Proxy . . . . . . . . . . . . . . 12
8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8.2. INVITE Dialog through a Proxy . . . . . . . . . . . . . . 12 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 16
9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9.2. Usage of "sips" Scheme . . . . . . . . . . . . . . . . . 16
9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 17 10.1. Registration of the WebSocket SIP Subprotocol . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10.2. Registration of New NAPTR Service Field Values . . . . . 17
10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 17 10.3. SIP/SIPS URI Parameters Subregistry . . . . . . . . . . 17
10.2. Registration of new NAPTR Service Field Values . . . . . . 17 10.4. Header Fields Subregistry . . . . . . . . . . . . . . . 17
10.3. SIP/SIPS URI Parameters Sub-Registry . . . . . . . . . . . 18 10.5. Header Field Parameters and Parameter Values Subregistry 17
10.4. Header Fields Sub-Registry . . . . . . . . . . . . . . . . 18 10.6. SIP Transport Subregistry . . . . . . . . . . . . . . . 18
10.5. Header Field Parameters and Parameter Values 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.6. SIP Transport Sub-Registry . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix A. Authentication Use Cases . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 A.1. Just SIP Authentication . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . . 20 A.2. Just Web Authentication . . . . . . . . . . . . . . . . . 21
Appendix A. Authentication Use Cases . . . . . . . . . . . . . . 21 A.3. Cookie-Based Authentication . . . . . . . . . . . . . . . 22
A.1. Just SIP Authentication . . . . . . . . . . . . . . . . . 21 Appendix B. Implementation Guidelines . . . . . . . . . . . . . 22
A.2. Just Web Authentication . . . . . . . . . . . . . . . . . 21 B.1. SIP WebSocket Client Considerations . . . . . . . . . . . 23
A.3. Cookie Based Authentication . . . . . . . . . . . . . . . 22 B.2. SIP WebSocket Server Considerations . . . . . . . . . . . 24
Appendix B. Implementation Guidelines . . . . . . . . . . . . . . 23
B.1. SIP WebSocket Client Considerations . . . . . . . . . . . 24
B.2. SIP WebSocket Server Considerations . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
The WebSocket [RFC6455] protocol enables message exchange between The WebSocket protocol [RFC6455] enables message exchange between
clients and servers on top of a persistent TCP connection (optionally clients and servers on top of a persistent TCP connection (optionally
secured with TLS [RFC5246]). The initial protocol handshake makes secured with Transport Layer Security (TLS) [RFC5246]). The initial
use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to protocol handshake makes use of HTTP [RFC2616] semantics, allowing
reuse existing HTTP infrastructure. the WebSocket protocol to reuse existing HTTP infrastructure.
Modern web browsers include a WebSocket client stack complying with Modern web browsers include a WebSocket client stack complying with
the WebSocket API [WS-API] as specified by the W3C. It is expected the WebSocket API [WS-API] as specified by the W3C. It is expected
that other client applications (those running in personal computers that other client applications (those running in personal computers
and devices such as smartphones) will also make a WebSocket client and devices such as smartphones) will also make a WebSocket client
stack available. The specification in this document enables usage of stack available. The specification in this document enables use of
SIP in these scenarios. SIP in these scenarios.
This specification defines a WebSocket sub-protocol (as defined in This specification defines a WebSocket subprotocol (as defined in
section 1.9 in [RFC6455]) for transporting SIP messages between a Section 1.9 of [RFC6455]) for transporting SIP messages between a
WebSocket client and server, a reliable and message-boundary WebSocket client and server, a reliable and message-boundary-
preserving transport for SIP, DNS NAPTR [RFC3403] service values and preserving transport for SIP, and DNS Naming Authority Pointer
procedures for SIP entities implementing the WebSocket transport. (NAPTR) [RFC3403] service values and procedures for SIP entities
Media transport is out of the scope of this document. implementing the WebSocket transport. Media transport is out of the
scope of this document.
Section 3 in this specification relaxes the requirement in [RFC3261] Section 3 in this specification relaxes the requirement in [RFC3261]
by which the SIP server transport MUST add a "received" parameter in by which the SIP server transport MUST add a "received" parameter in
the top Via header in certain circumstances. the top Via header in certain circumstances.
2. Terminology 2. Terminology
All diagrams, examples, and notes in this specification are non-
normative, as are all sections explicitly marked non-normative.
Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2.1. Definitions 2.1. Definitions
SIP WebSocket Client: A SIP entity capable of opening outbound SIP WebSocket Client: A SIP entity capable of opening outbound
connections to WebSocket servers and communicating using the connections to WebSocket servers and communicating using the
WebSocket SIP sub-protocol as defined by this document. WebSocket SIP subprotocol as defined by this document.
SIP WebSocket Server: A SIP entity capable of listening for inbound SIP WebSocket Server: A SIP entity capable of listening for inbound
connections from WebSocket clients and communicating using the connections from WebSocket clients and communicating using the
WebSocket SIP sub-protocol as defined by this document. WebSocket SIP subprotocol as defined by this document.
3. The WebSocket Protocol 3. The WebSocket Protocol
_This section is non-normative._
The WebSocket protocol [RFC6455] is a transport layer on top of TCP The WebSocket protocol [RFC6455] is a transport layer on top of TCP
(optionally secured with TLS [RFC5246]) in which both client and (optionally secured with TLS [RFC5246]) in which both client and
server exchange message units in both directions. The protocol server exchange message units in both directions. The protocol
defines a connection handshake, WebSocket sub-protocol and extensions defines a connection handshake, WebSocket subprotocol and extensions
negotiation, a frame format for sending application and control data, negotiation, a frame format for sending application and control data,
a masking mechanism, and status codes for indicating disconnection a masking mechanism, and status codes for indicating disconnection
causes. causes.
The WebSocket connection handshake is based on HTTP [RFC2616] and The WebSocket connection handshake is based on HTTP [RFC2616] and
utilizes the HTTP GET method with an "Upgrade" request. This is sent utilizes the HTTP GET method with an "Upgrade" request. This is sent
by the client and then answered by the server (if the negotiation by the client and then answered by the server (if the negotiation
succeeded) with an HTTP 101 status code. Once the handshake is succeeded) with an HTTP 101 status code. Once the handshake is
completed the connection upgrades from HTTP to the WebSocket completed, the connection upgrades from HTTP to the WebSocket
protocol. This handshake procedure is designed to reuse the existing protocol. This handshake procedure is designed to reuse the existing
HTTP infrastructure. During the connection handshake, client and HTTP infrastructure. During the connection handshake, the client and
server agree on the application protocol to use on top of the server agree on the application protocol to use on top of the
WebSocket transport. Such application protocol (also known as a WebSocket transport. Such an application protocol (also known as a
"WebSocket sub-protocol") defines the format and semantics of the "WebSocket subprotocol") defines the format and semantics of the
messages exchanged by the endpoints. This could be a custom protocol messages exchanged by the endpoints. This could be a custom protocol
or a standardized one (as the WebSocket SIP sub-protocol defined in or a standardized one (as defined by the WebSocket SIP subprotocol in
this document). Once the HTTP 101 response is processed both client this document). Once the HTTP 101 response is processed, both the
and server reuse the underlying TCP connection for sending WebSocket client and server reuse the underlying TCP connection for sending
messages and control frames to each other. Unlike plain HTTP, this WebSocket messages and control frames to each other. Unlike plain
connection is persistent and can be used for multiple message HTTP, this connection is persistent and can be used for multiple
exchanges. message exchanges.
WebSocket defines message units to be used by applications for the WebSocket defines message units to be used by applications for the
exchange of data, so it provides a message boundary-preserving exchange of data, so it provides a message-boundary-preserving
transport layer. These message units can contain either UTF-8 text transport layer. These message units can contain either UTF-8 text
or binary data, and can be split into multiple WebSocket text/binary or binary data and can be split into multiple WebSocket text/binary
transport frames as needed by the WebSocket stack. transport frames as needed by the WebSocket stack.
The WebSocket API [WS-API] for web browsers only defines callbacks The WebSocket API [WS-API] for web browsers only defines callbacks
to be invoked upon receipt of an entire message unit, regardless to be invoked upon receipt of an entire message unit, regardless
of whether it was received in a single Websocket frame or split of whether it was received in a single WebSocket frame or split
across multiple frames. across multiple frames.
4. The WebSocket SIP Sub-Protocol 4. The WebSocket SIP Subprotocol
The term WebSocket sub-protocol refers to an application-level The term WebSocket subprotocol refers to an application-level
protocol layered on top of a WebSocket connection. This document protocol layered on top of a WebSocket connection. This document
specifies the WebSocket SIP sub-protocol for carrying SIP requests specifies the WebSocket SIP subprotocol for carrying SIP requests and
and responses through a WebSocket connection. responses through a WebSocket connection.
4.1. Handshake 4.1. Handshake
The SIP WebSocket Client and SIP WebSocket Server negotiate usage of The SIP WebSocket Client and SIP WebSocket Server negotiate usage of
the WebSocket SIP sub-protocol during the WebSocket handshake the WebSocket SIP subprotocol during the WebSocket handshake
procedure as defined in section 1.3 of [RFC6455]. The Client MUST procedure as defined in Section 1.3 of [RFC6455]. The client MUST
include the value "sip" in the Sec-WebSocket-Protocol header in its include the value "sip" in the Sec-WebSocket-Protocol header in its
handshake request. The 101 reply from the Server MUST contain "sip" handshake request. The 101 reply from the server MUST contain "sip"
in its corresponding Sec-WebSocket-Protocol header. in its corresponding Sec-WebSocket-Protocol header.
The WebSocket Client initiates a WebSocket connection when The WebSocket client initiates a WebSocket connection when
attempting to send a SIP request (unless there is an already attempting to send a SIP request (unless there is an already
established WebSocket connection for sending the SIP request). In established WebSocket connection for sending the SIP request). In
case there is no HTTP 101 response during the WebSocket handshake case there is no HTTP 101 response during the WebSocket handshake,
it is considered a transaction error as per [RFC3261] section it is considered a transaction error as per [RFC3261],
8.1.3.1 "Transaction Layer Errors". Section 8.1.3.1., "Transaction Layer Errors".
Below is an example of a WebSocket handshake in which the Client Below is an example of a WebSocket handshake in which the client
requests the WebSocket SIP sub-protocol support from the Server: requests the WebSocket SIP subprotocol support from the server:
GET / HTTP/1.1 GET / HTTP/1.1
Host: sip-ws.example.com Host: sip-ws.example.com
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: http://www.example.com Origin: http://www.example.com
Sec-WebSocket-Protocol: sip Sec-WebSocket-Protocol: sip
Sec-WebSocket-Version: 13 Sec-WebSocket-Version: 13
The handshake response from the Server accepting the WebSocket SIP The handshake response from the server accepting the WebSocket SIP
sub-protocol would look as follows: subprotocol would look as follows:
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: sip Sec-WebSocket-Protocol: sip
Once the negotiation has been completed, the WebSocket connection is Once the negotiation has been completed, the WebSocket connection is
established and can be used for the transport of SIP requests and established and can be used for the transport of SIP requests and
responses. The WebSocket messages transmitted over this connection responses. Messages other than SIP requests and responses MUST NOT
MUST conform to the negotiated WebSocket sub-protocol. be transmitted over this connection.
4.2. SIP Encoding 4.2. SIP Encoding
WebSocket messages can be transported in either UTF-8 text frames or WebSocket messages can be transported in either UTF-8 text frames or
binary frames. SIP [RFC3261] allows both text and binary bodies in binary frames. SIP [RFC3261] allows both text and binary bodies in
SIP requests and responses. Therefore SIP WebSocket Clients and SIP SIP requests and responses. Therefore, SIP WebSocket Clients and SIP
WebSocket Servers MUST accept both text and binary frames. WebSocket Servers MUST accept both text and binary frames.
5. SIP WebSocket Transport If there is at least one non-UTF-8 symbol in the whole SIP message
(including headers and the body), then the whole message MUST be
sent within a WebSocket binary message. Given the nature of
JavaScript and the WebSocket API, it is RECOMMENDED to use UTF-8
encoding (or ASCII, which is a subset of UTF-8) for SIP messages
carried over a WebSocket connection.
5.1. General 5. SIP WebSocket Transport
WebSocket [RFC6455] is a reliable protocol and therefore the SIP WebSocket [RFC6455] is a reliable protocol; therefore, the SIP
WebSocket sub-protocol defined by this document is a reliable SIP WebSocket subprotocol defined by this document is a reliable SIP
transport. Thus, client and server transactions using WebSocket for transport. Thus, client and server transactions using WebSocket for
transport MUST follow the procedures and timer values for reliable transport MUST follow the procedures and timer values for reliable
transports as defined in [RFC3261]. transports as defined in [RFC3261].
Each SIP message MUST be carried within a single WebSocket message, Each SIP message MUST be carried within a single WebSocket message,
and a WebSocket message MUST NOT contain more than one SIP message. and a WebSocket message MUST NOT contain more than one SIP message.
Because the WebSocket transport preserves message boundaries, the use Because the WebSocket transport preserves message boundaries, the use
of the Content-Length header in SIP messages is optional when they of the Content-Length header in SIP messages is not necessary when
are transported using the WebSocket sub-protocol. they are transported using the WebSocket subprotocol.
This simplifies parsing of SIP messages for both clients and This simplifies the parsing of SIP messages for both clients and
servers. There is no need to establish message boundaries using servers. There is no need to establish message boundaries using
Content-Length headers between messages. Other SIP transports, Content-Length headers between messages. Other SIP transports,
such as UDP and SCTP [RFC4168] also provide this benefit. such as UDP and the Stream Control Transmission Protocol (SCTP)
[RFC4168], also provide this benefit.
5.2. Updates to RFC 3261
5.2.1. Via Transport Parameter 5.1. Via Transport Parameter
Via header fields in SIP messages carry a transport protocol Via header fields in SIP messages carry a transport protocol
identifier. This document defines the value "WS" to be used for identifier. This document defines the value "WS" to be used for
requests over plain WebSocket connections and "WSS" for requests over requests over plain WebSocket connections and "WSS" for requests over
secure WebSocket connections (in which the WebSocket connection is secure WebSocket connections (in which the WebSocket connection is
established using TLS [RFC5246] with TCP transport). established using TLS [RFC5246] with TCP transport).
The updated augmented BNF (Backus-Naur Form) [RFC5234] for this The updated augmented BNF (Backus-Naur Form) [RFC5234] for this
parameter is the following (the original BNF for this parameter can parameter is the following (the original BNF for this parameter can
be found in [RFC3261], which was then updated by [RFC4168]): be found in [RFC3261], which was then updated by [RFC4168]):
transport =/ "WS" / "WSS" transport =/ "WS" / "WSS"
5.2.2. SIP URI Transport Parameter 5.2. SIP URI Transport Parameter
This document defines the value "ws" as the transport parameter value This document defines the value "ws" as the transport parameter value
for a SIP URI [RFC3986] to be contacted using the SIP WebSocket sub- for a SIP URI [RFC3986] to be contacted using the SIP WebSocket
protocol as transport. subprotocol as transport.
The updated augmented BNF (Backus-Naur Form) for this parameter is The updated augmented BNF for this parameter is the following (the
the following (the original BNF for this parameter can be found in original BNF for this parameter can be found in [RFC3261]):
[RFC3261]):
transport-param =/ "transport=" "ws" transport-param =/ "transport=" "ws"
5.2.3. Via received Parameter 5.3. Via "received" Parameter
[RFC3261] section 18.2.1 "Receiving Requests" states the following: The following is stated in [RFC3261], Section 18.2.1, "Receiving
Requests":
When the server transport receives a request over any transport, When the server transport receives a request over any transport,
it MUST examine the value of the "sent-by" parameter in the top 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" 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 field contains a domain name, or if it contains an IP address that
differs from the packet source address, the server MUST add a differs from the packet source address, the server MUST add a
"received" parameter to that Via header field value. This "received" parameter to that Via header field value. This
parameter MUST contain the source address from which the packet parameter MUST contain the source address from which the packet
was received. was received.
The requirement of adding the "received" parameter does not fit well The requirement of adding the "received" parameter does not fit well
into the WebSocket protocol design. The WebSocket connection into the WebSocket protocol design. The WebSocket connection
handshake reuses existing HTTP infrastructure in which there could be handshake reuses the existing HTTP infrastructure in which there
an unknown number of HTTP proxies and/or TCP load balancers between could be an unknown number of HTTP proxies and/or TCP load balancers
the SIP WebSocket Client and Server, so the source address the server between the SIP WebSocket Client and Server, so the source address
would write into the Via "received" parameter would be the address of the server would write into the Via "received" parameter would be the
the HTTP/TCP intermediary in front of it. This could reveal address of the HTTP/TCP intermediary in front of it. This could
sensitive information about the internal topology of the Server's reveal sensitive information about the internal topology of the
network to the Client. server's network to the client.
Given the fact that SIP responses can only be sent over the existing Given the fact that SIP responses can only be sent over the existing
WebSocket connection, the Via "received" parameter is of little use. WebSocket connection, the Via "received" parameter is of little use.
Therefore, in order to allow hiding possible sensitive information Therefore, in order to allow hiding possible sensitive information
about the SIP WebSocket Server's network, this document updates about the SIP WebSocket Server's network, this document updates
[RFC3261] section 18.2.1 by stating: [RFC3261], Section 18.2.1 by stating:
When a SIP WebSocket Server receives a request it MAY decide not When a SIP WebSocket Server receives a request, it MAY decide not
to add a "received" parameter to the top Via header. Therefore to add a "received" parameter to the top Via header. Therefore,
SIP WebSocket Clients MUST accept responses without such a SIP WebSocket Clients MUST accept responses without such a
parameter in the top Via header regardless of whether the Via parameter in the top Via header regardless of whether the Via
"sent-by" field contains a domain name. "sent-by" field contains a domain name.
5.2.4. SIP Transport Implementation Requirements 5.4. SIP Transport Implementation Requirements
[RFC3261] section 18 "Transport" states the following: The following is stated in [RFC3261], Section 18, "Transport":
All SIP elements MUST implement UDP and TCP. SIP elements MAY All SIP elements MUST implement UDP and TCP. SIP elements MAY
implement other protocols. implement other protocols.
The specification of this transport enables SIP to be used as a The specification of this transport enables SIP to be used as a
session establishment protocol in scenarios where none of other session establishment protocol in scenarios where none of the other
transport protocols defined for SIP can be used. Since some transport protocols defined for SIP can be used. Since some
environments do not enable SIP elements to use UDP and TCP as 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 transport protocols, a SIP element acting as a SIP WebSocket Client
is not mandated to implement support of UDP and TCP. is not mandated to implement support of UDP and TCP.
The sentence quoted above from [RFC3261] section 18 is thus amended 5.5. Locating a SIP Server
as follows:
All SIP elements MUST implement at least one of the following:
* Both UDP and TCP transports.
* SIP WebSocket transport.
5.3. Locating a SIP Server
[RFC3263] specifies the procedures which should be followed by SIP [RFC3263] specifies the procedures that should be followed by SIP
entities for locating SIP servers. This specification defines the entities for locating SIP servers. This specification defines the
NAPTR service value "SIP+D2W" for SIP WebSocket Servers that support NAPTR service value "SIP+D2W" for SIP WebSocket Servers that support
plain WebSocket connections and "SIPS+D2W" for SIP WebSocket Servers plain WebSocket connections and "SIPS+D2W" for SIP WebSocket Servers
that support secure WebSocket connections. that support secure WebSocket connections.
At the time this document was written, DNS NAPTR/SRV queries could At the time this document was written, DNS NAPTR/Service Record
not be performed by commonly available WebSocket client stacks (in (SRV) queries could not be performed by commonly available
JavaScript engines and web browsers). WebSocket client stacks (in JavaScript engines and web browsers).
In the absence of DNS SRV resource records or an explicit port, the 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" 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 transport parameter is 80, and the default port for a SIP URI using
the "sips" scheme and the "ws" transport parameter is 443. the "sips" scheme and the "ws" transport parameter is 443.
6. Connection Keep-Alive 6. Connection Keep-Alive
_This section is non-normative._
SIP WebSocket Clients and Servers may keep their WebSocket SIP WebSocket Clients and Servers may keep their WebSocket
connections open by sending periodic WebSocket "Ping" frames as connections open by sending periodic WebSocket "Ping" frames as
described in [RFC6455] section 5.5.2. described in [RFC6455], Section 5.5.2.
The WebSocket API [WS-API] does not provide a mechanism for The WebSocket API [WS-API] does not provide a mechanism for
applications running in a web browser to control whether or not applications running in a web browser to control whether or not
periodic WebSocket "Ping" frames are sent to the server. The periodic WebSocket "Ping" frames are sent to the server. The
implementation of such a keep-alive feature is the decision of implementation of such a keep-alive feature is the decision of
each web browser manufacturer and may also depend on the each web browser manufacturer and may also depend on the
configuration of the web browser. configuration of the web browser.
The indication and use of the CRLF NAT keep-alive mechanism defined The indication and use of the CRLF NAT keep-alive mechanism defined
for SIP connection-oriented transports in [RFC5626] section 3.5.1 or for SIP connection-oriented transports in [RFC5626], Section 3.5.1 or
[RFC6223] are, of course, usable over the transport defined in this [RFC6223] are, of course, usable over the transport defined in this
specification. specification.
7. Authentication 7. Authentication
This section describes how authentication is achieved through the This section describes how authentication is achieved through the
requirements in [RFC6455], [RFC6265] and [RFC3261]. requirements in [RFC6455], [RFC6265], [RFC2617], and [RFC3261].
Prior to sending SIP requests, a SIP WebSocket Client connects to a The WebSocket protocol [RFC6455] does not define an authentication
SIP WebSocket Server and performs the connection handshake. As mechanism; instead, it exposes the following text in Section 10.5,
described in Section 3 the handshake procedure involves a HTTP GET "WebSocket Client Authentication":
method request from the Client and a response from the Server
including an HTTP 101 status code.
In order to authorize the WebSocket connection, the SIP WebSocket This protocol doesn't prescribe any particular way that servers
Server MAY require specific values for some fields in the WebSocket can authenticate clients during the WebSocket handshake. The
handshake request (such as the Origin header value or query WebSocket server can use any client authentication mechanism
parameters in the request URL). The SIP WebSocket Server MAY also available to a generic HTTP server, such as cookies, HTTP
inspect any Cookie [RFC6265] headers present in the HTTP GET request. authentication, or TLS authentication.
For many web applications the value of such a Cookie is provided by
the web server once the user has authenticated to the web server,
which could be done by many existing mechanisms. As an alternative
method, the SIP WebSocket Server MAY request HTTP authentication by
replying to the Client's GET method request with a HTTP 401 status
code. The WebSocket protocol [RFC6455] covers this usage in section
4.1:
If the status code received from the server is not 101, the The following list exposes mandatory-to-implement and optional
WebSocket client stack handles the response per HTTP [RFC2616] mechanisms for SIP WebSocket Clients and Servers in order to get
procedures, in particular the client might perform authentication interoperability at the WebSocket authentication level:
if it receives 401 status code.
If SIP Digest authentication is not requested for SIP requests coming o A SIP WebSocket Client MUST be ready to add a session cookie when
from the SIP WebSocket Client, then the SIP WebSocket Server MUST it runs in a web browser (or behaves like a browser navigating a
authorize SIP requests based on a previous Web or WebSocket login / website) and has previously retrieved a session cookie from the
authentication procedure, and MUST validate that the SIP identity in web server whose URL domain matches the domain in the WebSocket
those SIP requests match the SIP identity associated to the WebSocket URI. This mechanism is defined by [RFC6265].
connection.
If no authentication is done at WebSocket level then SIP Digest o A SIP WebSocket Client MUST be ready to be challenged with an HTTP
authentication is required for every SIP request coming over the 401 status code [RFC2617] by the SIP WebSocket Server when
WebSocket connection. performing the WebSocket handshake.
o A SIP WebSocket Client MAY use TLS client authentication (when in
a secure WebSocket connection) as an optional authentication
mechanism.
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.
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 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.
Regardless of whether or not the SIP WebSocket Server requires
authentication during the WebSocket handshake, authentication MAY be
requested at the SIP level.
Some authentication use cases are exposed in Appendix A. Some authentication use cases are exposed in Appendix A.
8. Examples 8. Examples
8.1. Registration 8.1. Registration
Alice (SIP WSS) proxy.example.com Alice (SIP WSS) proxy.example.com
| | | |
|HTTP GET (WS handshake) F1 | |HTTP GET (WS handshake) F1 |
|---------------------------->| |---------------------------->|
|101 Switching Protocols F2 | |101 Switching Protocols F2 |
|<----------------------------| |<----------------------------|
| | | |
|REGISTER F3 | |REGISTER F3 |
skipping to change at page 11, line 20 skipping to change at page 10, line 23
|101 Switching Protocols F2 | |101 Switching Protocols F2 |
|<----------------------------| |<----------------------------|
| | | |
|REGISTER F3 | |REGISTER F3 |
|---------------------------->| |---------------------------->|
|200 OK F4 | |200 OK F4 |
|<----------------------------| |<----------------------------|
| | | |
Alice loads a web page using her web browser and retrieves JavaScript Alice loads a web page using her web browser and retrieves JavaScript
code implementing the WebSocket SIP sub-protocol defined in this code implementing the WebSocket SIP subprotocol defined in this
document. The JavaScript code (a SIP WebSocket Client) establishes a document. The JavaScript code (a SIP WebSocket Client) establishes a
secure WebSocket connection with a SIP proxy/registrar (a SIP secure WebSocket connection with a SIP proxy/registrar (a SIP
WebSocket Server) at proxy.example.com. Upon WebSocket connection, WebSocket Server) at proxy.example.com. Upon WebSocket connection,
Alice constructs and sends a SIP REGISTER request including Outbound Alice constructs and sends a SIP REGISTER request, including Outbound
and GRUU support. Since the JavaScript stack in a browser has no way [RFC5626] and Globally Routable User Agent URI (GRUU) [RFC5627]
to determine the local address from which the WebSocket connection support. Since the JavaScript stack in a browser has no way to
was made, this implementation uses a random ".invalid" domain name determine the local address from which the WebSocket connection was
for the Via header sent-by parameter and for the hostport of the URI made, this implementation uses a random ".invalid" domain name for
in the Contact header (see Appendix B.1). the Via header "sent-by" parameter and for the hostport of the URI in
the Contact header (see Appendix B.1).
Message details (authentication and SDP bodies are omitted for Message details (authentication and Session Description Protocol
simplicity): (SDP) bodies are omitted for simplicity):
F1 HTTP GET (WS handshake) Alice -> proxy.example.com (TLS) F1 HTTP GET (WS handshake) Alice -> proxy.example.com (TLS)
GET / HTTP/1.1 GET / HTTP/1.1
Host: proxy.example.com Host: proxy.example.com
Upgrade: websocket Upgrade: websocket
Connection: Upgrade Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: https://www.example.com Origin: https://www.example.com
Sec-WebSocket-Protocol: sip Sec-WebSocket-Protocol: sip
skipping to change at page 13, line 35 skipping to change at page 12, line 38
| |BYE F8 | | |BYE F8 |
| |<----------------------------| | |<----------------------------|
|BYE F9 | | |BYE F9 | |
|<----------------------------| | |<----------------------------| |
|200 OK F10 | | |200 OK F10 | |
|---------------------------->| | |---------------------------->| |
| |200 OK F11 | | |200 OK F11 |
| |---------------------------->| | |---------------------------->|
| | | | | |
In the same scenario Alice places a call to Bob's AoR (Address Of In the same scenario, Alice places a call to Bob's Address of Record
Record). The SIP WebSocket Server at proxy.example.com acts as a SIP (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 proxy, routing the INVITE to Bob's contact address (which happens to
be using SIP transported over UDP). Bob answers the call and then be using SIP transported over UDP). Bob answers the call and then
terminates it. terminates it.
Message details (authentication and SDP bodies are omitted for Message details (authentication and SDP bodies are omitted for
simplicity): simplicity):
F1 INVITE Alice -> proxy.example.com (transport WSS) F1 INVITE Alice -> proxy.example.com (transport WSS)
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
skipping to change at page 16, line 46 skipping to change at page 16, line 17
Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001
From: sip:bob@example.com;tag=bmqkjhsd From: sip:bob@example.com;tag=bmqkjhsd
To: sip:alice@example.com;tag=asdyka899 To: sip:alice@example.com;tag=asdyka899
Call-ID: asidkj3ss Call-ID: asidkj3ss
CSeq: 1201 BYE CSeq: 1201 BYE
9. Security Considerations 9. Security Considerations
9.1. Secure WebSocket Connection 9.1. Secure WebSocket Connection
It is recommended that the SIP traffic transported over a WebSocket It is RECOMMENDED that the SIP traffic transported over a WebSocket
communication be protected by using a secure WebSocket connection communication be protected by using a secure WebSocket connection
(using TLS [RFC5246] over TCP). (using TLS [RFC5246] over TCP).
When establishing a connection using SIP over secure WebSocket When establishing a connection using SIP over secure WebSocket
transport, the client MUST authenticate the server using the server's transport, the client MUST authenticate the server using the server's
certificate according to the WebSocket validation procedure in certificate according to the WebSocket validation procedure in
[RFC6455]. [RFC6455].
Server operators should note that this authentication procedure is Server operators should note that this authentication procedure is
different from the procedure for SIP Domain Certificates defined different from the procedure for SIP domain certificates defined
in [RFC5922]. Certificates that are appropriate for SIP over TLS in [RFC5922]. Certificates that are appropriate for SIP over TLS
over TCP will probably not be appropriate for SIP over secure over TCP will probably not be appropriate for SIP over secure
WebSocket connections. WebSocket connections.
9.2. Usage of SIPS Scheme 9.2. Usage of "sips" Scheme
The SIPS scheme in a SIP URI dictates that the entire request path to The "sips" scheme in a SIP URI dictates that the entire request path
the target be secure. If such a path includes a WebSocket connection to the target be secure. If such a path includes a WebSocket
it MUST be a secure WebSocket connection. connection, it MUST be a secure WebSocket connection.
10. IANA Considerations 10. IANA Considerations
RFC Editor Note: Please set the RFC number assigned for this document 10.1. Registration of the WebSocket SIP Subprotocol
in the sub-sections below and remove this note.
10.1. Registration of the WebSocket SIP Sub-Protocol
This specification requests IANA to register the WebSocket SIP sub- IANA has registered the WebSocket SIP subprotocol under the
protocol under the "WebSocket Subprotocol Name" Registry with the "WebSocket Subprotocol Name" registry with the following data:
following data:
Subprotocol Identifier: sip Subprotocol Identifier: sip
Subprotocol Common Name: WebSocket Transport for SIP (Session Subprotocol Common Name: WebSocket Transport for SIP (Session
Initiation Protocol) Initiation Protocol)
Subprotocol Definition: TBD: this document Subprotocol Definition: [RFC7118]
10.2. Registration of new NAPTR Service Field Values 10.2. Registration of New NAPTR Service Field Values
This document defines two new NAPTR service field values (SIP+D2W and This document defines two new NAPTR service field values (SIP+D2W and
SIPS+D2W) and requests IANA to register these values under the SIPS+D2W) and IANA has registered these values under the "Registry
"Registry for the Session Initiation Protocol (SIP) NAPTR Resource for the Session Initiation Protocol (SIP) NAPTR Resource Record
Record Services Field". The resulting entries are as follows: Services Field". The entries are as follows:
Services Field Protocol Reference Services Field Protocol Reference
-------------- -------- --------- -------------- -------- ---------
SIP+D2W WS TBD: this document SIP+D2W WS [RFC7118]
SIPS+D2W WS TBD: this document SIPS+D2W WS [RFC7118]
10.3. SIP/SIPS URI Parameters Sub-Registry 10.3. SIP/SIPS URI Parameters Subregistry
This specification requests IANA to add a reference to this document IANA has added a reference to this document under the "SIP/SIPS URI
under the "SIP/SIPS URI Parameters" Sub-Registry within the "Session Parameters" subregistry within the "Session Initiation Protocol (SIP)
Initiation Protocol (SIP) Parameters" Registry: Parameters" registry:
Parameter Name Predefined Values Reference Parameter Name Predefined Values Reference
-------------- ----------------- --------- -------------- ----------------- ---------
transport Yes [RFC3261][TBD: this document] transport Yes [RFC3261][RFC7118]
10.4. Header Fields Sub-Registry 10.4. Header Fields Subregistry
This specification requests IANA to add a reference to this document IANA has added a reference to this document under the "Header Fields"
under the "Header Fields" Sub-Registry within the "Session Initiation subregistry within the "Session Initiation Protocol (SIP) Parameters"
Protocol (SIP) Parameters" Registry: registry:
Header Name compact Reference Header Name compact Reference
----------- ------- --------- ----------- ------- ---------
Via v [RFC3261][TBD: this document] Via v [RFC3261][RFC7118]
10.5. Header Field Parameters and Parameter Values Sub-Registry 10.5. Header Field Parameters and Parameter Values Subregistry
This specification requests IANA to add a reference to this document IANA has added a reference to this document under the "Header Field
under the "Header Field Parameters and Parameter Values" Sub-Registry Parameters and Parameter Values" subregistry within the "Session
within the "Session Initiation Protocol (SIP) Parameters" Registry: Initiation Protocol (SIP) Parameters" registry:
Predefined Predefined
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
------------ -------------- ------ --------- ------------ -------------- ------ ---------
Via received No [RFC3261][TBD: this document] Via received No [RFC3261][RFC7118]
10.6. SIP Transport Sub-Registry 10.6. SIP Transport Subregistry
This document adds a new registry, "SIP Transport", to the "Session This document adds a new subregistry, "SIP Transport", to the
Initiation Protocol (SIP) Parameters" Registry. Its format and "Session Initiation Protocol (SIP) Parameters" registry. Its format
initial values are as shown in the following table: and initial values are as shown in the following table:
+------------+------------------------+ +------------+------------------------+
| Transport | Reference | | Transport | Reference |
+------------+------------------------+ +------------+------------------------+
| UDP | [RFC 3261] | | UDP | [RFC3261] |
| TCP | [RFC 3261] | | TCP | [RFC3261] |
| TLS | [RFC 3261] | | TLS | [RFC3261] |
| SCTP | [RFC 3261], [RFC 4168] | | SCTP | [RFC3261], [RFC4168] |
| TLS-SCTP | [RFC 4168] | | TLS-SCTP | [RFC4168] |
| WS | [TBD: this document] | | WS | [RFC7118] |
| WSS | [TBD: this document] | | WSS | [RFC7118] |
+------------+------------------------+ +------------+------------------------+
The policy for registration of values in this registry is "Standards The policy for registration of values in this registry is "Standards
Action", as that term is defined by [RFC5226]. Action" [RFC5226].
11. Acknowledgements 11. Acknowledgements
Special thanks to the following people who participated in Special thanks to the following people who participated in
discussions on the SIPCORE and RTCWEB WG mailing lists and discussions on the SIPCORE and RTCWEB WG mailing lists and
contributed ideas and/or provided detailed reviews (the list is contributed ideas and/or provided detailed reviews (the list is
likely to be incomplete): Hadriel Kaplan, Paul Kyzivat, Robert likely to be incomplete): Hadriel Kaplan, Paul Kyzivat, Robert
Sparks, Adam Roach, Ranjit Avasarala, Xavier Marjou, Nataraju A. B., Sparks, Adam Roach, Ranjit Avasarala, Xavier Marjou, Nataraju A. B.,
Martin Vopatek, Alexey Melnikov, Alan Johnston, Christer Holmberg, Martin Vopatek, Alexey Melnikov, Alan Johnston, Christer Holmberg,
Salvatore Loreto, Kevin P. Fleming, Suresh Krishnan, Yaron Sheffer, Salvatore Loreto, Kevin P. Fleming, Suresh Krishnan, Yaron Sheffer,
Richard Barnes, Barry Leiba, Saul Ibarra Corretge. Richard Barnes, Barry Leiba, Stephen Farrell, Ted Lemon, Benoit
Claise, Pete Resnick, Binod P.G., and Saul Ibarra Corretge.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263, Protocol (SIP): Locating SIP Servers", RFC 3263, June
June 2002. 2002.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", Part Three: The Domain Name System (DNS) Database", RFC
RFC 3403, October 2002. 3403, October 2002.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
RFC 6455, December 2011. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC
6455, December 2011.
12.2. Informative References 12.2. Informative References
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999. Names", BCP 32, RFC 2606, June 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Registering Non-Adjacent (SIP) Extension Header Field for Registering Non-Adjacent
Contacts", RFC 3327, December 2002. Contacts", RFC 3327, December 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66, RFC
RFC 3986, January 2005. 3986, January 2005.
[RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The
Stream Control Transmission Protocol (SCTP) as a Transport Stream Control Transmission Protocol (SCTP) as a Transport
for the Session Initiation Protocol (SIP)", RFC 4168, for the Session Initiation Protocol (SIP)", RFC 4168,
October 2005. October 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
[RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent URIs (GRUUs) in the Session Initiation Protocol Agent URIs (GRUUs) in the Session Initiation Protocol
(SIP)", RFC 5627, October 2009. (SIP)", RFC 5627, October 2009.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)", Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, June 2010. RFC 5922, June 2010.
[RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", RFC
RFC 6223, April 2011. 6223, April 2011.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011.
[WS-API] W3C and I. Hickson, Ed., "The WebSocket API", April 2013. [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", September
2012.
Appendix A. Authentication Use Cases Appendix A. Authentication Use Cases
_This section is non-normative._ The sections below briefly describe some SIP over WebSocket scenarios
in which authentication takes place in different ways.
Sections below briefly describe some SIP over WebSocket scenarios in
which authentication take place in different ways.
A.1. Just SIP Authentication A.1. Just SIP Authentication
SIP PBX model A implements the SIP WebSocket transport defined by SIP Private Branch Exchange (PBX) model A implements the SIP
this specification. Its implementation is 100% website agnostic as WebSocket transport defined by this specification. Its
it does not share information with the web server providing the HTML implementation is 100% website agnostic as it does not share
code to browsers, meaning that the SIP WebSocket Server (here the PBX information with the web server providing the HTML code to browsers,
model A) has no knowledge about web login activity within the meaning that the SIP WebSocket Server (here, PBX model A) has no
website. knowledge about web login activity within the website.
In this simple scenario, the SIP WebSocket Server does not inspect In this simple scenario, the SIP WebSocket Server does not inspect
fields in the WebSocket handshake HTTP GET request such as the fields in the WebSocket handshake HTTP GET request such as the
request URL, the Origin header value, the Host header value or the request URL, the Origin header value, the Host header value, or the
Cookie header value (if present). However some of those fields could Cookie header value (if present). However, some of those fields
be inspected for a minimal validation (i.e. PBX model A could 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 require that the Origin header value contains a specific URL so just
users navigating such a website would be able to establish a users navigating such a website would be able to establish a
WebSocket connection with PBX model A). WebSocket connection with PBX model A).
Once the WebSocket connection has been established, SIP Once the WebSocket connection has been established, SIP
authentication is requested by PBX model A for each SIP request authentication is requested by PBX model A for each SIP request
coming over that connection. Therefore SIP WebSocket Clients must be coming over that connection. Therefore, SIP WebSocket Clients must
provisioned with their corresponding SIP password. be provisioned with their corresponding SIP password.
A.2. Just Web Authentication A.2. Just Web Authentication
A SIP-to-PSTN provider offers telephony service for clients logged A SIP-to-PSTN (Public Switched Telephone Network) provider offers
into its website. The provider does not want to expose SIP passwords telephony service for clients logged into its website. The provider
into the web for security/privacy reasons. does not want to expose SIP passwords into the web for security/
privacy reasons.
Once the user is logged into the web, the web server provides him 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 with a SIP identity (SIP URI) and a session temporary token string
(along with the SIP WebSocket Client JavaScript application and SIP (along with the SIP WebSocket Client JavaScript application and SIP
settings). The web server stores the SIP identity and session token settings). The web server stores the SIP identity and session token
into a database. into a database.
The web application adds the SIP identity and session token as URL The web application adds the SIP identity and session token as URL
query parameters in the WebSocket handshake request and attempts the query parameters in the WebSocket handshake request and attempts the
connection. The SIP WebSocket Server inspects the handshake request connection. The SIP WebSocket Server inspects the handshake request
and validates that the session token matches the value stored in the and validates that the session token matches the value stored in the
database for the given SIP identity. In case the value matches, the database for the given SIP identity. In case the value matches, the
WebSocket connection gets "authenticated" for that SIP identity. The WebSocket connection gets "authenticated" for that SIP identity. The
SIP WebSocket Client can then register and make calls. The SIP SIP WebSocket Client can then register and make calls. The SIP
WebSocket Server would however verify that the identity in those SIP WebSocket Server would, however, verify that the identity in those
requests (i.e. the From URI value) matches the SIP identity the SIP requests (i.e., the From URI value) matches the SIP identity the
WebSocket connection is associated to (otherwise the SIP request is WebSocket connection is associated to (otherwise, the SIP request is
rejected). rejected).
When the user performs logout action in the web, the web server When the user performs a logout action in the web, the web server
removes the SIP identity and session token tuple from the database removes the SIP identity and session token tuple from the database
and notifies it to the SIP WebSocket Server which revokes and closes and notifies the SIP WebSocket Server, which revokes and closes the
the WebSocket connection. WebSocket connection.
No SIP authentication takes place in this scenario. No SIP authentication takes place in this scenario.
A.3. Cookie Based Authentication A.3. Cookie-Based Authentication
Apache web server comes with a new module mod_sip_websocket. The web The Apache web server comes with a new module: mod_sip_websocket. In
server is configured to listen in port 80 for both HTTP common port 80, the web server is configured to listen for both HTTP common
requests and WebSocket handshake requests. Therefore both the web requests and WebSocket handshake requests. Therefore, both the web
server and the SIP WebSocket Server are co-located within the same server and the SIP WebSocket Server are co-located within the same
host and same domain. host and same domain.
Once the user is logged into the web, he is provided with the SIP Once the user is logged into the web, he is provided with the SIP
WebSocket Client JavaScript application and SIP settings. The HTTP WebSocket Client JavaScript application and SIP settings. The HTTP
200 response after the login procedure also contains a session Cookie 200 response after the login procedure also contains a session cookie
[RFC6265]. The web application attempts then a WebSocket connection [RFC6265]. The web application then attempts a WebSocket connection
against the same URL/domain of the website and thus, the session against the same URL/domain of the website, and thus the session
Cookie is automatically added by the browser into the WebSocket cookie is automatically added by the browser into the WebSocket
handshake request (as the WebSocket protocol [RFC6455] states). handshake request (as the WebSocket protocol [RFC6455] states).
The web server inspects the Cookie value (as it would do for a common The web server inspects the cookie value (as it would do for a common
HTTP request containing a session Cookie, so login procedure is not HTTP request containing a session cookie so that the login procedure
required again). If the Cookie is valid the WebSocket connection is is not required again). If the cookie is valid, the WebSocket
authorized and, as in the previous use case, the connection is also connection is authorized. And, as in the previous use case, the
associated with a specific SIP identity which must be satisfied by connection is also associated with a specific SIP identity that must
every SIP request coming over that connection. be satisfied by every SIP request coming over that connection.
No SIP authentication takes place in this scenario but just common No SIP authentication takes place in this scenario but just common
Cookie usage as widely deployed in the WWW. cookie usage as widely deployed in the World Wide Web.
Appendix B. Implementation Guidelines Appendix B. Implementation Guidelines
_This section is non-normative._
Let us assume a scenario in which the users access with their web Let us assume a scenario in which the users access with their web
browsers (probably behind NAT) an application provided by a server on browsers (probably behind NAT) an application provided by a server on
an intranet, login by entering their user identifier and credentials, an intranet, login by entering their user identifier and credentials,
and retrieve a JavaScript application (along with the HTML) and retrieve a JavaScript application (along with the HTML)
implementing a SIP WebSocket Client. implementing a SIP WebSocket Client.
Such a SIP stack connects to a given SIP WebSocket Server (an Such a SIP stack connects to a given SIP WebSocket Server (an
outbound SIP proxy which also implements classic SIP transports such outbound SIP proxy that also implements classic SIP transports such
as UDP and TCP). The HTTP GET method request sent by the web browser as UDP and TCP). The HTTP GET method request sent by the web browser
for the WebSocket handshake includes a Cookie [RFC6265] header with for the WebSocket handshake includes a Cookie [RFC6265] header with
the value previously provided by the server after the successful the value previously provided by the server after the successful
login procedure. The Cookie value is then inspected by the WebSocket login procedure. The cookie value is then inspected by the WebSocket
server to authorize the connection. Once the WebSocket connection is server to authorize the connection. Once the WebSocket connection is
established, the SIP WebSocket Client performs a SIP registration to established, the SIP WebSocket Client performs a SIP registration to
a SIP registrar server that is reachable through the proxy. After a SIP registrar server that is reachable through the proxy. After
registration, the SIP WebSocket Client and Server exchange SIP registration, the SIP WebSocket Client and Server exchange SIP
messages as would normally be expected. messages as would normally be expected.
This scenario is quite similar to ones in which SIP UAs behind NATs This scenario is quite similar to ones in which SIP user agents (UAs)
connect to a proxy and must reuse the same TCP connection for behind NATs connect to a proxy and must reuse the same TCP connection
incoming requests (because they are not directly reachable by the for incoming requests (because they are not directly reachable by the
proxy otherwise). In both cases, the SIP UAs are only reachable proxy otherwise). In both cases, the SIP UAs are only reachable
through the proxy they are connected to. through the proxy to which they are connected.
The SIP Outbound extension [RFC5626] seems an appropriate solution The SIP Outbound extension [RFC5626] seems an appropriate solution
for this scenario. Therefore these SIP WebSocket Clients and the SIP for this scenario. Therefore, these SIP WebSocket Clients and the
registrar implement both the Outbound and Path [RFC3327] extensions, SIP registrar implement both the Outbound and Path [RFC3327]
and the SIP proxy acts as an Outbound Edge Proxy (as defined in extensions, and the SIP proxy acts as an Outbound Edge Proxy (as
[RFC5626] section 3.4). defined in [RFC5626], Section 3.4).
SIP WebSocket Clients in this scenario receive incoming SIP requests SIP WebSocket Clients in this scenario receive incoming SIP requests
via the SIP WebSocket Server they are connected to. Therefore, in via the SIP WebSocket Server to which they are connected. Therefore,
some call transfer cases the usage of GRUU [RFC5627] (which should be in some call transfer cases, the use of GRUU [RFC5627] (which should
implemented in both the SIP WebSocket Clients and SIP registrar) is be implemented in both the SIP WebSocket Clients and SIP registrar)
valuable. is valuable.
If a REFER request is sent to a third SIP user agent including the 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 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 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 SIP UA only if it is a globally routable URI. GRUU (Globally
Routable User Agent URI) is a solution for those scenarios, and Routable User Agent URI) is a solution for those scenarios and
would cause the incoming request from the third SIP user agent to 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 be sent to the SIP registrar, which would route the request to the
SIP WebSocket Client via the Outbound Edge Proxy. SIP WebSocket Client via the Outbound Edge Proxy.
B.1. SIP WebSocket Client Considerations B.1. SIP WebSocket Client Considerations
The JavaScript stack in web browsers does not have the ability to The JavaScript stack in web browsers does not have the ability to
discover the local transport address used for originating WebSocket discover the local transport address used for originating WebSocket
connections. A SIP WebSocket client running in such an environment connections. A SIP WebSocket Client running in such an environment
can construct a domain name consisting of a random token followed by can construct a domain name consisting of a random token followed by
the ".invalid" top-level domain name, as stated in [RFC2606], and the ".invalid" top-level domain name, as stated in [RFC2606], and
uses it within its Via and Contact headers. uses it within its Via and Contact headers.
The Contact URI provided by SIP UAs requesting (and receiving) The Contact URI provided by SIP UAs requesting (and receiving)
Outbound support is not used for routing requests to those UAs, Outbound support is not used for routing requests to those UAs,
thus it is safe to set a random domain in the Contact URI thus it is safe to set a random domain in the Contact URI
hostport. hostport.
Both the Outbound and GRUU specifications require a SIP UA to include Both the Outbound and GRUU specifications require a SIP UA to include
a Uniform Resource Name (URN) in a "+sip.instance" parameter of the a Uniform Resource Name (URN) in a "+sip.instance" parameter of the
Contact header they include their SIP REGISTER requests. The client Contact header in which they include their SIP REGISTER requests.
device is responsible for generating or collecting a suitable value The client device is responsible for generating or collecting a
for this purpose. suitable value for this purpose.
In web browsers it is difficult to generate or collect a suitable In web browsers, it is difficult to generate or collect a suitable
value to be used as a URN value from the browser itself. This value to be used as an URN value from the browser itself. This
scenario suggests that value is generated according to [RFC5626] scenario suggests that value is generated according to [RFC5626],
section 4.1 by the web application running in the browser the 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 first time it loads the JavaScript SIP stack code, and then it is
stored as a Cookie within the browser. stored as a cookie within the browser.
B.2. SIP WebSocket Server Considerations B.2. SIP WebSocket Server Considerations
The SIP WebSocket Server in this scenario behaves as a SIP Outbound The SIP WebSocket Server in this scenario behaves as a SIP Outbound
Edge Proxy, which involves support for Outbound [RFC5626] and Path Edge Proxy, which involves support for Outbound [RFC5626] and Path
[RFC3327]. [RFC3327].
The proxy performs Loose Routing and remains in the path of dialogs 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 as specified in [RFC3261]. If it did not do this, in-dialog requests
would fail since SIP WebSocket Clients make use of their SIP would fail since SIP WebSocket Clients make use of their SIP
WebSocket Server in order to send and receive SIP messages. WebSocket Server in order to send and receive SIP messages.
Authors' Addresses Authors' Addresses
Inaki Baz Castillo Inaki Baz Castillo
Versatica Versatica
Barakaldo, Basque Country Barakaldo, Basque Country
Spain Spain
Email: ibc@aliax.net EMail: ibc@aliax.net
Jose Luis Millan Villegas Jose Luis Millan Villegas
Versatica Versatica
Bilbao, Basque Country Bilbao, Basque Country
Spain Spain
Email: jmillan@aliax.net EMail: jmillan@aliax.net
Victor Pascual Victor Pascual
Acme Packet Quobis
Anabel Segura 10
Madrid, Madrid 28108
Spain Spain
Email: vpascual@acmepacket.com EMail: victor.pascual@quobis.com
 End of changes. 134 change blocks. 
352 lines changed or deleted 343 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/