draft-ietf-sipcore-sip-websocket-00.txt   draft-ietf-sipcore-sip-websocket-01.txt 
SIPCORE Working Group I. Baz Castillo SIPCORE Working Group I. Baz Castillo
Internet-Draft J. Millan Villegas Internet-Draft J. Millan Villegas
Intended status: Standards Track Consultant Intended status: Standards Track Consultant
Expires: November 6, 2012 V. Pascual Expires: December 29, 2012 V. Pascual
Acme Packet Acme Packet
May 5, 2012 June 27, 2012
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-00 draft-ietf-sipcore-sip-websocket-01
Abstract Abstract
The WebSocket protocol enables two-way realtime communication between The WebSocket protocol enables two-way realtime communication between
clients and servers. This document specifies a new WebSocket sub- clients and servers. This document specifies a new WebSocket sub-
protocol as a reliable transport mechanism between SIP (Session protocol as a reliable transport mechanism between SIP (Session
Initiation Protocol) entities and enables usage of the SIP protocol Initiation Protocol) entities and enables usage of the SIP protocol
in new scenarios. in new scenarios.
Status of this Memo Status of this Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 November 6, 2012. This Internet-Draft will expire on December 29, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 22 skipping to change at page 2, line 22
2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 3 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 3
4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 4 4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 4
4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 4
4.2. SIP encoding . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. SIP encoding . . . . . . . . . . . . . . . . . . . . . . . 5
5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5 5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . 6 5.2. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . 6
5.2.1. Via Transport Parameter . . . . . . . . . . . . . . . 6 5.2.1. Via Transport Parameter . . . . . . . . . . . . . . . 6
5.2.2. SIP URI Transport Parameter . . . . . . . . . . . . . 6 5.2.2. SIP URI Transport Parameter . . . . . . . . . . . . . 6
5.2.3. Sending Responses . . . . . . . . . . . . . . . . . . 6 5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 6
5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 7
6. Connection Keep Alive . . . . . . . . . . . . . . . . . . . . 7 6. Connection Keep Alive . . . . . . . . . . . . . . . . . . . . 7
7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 8
8.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 10 8.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 14 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 14
9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 15 9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 14
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 15 10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 14
10.2. Registration of new Via transports . . . . . . . . . . . . 15 10.2. Registration of new Via transports . . . . . . . . . . . . 14
10.3. Registration of new SIP URI transport . . . . . . . . . . 15 10.3. Registration of new SIP URI transport . . . . . . . . . . 15
10.4. Registration of new NAPTR service field values . . . . . . 15 10.4. Registration of new NAPTR service field values . . . . . . 15
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 15
12.2. Informative References . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 18 Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 17
A.1. SIP WebSocket Client Considerations . . . . . . . . . . . 19 A.1. SIP WebSocket Client Considerations . . . . . . . . . . . 18
A.2. SIP WebSocket Server Considerations . . . . . . . . . . . 19 A.2. SIP WebSocket Server Considerations . . . . . . . . . . . 18
Appendix B. HTTP Topology Hiding . . . . . . . . . . . . . . . . 19 Appendix B. HTTP Topology Hiding . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
The WebSocket [RFC6455] protocol enables messages exchange between The WebSocket [RFC6455] protocol enables messages 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 6, line 11 skipping to change at page 6, line 11
is also a reliable transport. Thus, client and server transactions is also a reliable transport. Thus, client and server transactions
using WebSocket transport MUST follow the procedures and timer values using WebSocket transport MUST follow the procedures and timer values
for reliable transports as defined in [RFC3261]. for reliable transports as defined in [RFC3261].
Each complete SIP message MUST be carried within a single WebSocket Each complete 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. Therefore the usage of the Content-Length header field is message. Therefore the usage of the Content-Length header field is
optional. optional.
This makes parsing of SIP messages easier on client side This makes parsing of SIP messages easier on client side
(typically web-based applications with an strict and simple API (typically web-based applications with a strict and simple API for
for receiving WebSocket messages). There is no need to establish receiving WebSocket messages). There is no need to establish
boundaries (using Content-Length headers) between different boundaries (using Content-Length headers) between different
messages. Same advantage is present in other message-based SIP messages. Same advantage is present in other message-based SIP
transports such as UDP or SCTP [RFC4168]. transports such as UDP or SCTP [RFC4168].
5.2. Updates to RFC 3261 5.2. Updates to RFC 3261
5.2.1. Via Transport Parameter 5.2.1. Via Transport Parameter
Via header fields carry the transport protocol identifier. This Via header fields carry the transport protocol identifier. This
document defines the value "WS" to be used for requests over plain document defines the value "WS" to be used for requests over plain
skipping to change at page 6, line 47 skipping to change at page 6, line 47
for a SIP URI [RFC3986] to be contacted using WebSocket protocol as for a SIP URI [RFC3986] to be contacted using WebSocket protocol as
transport. transport.
The updated RFC 3261 augmented BNF (Backus-Naur Form) for this The updated RFC 3261 augmented BNF (Backus-Naur Form) for this
parameter reads as follows: parameter reads as follows:
transport-param = "transport=" transport-param = "transport="
( "udp" / "tcp" / "sctp" / "tls" / "ws" ( "udp" / "tcp" / "sctp" / "tls" / "ws"
/ other-transport ) / other-transport )
5.2.3. Sending Responses
This specification updates the section 18.2.2 "Sending Responses" in
[RFC3261] by adding the following:
o If the Via "sent-protocol" is "WS" or "WSS" the response MUST be
sent using the existing WebSocket connection to the source of the
original request that created the transaction, if that connection
is still open. If that connection is no longer open, the server
SHOULD NOT attempt to open a WebSocket connection for sending the
response.
This is due to the nature of the WebSocket protocol in which just
the WebSocket client can establish a connection with the WebSocket
server. Typically a WebSocket client does not listen for inbound
connections and WebSocket servers do not open outbound
connections.
5.3. Locating a SIP Server 5.3. Locating a SIP Server
RFC 3263 [RFC3263] specifies the procedures which should be followed RFC 3263 [RFC3263] specifies the procedures which should be followed
by SIP entities for locating SIP servers. This specification defines by SIP entities for locating SIP servers. This specification defines
the NAPTR service value "SIP+D2W" for SIP WebSocket Servers that the NAPTR service value "SIP+D2W" for SIP WebSocket Servers that
support plain WebSocket transport and "SIPS+D2W" for SIP WebSocket support plain WebSocket transport and "SIPS+D2W" for SIP WebSocket
Servers that support secure WebSocket transport. Servers that support secure WebSocket transport.
Unfortunately neither JavaScript stacks nor WebSocket stacks Unfortunately neither JavaScript stacks nor WebSocket stacks
running in current web browsers are capable of performing DNS running in current web browsers are capable of performing DNS
skipping to change at page 9, line 4 skipping to change at page 8, line 29
Regardless whether the SIP WebSocket Server requires authentication Regardless whether the SIP WebSocket Server requires authentication
during the WebSocket handshake or not, authentication MAY be during the WebSocket handshake or not, authentication MAY be
requested at SIP protocol level. Therefore it is RECOMMENDED for a requested at SIP protocol level. Therefore it is RECOMMENDED for a
SIP WebSocket Client to implement HTTP Digest [RFC2617] SIP WebSocket Client to implement HTTP Digest [RFC2617]
authentication as stated in [RFC3261]. authentication as stated in [RFC3261].
8. Examples 8. Examples
8.1. Registration 8.1. Registration
Alice (SIP WSS) proxy.atlanta.com Alice (SIP WSS) proxy.atlanta.com
| | | |
|REGISTER F1 | |HTTP GET (WS handshake) F1 |
|---------------------------->| |---------------------------->|
|200 OK F2 | |101 Switching Protocols F2 |
|<----------------------------|
| |
|REGISTER F3 |
|---------------------------->|
|200 OK F4 |
|<----------------------------| |<----------------------------|
| | | |
Alice loads a web page using her web browser and retrieves a Alice loads a web page using her web browser and retrieves a
JavaScript code implementing the WebSocket SIP Sub-Protocol defined JavaScript code implementing the WebSocket SIP Sub-Protocol defined
in this document. The JavaScript code (a SIP WebSocket Client) in this document. The JavaScript code (a SIP WebSocket Client)
establishes a secure WebSocket connection with a SIP proxy/registrar establishes a secure WebSocket connection with a SIP proxy/registrar
(a SIP WebSocket Server) at proxy.atlanta.com. Upon WebSocket (a SIP WebSocket Server) at proxy.atlanta.com. Upon WebSocket
connection, Alice constructs and sends a SIP REGISTER by requesting connection, Alice constructs and sends a SIP REGISTER by requesting
Outbound and GRUU support. Since the JavaScript stack in a browser Outbound and GRUU support. Since the JavaScript stack in a browser
has no way to determine the local address from which the WebSocket has no way to determine the local address from which the WebSocket
connection is made, this implementation uses a random ".invalid" connection is made, this implementation uses a random ".invalid"
domain name for the Via sent-by and for the URI hostpart in the domain name for the Via sent-by and for the URI hostpart in the
Contact header (see Appendix A.1). Contact header (see Appendix A.1).
Message details (authentication and SDP bodies are omitted for Message details (authentication and SDP bodies are omitted for
simplicity): simplicity):
F1 REGISTER Alice -> proxy.atlanta.com (transport WSS) F1 HTTP GET (WS handshake) Alice -> proxy.atlanta.com (TLS)
GET / HTTP/1.1
Host: proxy.atlanta.com
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Origin: https://www.atlanta.com
Sec-WebSocket-Protocol: sip
Sec-WebSocket-Version: 13
F2 101 Switching Protocols proxy.atlanta.com -> Alice (TLS)
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: sip
F3 REGISTER Alice -> proxy.atlanta.com (transport WSS)
REGISTER sip:proxy.atlanta.com SIP/2.0 REGISTER sip:proxy.atlanta.com SIP/2.0
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf
From: sip:alice@atlanta.com;tag=65bnmj.34asd From: sip:alice@atlanta.com;tag=65bnmj.34asd
To: sip:alice@atlanta.com To: sip:alice@atlanta.com
Call-ID: aiuy7k9njasd Call-ID: aiuy7k9njasd
CSeq: 1 REGISTER CSeq: 1 REGISTER
Max-Forwards: 70 Max-Forwards: 70
Supported: path, outbound, gruu Supported: path, 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>"
F2 200 OK proxy.atlanta.com -> Alice (transport WSS) F4 200 OK proxy.atlanta.com -> Alice (transport WSS)
SIP/2.0 200 OK SIP/2.0 200 OK
Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf Via: SIP/2.0/WSS df7jal23ls0d.invalid;branch=z9hG4bKasudf
From: sip:alice@atlanta.com;tag=65bnmj.34asd From: sip:alice@atlanta.com;tag=65bnmj.34asd
To: sip:alice@atlanta.com;tag=12isjljn8 To: sip:alice@atlanta.com;tag=12isjljn8
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
skipping to change at page 16, line 17 skipping to change at page 15, line 34
-------------------- -------- --------- -------------------- -------- ---------
SIP+D2W WS TBD: this document SIP+D2W WS TBD: this document
SIPS+D2W WSS TBD: this document SIPS+D2W WSS TBD: this document
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, Adam Roach, likely to be incomplete): Hadriel Kaplan, Paul Kyzivat, Adam Roach,
Ranjit Avasarala, Xavier Marjou, Kevin P. Fleming, Nataraju A. Ranjit Avasarala, Xavier Marjou, Kevin P. Fleming, Nataraju A. B.
Special thanks to Alan Johnston, Christer Holmberg and Salvatore Special thanks to Alan Johnston, Christer Holmberg and Salvatore
Loreto for their full reviews, and also to Saul Ibarra Corretge for Loreto for their full reviews, and also to Saul Ibarra Corretge for
his contribution and suggestions. his contribution and suggestions.
Special thanks also to Aranzazu Ruiz for her valuable collaboration
in the whole document.
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.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
 End of changes. 18 change blocks. 
47 lines changed or deleted 50 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/