--- 1/draft-ietf-sipcore-sip-websocket-09.txt 2013-11-28 19:14:29.403042880 -0800 +++ 2/draft-ietf-sipcore-sip-websocket-10.txt 2013-11-28 19:14:29.451044053 -0800 @@ -1,108 +1,105 @@ SIPCORE Working Group I. Baz Castillo Internet-Draft J. Millan Villegas -Updates: 3261 (if approved) Versatica -Intended status: Standards Track V. Pascual -Expires: December 15, 2013 Acme Packet - June 13, 2013 +Intended status: Standards Track Versatica +Expires: June 2, 2014 V. Pascual + Quobis + November 29, 2013 The WebSocket Protocol as a Transport for the Session Initiation Protocol (SIP) - draft-ietf-sipcore-sip-websocket-09 + draft-ietf-sipcore-sip-websocket-10 Abstract The WebSocket protocol enables two-way realtime communication between clients and servers in web-based applications. This document specifies a WebSocket sub-protocol as a reliable transport mechanism between SIP (Session Initiation Protocol) entities to enable usage of - SIP in web-oriented deployments. This document normatively updates - RFC 3261. + SIP in web-oriented deployments. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 5 - 4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 5 - 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4.2. SIP Encoding . . . . . . . . . . . . . . . . . . . . . . . 6 - 5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 7 - 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 5.2. Updates to RFC 3261 . . . . . . . . . . . . . . . . . . . 7 - 5.2.1. Via Transport Parameter . . . . . . . . . . . . . . . 7 - 5.2.2. SIP URI Transport Parameter . . . . . . . . . . . . . 7 - 5.2.3. Via received Parameter . . . . . . . . . . . . . . . . 8 - 5.2.4. SIP Transport Implementation Requirements . . . . . . 8 - 5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 9 - 6. Connection Keep-Alive . . . . . . . . . . . . . . . . . . . . 9 - 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 10 - 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 11 - 8.2. INVITE Dialog through a Proxy . . . . . . . . . . . . . . 12 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 16 - 9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 17 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 - 10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 17 - 10.2. Registration of new NAPTR Service Field Values . . . . . . 17 - 10.3. SIP/SIPS URI Parameters Sub-Registry . . . . . . . . . . . 18 - 10.4. Header Fields Sub-Registry . . . . . . . . . . . . . . . . 18 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. The WebSocket Protocol . . . . . . . . . . . . . . . . . . . . 3 + 4. The WebSocket SIP Sub-Protocol . . . . . . . . . . . . . . . . 4 + 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 4 + 4.2. SIP Encoding . . . . . . . . . . . . . . . . . . . . . . . 5 + 5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 6 + 5.1. Via Transport Parameter . . . . . . . . . . . . . . . . . 6 + 5.2. SIP URI Transport Parameter . . . . . . . . . . . . . . . 6 + 5.3. Via received Parameter . . . . . . . . . . . . . . . . . . 7 + 5.4. SIP Transport Implementation Requirements . . . . . . . . 7 + 5.5. Locating a SIP Server . . . . . . . . . . . . . . . . . . 8 + 6. Connection Keep-Alive . . . . . . . . . . . . . . . . . . . . 8 + 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8 + 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 10 + 8.2. INVITE Dialog through a Proxy . . . . . . . . . . . . . . 11 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 15 + 9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 16 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 + 10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 16 + 10.2. Registration of new NAPTR Service Field Values . . . . . . 16 + 10.3. SIP/SIPS URI Parameters Sub-Registry . . . . . . . . . . . 17 + 10.4. Header Fields Sub-Registry . . . . . . . . . . . . . . . . 17 10.5. Header Field Parameters and Parameter Values - Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 18 - 10.6. SIP Transport Sub-Registry . . . . . . . . . . . . . . . . 18 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 - Appendix A. Authentication Use Cases . . . . . . . . . . . . . . 21 - A.1. Just SIP Authentication . . . . . . . . . . . . . . . . . 21 - A.2. Just Web Authentication . . . . . . . . . . . . . . . . . 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 + Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 17 + 10.6. SIP Transport Sub-Registry . . . . . . . . . . . . . . . . 17 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 19 + Appendix A. Authentication Use Cases . . . . . . . . . . . . . . 20 + A.1. Just SIP Authentication . . . . . . . . . . . . . . . . . 20 + A.2. Just Web Authentication . . . . . . . . . . . . . . . . . 20 + A.3. Cookie Based Authentication . . . . . . . . . . . . . . . 21 + Appendix B. Implementation Guidelines . . . . . . . . . . . . . . 22 + B.1. SIP WebSocket Client Considerations . . . . . . . . . . . 23 + B.2. SIP WebSocket Server Considerations . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction The WebSocket [RFC6455] protocol enables message exchange between clients and servers on top of a persistent TCP connection (optionally secured with TLS [RFC5246]). The initial protocol handshake makes use of HTTP [RFC2616] semantics, allowing the WebSocket protocol to reuse existing HTTP infrastructure. Modern web browsers include a WebSocket client stack complying with @@ -118,42 +115,36 @@ preserving transport for SIP, DNS NAPTR [RFC3403] service values and procedures for SIP entities implementing the WebSocket transport. Media transport is out of the scope of this document. Section 3 in this specification relaxes the requirement in [RFC3261] by which the SIP server transport MUST add a "received" parameter in the top Via header in certain circumstances. 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", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 2.1. Definitions SIP WebSocket Client: A SIP entity capable of opening outbound connections to WebSocket servers and communicating using the WebSocket SIP sub-protocol as defined by this document. SIP WebSocket Server: A SIP entity capable of listening for inbound connections from WebSocket clients and communicating using the WebSocket SIP sub-protocol as defined by this document. 3. The WebSocket Protocol - _This section is non-normative._ - The WebSocket protocol [RFC6455] is a transport layer on top of TCP (optionally secured with TLS [RFC5246]) in which both client and server exchange message units in both directions. The protocol defines a connection handshake, WebSocket sub-protocol and extensions negotiation, a frame format for sending application and control data, a masking mechanism, and status codes for indicating disconnection causes. The WebSocket connection handshake is based on HTTP [RFC2616] and utilizes the HTTP GET method with an "Upgrade" request. This is sent @@ -223,80 +214,83 @@ sub-protocol would look as follows: HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: sip Once the negotiation has been completed, the WebSocket connection is established and can be used for the transport of SIP requests and - responses. The WebSocket messages transmitted over this connection - MUST conform to the negotiated WebSocket sub-protocol. + responses. Messages other than SIP requests and responses MUST NOT + be transmitted over this connection. 4.2. SIP Encoding WebSocket messages can be transported in either UTF-8 text frames or binary frames. SIP [RFC3261] allows both text and binary bodies in SIP requests and responses. Therefore SIP WebSocket Clients and SIP 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 sub-protocol defined by this document is a reliable SIP transport. Thus, client and server transactions using WebSocket for transport MUST follow the procedures and timer values for reliable transports as defined in [RFC3261]. Each SIP message MUST be carried within a single WebSocket message, and a WebSocket message MUST NOT contain more than one SIP message. Because the WebSocket transport preserves message boundaries, the use - of the Content-Length header in SIP messages is optional when they - are transported using the WebSocket sub-protocol. + of the Content-Length header in SIP messages is not necessary when + they are transported using the WebSocket sub-protocol. This simplifies parsing of SIP messages for both clients and servers. There is no need to establish message boundaries using Content-Length headers between messages. Other SIP transports, such as UDP and SCTP [RFC4168] also provide this benefit. -5.2. Updates to RFC 3261 - -5.2.1. Via Transport Parameter +5.1. Via Transport Parameter Via header fields in SIP messages carry a transport protocol identifier. This document defines the value "WS" to be used for requests over plain WebSocket connections and "WSS" for requests over secure WebSocket connections (in which the WebSocket connection is established using TLS [RFC5246] with TCP transport). The updated augmented BNF (Backus-Naur Form) [RFC5234] for this parameter is the following (the original BNF for this parameter can be found in [RFC3261], which was then updated by [RFC4168]): 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 for a SIP URI [RFC3986] to be contacted using the SIP WebSocket sub- protocol as transport. The updated augmented BNF (Backus-Naur Form) for this parameter is the following (the original BNF for this parameter can be found in [RFC3261]): 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: When the server transport receives a request over any transport, 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" field contains a domain name, or if it contains an IP address that differs from the packet source address, the server MUST add a "received" parameter to that Via header field value. This parameter MUST contain the source address from which the packet @@ -317,119 +311,119 @@ Therefore, in order to allow hiding possible sensitive information about the SIP WebSocket Server's network, this document updates [RFC3261] section 18.2.1 by stating: When a SIP WebSocket Server receives a request it MAY decide not to add a "received" parameter to the top Via header. Therefore SIP WebSocket Clients MUST accept responses without such a parameter in the top Via header regardless of whether the Via "sent-by" field contains a domain name. -5.2.4. SIP Transport Implementation Requirements +5.4. SIP Transport Implementation Requirements [RFC3261] section 18 "Transport" states the following: All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols. The specification of this transport enables SIP to be used as a session establishment protocol in scenarios where none of other transport protocols defined for SIP can be used. Since some environments do not enable SIP elements to use UDP and TCP as SIP transport protocols, a SIP element acting as a SIP WebSocket Client is not mandated to implement support of UDP and TCP. - 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.5. Locating a SIP Server [RFC3263] specifies the procedures which should be followed by SIP entities for locating SIP servers. This specification defines the NAPTR service value "SIP+D2W" for SIP WebSocket Servers that support plain WebSocket connections and "SIPS+D2W" for SIP WebSocket Servers that support secure WebSocket connections. At the time this document was written, DNS NAPTR/SRV queries could not be performed by commonly available WebSocket client stacks (in JavaScript engines and web browsers). 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" transport parameter is 80, and the default port for a SIP URI using the "sips" scheme and the "ws" transport parameter is 443. 6. Connection Keep-Alive - _This section is non-normative._ - SIP WebSocket Clients and Servers may keep their WebSocket connections open by sending periodic WebSocket "Ping" frames as described in [RFC6455] section 5.5.2. The WebSocket API [WS-API] does not provide a mechanism for applications running in a web browser to control whether or not periodic WebSocket "Ping" frames are sent to the server. The implementation of such a keep-alive feature is the decision of each web browser manufacturer and may also depend on the configuration of the web browser. The indication and use of the CRLF NAT keep-alive mechanism defined for SIP connection-oriented transports in [RFC5626] section 3.5.1 or [RFC6223] are, of course, usable over the transport defined in this specification. 7. Authentication 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 - SIP WebSocket Server and performs the connection handshake. As - described in Section 3 the handshake procedure involves a HTTP GET - method request from the Client and a response from the Server - including an HTTP 101 status code. + WebSocket protocol [RFC6455] does not define an authentication + mechanism, instead it exposes the following text in section 10.5 + "WebSocket Client Authentication": - In order to authorize the WebSocket connection, the SIP WebSocket - Server MAY require specific values for some fields in the WebSocket - handshake request (such as the Origin header value or query - parameters in the request URL). The SIP WebSocket Server MAY also - inspect any Cookie [RFC6265] headers present in the HTTP GET request. - 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: + This protocol doesn't prescribe any particular way that servers + can authenticate clients during the WebSocket handshake. The + WebSocket server can use any client authentication mechanism + available to a generic HTTP server, such as cookies, HTTP + authentication, or TLS authentication. - If the status code received from the server is not 101, the - WebSocket client stack handles the response per HTTP [RFC2616] - procedures, in particular the client might perform authentication - if it receives 401 status code. + The following list exposes mandatory to implement and optional + mechanisms for SIP WebSocket Clients and Servers in order to get + interoperability at WebSocket authentication level: - If SIP Digest authentication is not requested for SIP requests coming - from the SIP WebSocket Client, then the SIP WebSocket Server MUST - authorize SIP requests based on a previous Web or WebSocket login / - authentication procedure, and MUST validate that the SIP identity in - those SIP requests match the SIP identity associated to the WebSocket - connection. + o A SIP WebSocket Client MUST be ready to add a session Cookie when + it runs in a web browser (or behaves like a browser navigating a + website) and has previously retrieved a session Cookie from the + web server whose URL domain matches the domain in the WebSocket + URI. This mechanism is defined by [RFC6265]. - If no authentication is done at WebSocket level then SIP Digest - authentication is required for every SIP request coming over the - WebSocket connection. + o A SIP WebSocket Client MUST be ready to be challenged with HTTP + 401 status code by the SIP WebSocket Server when performing the + 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. 8. Examples 8.1. Registration Alice (SIP WSS) proxy.example.com | | |HTTP GET (WS handshake) F1 | |---------------------------->| @@ -678,21 +672,21 @@ Via: SIP/2.0/UDP 203.0.113.22;branch=z9hG4bKbiuiansd001 From: sip:bob@example.com;tag=bmqkjhsd To: sip:alice@example.com;tag=asdyka899 Call-ID: asidkj3ss CSeq: 1201 BYE 9. Security Considerations 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 (using TLS [RFC5246] over TCP). When establishing a connection using SIP over secure WebSocket transport, the client MUST authenticate the server using the server's certificate according to the WebSocket validation procedure in [RFC6455]. Server operators should note that this authentication procedure is different from the procedure for SIP Domain Certificates defined @@ -790,49 +784,61 @@ 11. Acknowledgements Special thanks to the following people who participated in discussions on the SIPCORE and RTCWEB WG mailing lists and contributed ideas and/or provided detailed reviews (the list is likely to be incomplete): Hadriel Kaplan, Paul Kyzivat, Robert Sparks, Adam Roach, Ranjit Avasarala, Xavier Marjou, Nataraju A. B., Martin Vopatek, Alexey Melnikov, Alan Johnston, Christer Holmberg, 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.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 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, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 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", RFC 6455, December 2011. 12.2. Informative References [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999. [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext @@ -844,47 +850,39 @@ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, "The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)", RFC 4168, 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- Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009. [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, October 2009. [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010. [RFC6223] Holmberg, C., "Indication of Support for Keep-Alive", 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. 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 @@ -956,22 +954,20 @@ 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._ - Let us assume a scenario in which the users access with their web browsers (probably behind NAT) an application provided by a server on an intranet, login by entering their user identifier and credentials, and retrieve a JavaScript application (along with the HTML) implementing a SIP WebSocket Client. Such a SIP stack connects to a given SIP WebSocket Server (an outbound SIP proxy which also implements classic SIP transports such as UDP and TCP). The HTTP GET method request sent by the web browser for the WebSocket handshake includes a Cookie [RFC6265] header with @@ -1049,24 +1045,23 @@ WebSocket Server in order to send and receive SIP messages. Authors' Addresses Inaki Baz Castillo Versatica Barakaldo, Basque Country Spain Email: ibc@aliax.net + Jose Luis Millan Villegas Versatica Bilbao, Basque Country Spain Email: jmillan@aliax.net Victor Pascual - Acme Packet - Anabel Segura 10 - Madrid, Madrid 28108 + Quobis Spain - Email: vpascual@acmepacket.com + Email: victor.pascual@quobis.com