< draft-ietf-sipcore-sip-websocket-08.txt   draft-ietf-sipcore-sip-websocket-09.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 Updates: 3261 (if approved) Versatica
Intended status: Standards Track V. Pascual Intended status: Standards Track V. Pascual
Expires: September 12, 2013 Acme Packet Expires: December 15, 2013 Acme Packet
March 11, 2013 June 13, 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-08 draft-ietf-sipcore-sip-websocket-09
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. This document normatively updates
RFC 3261. RFC 3261.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 September 12, 2013. This Internet-Draft will expire on December 15, 2013.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 4 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 5
4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 4 4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 5
4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. SIP encoding . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. SIP Encoding . . . . . . . . . . . . . . . . . . . . . . . 6
5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5 5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 7
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.2. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . 6 5.2. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . 7
5.2.1. Via Transport Parameter . . . . . . . . . . . . . . . 6 5.2.1. Via Transport Parameter . . . . . . . . . . . . . . . 7
5.2.2. SIP URI Transport Parameter . . . . . . . . . . . . . 6 5.2.2. SIP URI Transport Parameter . . . . . . . . . . . . . 7
5.2.3. Via received parameter . . . . . . . . . . . . . . . . 7 5.2.3. Via received Parameter . . . . . . . . . . . . . . . . 8
5.2.4. SIP transport implementation requirements . . . . . . 7 5.2.4. SIP Transport Implementation Requirements . . . . . . 8
5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 8 5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 9
6. Connection Keep-Alive . . . . . . . . . . . . . . . . . . . . 8 6. Connection Keep-Alive . . . . . . . . . . . . . . . . . . . . 9
7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 11 8.2. INVITE Dialog through a Proxy . . . . . . . . . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 15 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 16
9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 16 9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 16 10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 17
10.2. Registration of new NAPTR service field values . . . . . . 16 10.2. Registration of new NAPTR Service Field Values . . . . . . 17
10.3. SIP/SIPS URI Parameters Sub-Registry . . . . . . . . . . . 17 10.3. SIP/SIPS URI Parameters Sub-Registry . . . . . . . . . . . 18
10.4. Header Fields Sub-Registry . . . . . . . . . . . . . . . . 17 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 . . . . . . . . . . . . . . . . . . . . . . . 17 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 18
10.6. SIP Transport Sub-Registry . . . . . . . . . . . . . . . . 17 10.6. SIP Transport Sub-Registry . . . . . . . . . . . . . . . . 18
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19
12.2. Informative References . . . . . . . . . . . . . . . . . . 19 12.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 20 Appendix A. Authentication Use Cases . . . . . . . . . . . . . . 21
A.1. SIP WebSocket Client Considerations . . . . . . . . . . . 21 A.1. Just SIP Authentication . . . . . . . . . . . . . . . . . 21
A.2. SIP WebSocket Server Considerations . . . . . . . . . . . 21 A.2. Just Web Authentication . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 A.3. Cookie Based Authentication . . . . . . . . . . . . . . . 22
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 [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 5, line 14 skipping to change at page 6, line 14
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 sub-protocol 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
attempting to send a SIP request (unless there is an already
established WebSocket connection for sending the SIP request). In
case there is no HTTP 101 response during the WebSocket handshake
it is considered a transaction error as per [RFC3261] section
8.1.3.1 "Transaction Layer Errors".
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 sub-protocol 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
skipping to change at page 5, line 40 skipping to change at page 6, line 47
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. The WebSocket messages transmitted over this connection
MUST conform to the negotiated WebSocket sub-protocol. MUST conform to the negotiated WebSocket sub-protocol.
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 5. SIP WebSocket Transport
5.1. General 5.1. General
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.
skipping to change at page 6, line 47 skipping to change at page 7, line 50
transport =/ "WS" / "WSS" transport =/ "WS" / "WSS"
5.2.2. SIP URI Transport Parameter 5.2.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], which was then updated by [RFC4168]): [RFC3261]):
transport-param =/ "transport=" "ws" transport-param =/ "transport=" "ws"
5.2.3. Via received parameter 5.2.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 7, line 40 skipping to change at page 8, 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.2.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 and thus MAY just is not mandated to implement support of UDP and TCP.
implement the WebSocket transport defined by this specification.
The sentence quoted above from [RFC3261] section 18 is thus amended
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 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
skipping to change at page 8, line 45 skipping to change at page 10, line 7
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 is non-normative._
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] and [RFC3261].
Prior to sending SIP requests, a SIP WebSocket Client connects to a Prior to sending SIP requests, a SIP WebSocket Client connects to a
SIP WebSocket Server and performs the connection handshake. As SIP WebSocket Server and performs the connection handshake. As
described in Section 3 the handshake procedure involves a HTTP GET described in Section 3 the handshake procedure involves a HTTP GET
method request from the Client and a response from the Server method request from the Client and a response from the Server
including an HTTP 101 status code. including an HTTP 101 status code.
In order to authorize the WebSocket connection, the SIP WebSocket In order to authorize the WebSocket connection, the SIP WebSocket
Server is allowed to inspect any Cookie [RFC6265] headers present in Server MAY require specific values for some fields in the WebSocket
the HTTP GET request. For many web applications the value of such a handshake request (such as the Origin header value or query
Cookie is provided by the web server once the user has authenticated parameters in the request URL). The SIP WebSocket Server MAY also
themselves to the web server, which could be done by many existing inspect any Cookie [RFC6265] headers present in the HTTP GET request.
mechanisms. As an alternative method, the SIP WebSocket Server could For many web applications the value of such a Cookie is provided by
request HTTP authentication by replying to the Client's GET method the web server once the user has authenticated to the web server,
request with a HTTP 401 status code. The WebSocket protocol which could be done by many existing mechanisms. As an alternative
[RFC6455] covers this usage in section 4.1: 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 If the status code received from the server is not 101, the
WebSocket client stack handles the response per HTTP [RFC2616] WebSocket client stack handles the response per HTTP [RFC2616]
procedures, in particular the client might perform authentication procedures, in particular the client might perform authentication
if it receives 401 status code. if it receives 401 status code.
Regardless of whether the SIP WebSocket Server requires If SIP Digest authentication is not requested for SIP requests coming
authentication during the WebSocket handshake, authentication can be from the SIP WebSocket Client, then the SIP WebSocket Server MUST
requested at SIP protocol level. Note that RFC 3261 requires that authorize SIP requests based on a previous Web or WebSocket login /
all SIP implementations (which includes implementations of this authentication procedure, and MUST validate that the SIP identity in
specification) implement Digest Authorization ([RFC3261] section those SIP requests match the SIP identity associated to the WebSocket
26.3.1). connection.
8. Examples If no authentication is done at WebSocket level then SIP Digest
authentication is required for every SIP request coming over the
WebSocket connection.
Some authentication use cases are exposed in Appendix A.
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 10, line 13 skipping to change at page 11, line 29
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 sub-protocol 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 and GRUU support. Since the JavaScript stack in a browser has no way
to determine the local address from which the WebSocket connection to determine the local address from which the WebSocket connection
was made, this implementation uses a random ".invalid" domain name was made, this implementation uses a random ".invalid" domain name
for the Via header sent-by parameter and for the hostport of the URI for the Via header sent-by parameter and for the hostport of the URI
in the Contact header (see Appendix A.1). in the Contact header (see Appendix B.1).
Message details (authentication and SDP bodies are omitted for Message details (authentication and SDP bodies are omitted for
simplicity): 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
skipping to change at page 11, line 22 skipping to change at page 12, line 38
Call-ID: aiuy7k9njasd Call-ID: aiuy7k9njasd
CSeq: 1 REGISTER CSeq: 1 REGISTER
Supported: outbound, gruu Supported: outbound, gruu
Contact: <sip:alice@df7jal23ls0d.invalid;transport=ws> Contact: <sip:alice@df7jal23ls0d.invalid;transport=ws>
;reg-id=1 ;reg-id=1
;+sip.instance="<urn:uuid:f81-7dec-14a06cf1>" ;+sip.instance="<urn:uuid:f81-7dec-14a06cf1>"
;pub-gruu="sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1" ;pub-gruu="sip:alice@example.com;gr=urn:uuid:f81-7dec-14a06cf1"
;temp-gruu="sip:87ash54=3dd.98a@example.com;gr" ;temp-gruu="sip:87ash54=3dd.98a@example.com;gr"
;expires=3600 ;expires=3600
8.2. INVITE dialog through a proxy 8.2. INVITE Dialog through a Proxy
Alice (SIP WSS) proxy.example.com (SIP UDP) Bob Alice (SIP WSS) proxy.example.com (SIP UDP) Bob
| | | | | |
|INVITE F1 | | |INVITE F1 | |
|---------------------------->| | |---------------------------->| |
|100 Trying F2 | | |100 Trying F2 | |
|<----------------------------| | |<----------------------------| |
| |INVITE F3 | | |INVITE F3 |
| |---------------------------->| | |---------------------------->|
| |200 OK F4 | | |200 OK F4 |
| |<----------------------------| | |<----------------------------|
skipping to change at page 16, line 6 skipping to change at page 17, line 6
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).
However none of the SIP TLS certificate checks specified in [RFC3261] When establishing a connection using SIP over secure WebSocket
or [RFC5922] will be made when using SIP over secure WebSocket transport, the client MUST authenticate the server using the server's
transport. Instead, only the checks specified by [RFC6455] will be certificate according to the WebSocket validation procedure in
made. The certificates that are appropriate for SIP over TLS over [RFC6455].
TCP will probably not be appropriate for SIP over secure WebSocket
connections. Server operators should note that this authentication procedure is
different from the procedure for SIP Domain Certificates defined
in [RFC5922]. Certificates that are appropriate for SIP over TLS
over TCP will probably not be appropriate for SIP over secure
WebSocket connections.
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 to
the target be secure. If such a path includes a WebSocket connection the target be secure. If such a path includes a WebSocket connection
it MUST be a secure WebSocket 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 RFC Editor Note: Please set the RFC number assigned for this document
skipping to change at page 16, line 37 skipping to change at page 17, line 41
protocol under the "WebSocket Subprotocol Name" Registry with the protocol under 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: TBD: this document
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 requests IANA to register these values under the
"Registry for the Session Initiation Protocol (SIP) NAPTR Resource "Registry for the Session Initiation Protocol (SIP) NAPTR Resource
Record Services Field". The resulting entries are as follows: Record Services Field". The resulting entries are as follows:
Services Field Protocol Reference Services Field Protocol Reference
-------------- -------- --------- -------------- -------- ---------
SIP+D2W WS TBD: this document SIP+D2W WS TBD: this document
SIPS+D2W WS TBD: this document SIPS+D2W WS TBD: this document
skipping to change at page 18, line 15 skipping to change at page 19, line 28
Action", as that term is defined by [RFC5226]. Action", as that term is defined by [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 (complete grammatical review), Salvatore Loreto, Kevin P. Fleming, Suresh Krishnan, Yaron Sheffer,
Saul Ibarra Corretge. Richard Barnes, Barry Leiba, 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.
[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.
skipping to change at page 19, line 48 skipping to change at page 21, line 9
[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, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[WS-API] W3C and I. Hickson, Ed., "The WebSocket API", [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", April 2013.
September 2012.
Appendix A. Implementation Guidelines Appendix A. Authentication Use Cases
_This section is non-normative._
Sections below briefly describe some SIP over WebSocket scenarios in
which authentication take place in different ways.
A.1. Just SIP Authentication
SIP PBX model A implements the SIP WebSocket transport defined by
this specification. Its implementation is 100% website agnostic as
it does not share information with the web server providing the HTML
code to browsers, meaning that the SIP WebSocket Server (here the PBX
model A) has no knowledge about web login activity within the
website.
In this simple scenario, the SIP WebSocket Server does not inspect
fields in the WebSocket handshake HTTP GET request such as the
request URL, the Origin header value, the Host header value or the
Cookie header value (if present). However some of those fields could
be inspected for a minimal validation (i.e. PBX model A could
require that the Origin header value contains a specific URL so just
users navigating such a website would be able to establish a
WebSocket connection with PBX model A).
Once the WebSocket connection has been established, SIP
authentication is requested by PBX model A for each SIP request
coming over that connection. Therefore SIP WebSocket Clients must be
provisioned with their corresponding SIP password.
A.2. Just Web Authentication
A SIP-to-PSTN provider offers telephony service for clients logged
into its website. The provider does not want to expose SIP passwords
into the web for security/privacy reasons.
Once the user is logged into the web, the web server provides him
with a SIP identity (SIP URI) and a session temporary token string
(along with the SIP WebSocket Client JavaScript application and SIP
settings). The web server stores the SIP identity and session token
into a database.
The web application adds the SIP identity and session token as URL
query parameters in the WebSocket handshake request and attempts the
connection. The SIP WebSocket Server inspects the handshake request
and validates that the session token matches the value stored in the
database for the given SIP identity. In case the value matches, the
WebSocket connection gets "authenticated" for that SIP identity. The
SIP WebSocket Client can then register and make calls. The SIP
WebSocket Server would however verify that the identity in those SIP
requests (i.e. the From URI value) matches the SIP identity the
WebSocket connection is associated to (otherwise the SIP request is
rejected).
When the user performs logout action in the web, the web server
removes the SIP identity and session token tuple from the database
and notifies it to the SIP WebSocket Server which revokes and closes
the WebSocket connection.
No SIP authentication takes place in this scenario.
A.3. Cookie Based Authentication
Apache web server comes with a new module mod_sip_websocket. The web
server is configured to listen in port 80 for both HTTP common
requests and WebSocket handshake requests. Therefore both the web
server and the SIP WebSocket Server are co-located within the same
host and same domain.
Once the user is logged into the web, he is provided with the SIP
WebSocket Client JavaScript application and SIP settings. The HTTP
200 response after the login procedure also contains a session Cookie
[RFC6265]. The web application attempts then a WebSocket connection
against the same URL/domain of the website and thus, the session
Cookie is automatically added by the browser into the WebSocket
handshake request (as the WebSocket protocol [RFC6455] states).
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
required again). If the Cookie is valid the WebSocket connection is
authorized and, as in the previous use case, the connection is also
associated with a specific SIP identity which must be satisfied by
every SIP request coming over that connection.
No SIP authentication takes place in this scenario but just common
Cookie usage as widely deployed in the WWW.
Appendix B. Implementation Guidelines
_This section is non-normative._ _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
skipping to change at page 21, line 5 skipping to change at page 24, line 5
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.
A.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,
skipping to change at page 21, line 32 skipping to change at page 24, line 32
device is responsible for generating or collecting a suitable value device is responsible for generating or collecting a suitable value
for this purpose. 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 a 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.
A.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.
 End of changes. 26 change blocks. 
81 lines changed or deleted 197 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/