draft-ietf-sipcore-sip-websocket-09.txt   draft-ietf-sipcore-sip-websocket-10.txt 
SIPCORE Working Group I. Baz Castillo SIPCORE Working Group I. Baz Castillo
Internet-Draft J. Millan Villegas Internet-Draft J. Millan Villegas
Updates: 3261 (if approved) Versatica Intended status: Standards Track Versatica
Intended status: Standards Track V. Pascual Expires: June 2, 2014 V. Pascual
Expires: December 15, 2013 Acme Packet Quobis
June 13, 2013 November 29, 2013
The WebSocket Protocol as a Transport for the Session Initiation The WebSocket Protocol as a Transport for the Session Initiation
Protocol (SIP) Protocol (SIP)
draft-ietf-sipcore-sip-websocket-09 draft-ietf-sipcore-sip-websocket-10
Abstract Abstract
The WebSocket protocol enables two-way realtime communication between The WebSocket protocol enables two-way realtime communication between
clients and servers in web-based applications. This document clients and servers in web-based applications. This document
specifies a WebSocket sub-protocol as a reliable transport mechanism specifies a WebSocket sub-protocol as a reliable transport mechanism
between SIP (Session Initiation Protocol) entities to enable usage of between SIP (Session Initiation Protocol) entities to enable usage of
SIP in web-oriented deployments. This document normatively updates SIP in web-oriented deployments.
RFC 3261.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 15, 2013. This Internet-Draft will expire on June 2, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 Sub-Protocol . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 10
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.2. INVITE Dialog through a Proxy . . . . . . . . . . . . . . 11
8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 11 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8.2. INVITE Dialog through a Proxy . . . . . . . . . . . . . . 12 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 15
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 Sub-Protocol . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10.2. Registration of new NAPTR Service Field Values . . . . . . 16
10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 17 10.3. SIP/SIPS URI Parameters Sub-Registry . . . . . . . . . . . 17
10.2. Registration of new NAPTR Service Field Values . . . . . . 17 10.4. Header Fields Sub-Registry . . . . . . . . . . . . . . . . 17
10.3. SIP/SIPS URI Parameters Sub-Registry . . . . . . . . . . . 18
10.4. Header Fields Sub-Registry . . . . . . . . . . . . . . . . 18
10.5. Header Field Parameters and Parameter Values 10.5. Header Field Parameters and Parameter Values
Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 18 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 17
10.6. SIP Transport Sub-Registry . . . . . . . . . . . . . . . . 18 10.6. SIP Transport Sub-Registry . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. Authentication Use Cases . . . . . . . . . . . . . . 21 Appendix A. Authentication Use Cases . . . . . . . . . . . . . . 20
A.1. Just SIP Authentication . . . . . . . . . . . . . . . . . 21 A.1. Just SIP Authentication . . . . . . . . . . . . . . . . . 20
A.2. Just Web Authentication . . . . . . . . . . . . . . . . . 21 A.2. Just Web Authentication . . . . . . . . . . . . . . . . . 20
A.3. Cookie Based Authentication . . . . . . . . . . . . . . . 22 A.3. Cookie Based Authentication . . . . . . . . . . . . . . . 21
Appendix B. Implementation Guidelines . . . . . . . . . . . . . . 23 Appendix B. Implementation Guidelines . . . . . . . . . . . . . . 22
B.1. SIP WebSocket Client Considerations . . . . . . . . . . . 24 B.1. SIP WebSocket Client Considerations . . . . . . . . . . . 23
B.2. SIP WebSocket Server Considerations . . . . . . . . . . . 24 B.2. SIP WebSocket Server Considerations . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction 1. Introduction
The WebSocket [RFC6455] protocol enables message exchange between The WebSocket [RFC6455] protocol 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 TLS [RFC5246]). The initial protocol handshake makes
use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to
reuse existing HTTP infrastructure. reuse existing HTTP infrastructure.
Modern web browsers include a WebSocket client stack complying with Modern web browsers include a WebSocket client stack complying with
skipping to change at page 4, line 33 skipping to change at page 3, line 33
preserving transport for SIP, DNS NAPTR [RFC3403] service values and preserving transport for SIP, DNS NAPTR [RFC3403] service values and
procedures for SIP entities implementing the WebSocket transport. procedures for SIP entities implementing the WebSocket transport.
Media transport is out of the scope of this document. 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 sub-protocol 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 sub-protocol 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 sub-protocol 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
skipping to change at page 6, line 44 skipping to change at page 5, line 38
sub-protocol would look as follows: sub-protocol 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 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 and therefore the SIP
WebSocket sub-protocol defined by this document is a reliable SIP WebSocket sub-protocol 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 sub-protocol.
This simplifies parsing of SIP messages for both clients and This simplifies 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 SCTP [RFC4168] also provide this benefit.
5.2. Updates to RFC 3261 5.1. Via Transport Parameter
5.2.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 sub-
protocol as transport. protocol as transport.
The updated augmented BNF (Backus-Naur Form) for this parameter is The updated augmented BNF (Backus-Naur Form) for this parameter is
the following (the original BNF for this parameter can be found in the following (the 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: [RFC3261] section 18.2.1 "Receiving Requests" states the following:
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
skipping to change at page 8, line 40 skipping to change at page 7, line 40
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: [RFC3261] section 18 "Transport" states the following:
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 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 which 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/SRV queries could
not be performed by commonly available WebSocket client stacks (in not be performed by commonly available WebSocket client stacks (in
JavaScript engines and web browsers). 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 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 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 HTTP
authentication is required for every SIP request coming over the 401 status code by the SIP WebSocket Server when performing the
WebSocket connection. WebSocket handshake as stated in [RFC2617].
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 WebSocket
protocol is governed by the rules of HTTP protocol rather than
the rules of SIP protocol.
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 a 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 HTTP 401 status code by providing a Basic/
Digest challenge as defined for HTTP protocol.
Regardless of whether the SIP WebSocket Server requires
authentication during the WebSocket handshake or not, authentication
MAY be requested at SIP protocol 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 |
|---------------------------->| |---------------------------->|
skipping to change at page 16, line 46 skipping to change at page 15, line 46
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
skipping to change at page 19, line 29 skipping to change at page 18, line 29
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, 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 2002. June 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 3403, October 2002. RFC 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.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(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", [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, December 2011. 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
skipping to change at page 20, line 37 skipping to change at page 19, line 48
[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 3986, January 2005. RFC 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 6223, April 2011. RFC 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", April 2013.
Appendix A. Authentication Use Cases Appendix A. Authentication Use Cases
_This section is non-normative._
Sections below briefly describe some SIP over WebSocket scenarios in Sections below briefly describe some SIP over WebSocket scenarios in
which authentication take place in different ways. 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 PBX model A implements the SIP WebSocket transport defined by
this specification. Its implementation is 100% website agnostic as this specification. Its implementation is 100% website agnostic as
it does not share information with the web server providing the HTML it does not share information with the web server providing the HTML
code to browsers, meaning that the SIP WebSocket Server (here the PBX code to browsers, meaning that the SIP WebSocket Server (here the PBX
model A) has no knowledge about web login activity within the model A) has no knowledge about web login activity within the
skipping to change at page 23, line 7 skipping to change at page 22, line 10
required again). If the Cookie is valid the WebSocket connection is required again). If the Cookie is valid the WebSocket connection is
authorized and, as in the previous use case, the connection is also authorized and, as in the previous use case, the connection is also
associated with a specific SIP identity which must be satisfied by associated with a specific SIP identity which must be satisfied by
every SIP request coming over that connection. 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 WWW.
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 which 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
skipping to change at page 25, line 4 skipping to change at page 24, line 13
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. 35 change blocks. 
126 lines changed or deleted 121 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/