draft-ietf-sipcore-sip-websocket-06.txt   draft-ietf-sipcore-sip-websocket-07.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: May 10, 2013 Acme Packet Expires: August 22, 2013 Acme Packet
November 6, 2012 February 18, 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-06 draft-ietf-sipcore-sip-websocket-07
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 in web-based applications. This document
protocol as a reliable transport mechanism between SIP (Session specifies a WebSocket sub-protocol as a reliable transport mechanism
Initiation Protocol) entities to enable usage of SIP in new between SIP (Session Initiation Protocol) entities to enable usage of
scenarios. This document normatively updates RFC 3261. SIP in web-oriented deployments. This document normatively updates
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 May 10, 2013. This Internet-Draft will expire on August 22, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 2, line 25 skipping to change at page 2, line 26
4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. SIP encoding . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. SIP encoding . . . . . . . . . . . . . . . . . . . . . . . 5
5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5 5. SIP WebSocket Transport . . . . . . . . . . . . . . . . . . . 5
5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
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. Via received parameter . . . . . . . . . . . . . . . . 7 5.2.3. Via received parameter . . . . . . . . . . . . . . . . 7
5.2.4. SIP transport implementation requirements . . . . . . 7 5.2.4. SIP transport implementation requirements . . . . . . 7
5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 8 5.3. Locating a SIP Server . . . . . . . . . . . . . . . . . . 8
6. Connection Keep Alive . . . . . . . . . . . . . . . . . . . . 8 6. Connection Keep-Alive . . . . . . . . . . . . . . . . . . . . 8
7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Authentication . . . . . . . . . . . . . . . . . . . . . . . . 8
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Registration . . . . . . . . . . . . . . . . . . . . . . . 9
8.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 11 8.2. INVITE dialog through a proxy . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 15 9.1. Secure WebSocket Connection . . . . . . . . . . . . . . . 15
9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 16 9.2. Usage of SIPS Scheme . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 16 10.1. Registration of the WebSocket SIP Sub-Protocol . . . . . . 16
10.2. Registration of new NAPTR service field values . . . . . . 16 10.2. Registration of new NAPTR service field values . . . . . . 16
10.3. SIP/SIPS URI Parameters Sub-Registry . . . . . . . . . . . 16 10.3. SIP/SIPS URI Parameters Sub-Registry . . . . . . . . . . . 16
10.4. Header Fields Sub-Registry . . . . . . . . . . . . . . . . 17 10.4. Header Fields Sub-Registry . . . . . . . . . . . . . . . . 17
10.5. Header Field Parameters and Parameter Values 10.5. Header Field Parameters and Parameter Values
Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 17 Sub-Registry . . . . . . . . . . . . . . . . . . . . . . . 17
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
12.1. Normative References . . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18
12.2. Informative References . . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 19 Appendix A. Implementation Guidelines . . . . . . . . . . . . . . 19
A.1. SIP WebSocket Client Considerations . . . . . . . . . . . 20 A.1. SIP WebSocket Client Considerations . . . . . . . . . . . 20
A.2. SIP WebSocket Server Considerations . . . . . . . . . . . 20 A.2. SIP WebSocket Server Considerations . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
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
the WebSocket API [WS-API] as specified by the W3C. It is expected the WebSocket API [WS-API] as specified by the W3C. It is expected
that other client applications (those running in personal computers that other client applications (those running in personal computers
and devices such as smartphones) will also make a WebSocket client and devices such as smartphones) will also make a WebSocket client
stack available. The specification in this document enables usage of stack available. The specification in this document enables usage of
SIP in these scenarios. SIP in these scenarios.
This specification defines a new WebSocket sub-protocol (as defined This specification defines a WebSocket sub-protocol (as defined in
in section 1.9 in [RFC6455]) for transporting SIP messages between a section 1.9 in [RFC6455]) for transporting SIP messages between a
WebSocket client and server, a new reliable and message boundary WebSocket client and server, a reliable and message-boundary
transport for SIP, new 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- All diagrams, examples, and notes in this specification are non-
skipping to change at page 6, line 37 skipping to change at page 6, line 37
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 = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" transport =/ "WS" / "WSS"
/ "WS" / "WSS"
/ other-transport
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], which was then updated by [RFC4168]):
transport-param = "transport=" transport-param =/ "transport=" "ws"
( "udp" / "tcp" / "sctp" / "tls" / "ws"
/ other-transport )
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
skipping to change at page 7, line 41 skipping to change at page 7, line 37
Given the fact that SIP responses can only be sent over the existing Given the fact that SIP responses can only be sent over the existing
WebSocket connection, the Via "received" parameter is of little use. WebSocket connection, the Via "received" parameter is of little use.
Therefore, in order to allow hiding possible sensitive information Therefore, in order to allow hiding possible sensitive information
about the SIP WebSocket Server's network, this document updates about the SIP WebSocket Server's network, this document updates
[RFC3261] section 18.2.1 by stating: [RFC3261] section 18.2.1 by stating:
When a SIP WebSocket Server receives a request it MAY decide not When a SIP WebSocket Server receives a request it MAY decide not
to add a "received" parameter to the top Via header. Therefore to add a "received" parameter to the top Via header. Therefore
SIP WebSocket Clients MUST accept responses without such a SIP WebSocket Clients MUST accept responses without such a
parameter in the top Via header regardless the Via "sent-by" field parameter in the top Via header regardless of whether the Via
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 new 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 and thus MAY just
implement the WebSocket transport defined by this specification. implement the WebSocket transport defined by this specification.
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
skipping to change at page 8, line 27 skipping to change at page 8, line 23
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._ _This section is non-normative._
It is RECOMMENDED that SIP WebSocket Clients and Servers keep their SIP WebSocket Clients and Servers may keep their WebSocket
WebSocket connections open by sending periodic WebSocket "Ping" connections open by sending periodic WebSocket "Ping" frames as
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.
A future WebSocket protocol extension providing a similar keep alive The indication and use of the CRLF NAT keep-alive mechanism defined
mechanism could also be used. for SIP connection-oriented transports in [RFC5626] section 3.5.1 or
[RFC6223] are, of course, usable over the transport defined in this
The SIP stack in the SIP WebSocket Client MAY also use a Network specification.
Address Translation (NAT) keep-alive mechanism defined for SIP
connection-oriented transports, such as the CRLF Keep-Alive Technique
mechanism described in [RFC5626] section 3.5.1 or [RFC6223].
Implementing this technique would involve sending a WebSocket
message to the SIP WebSocket Server with a content consisting of
only a double CRLF, and expecting a WebSocket message from the
server containing a single CRLF as response.
7. Authentication 7. Authentication
_This section is non-normative._ _This section is non-normative._
This section describes how authentication is achieved through the
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 MAY inspect any Cookie [RFC6265] headers present in the HTTP Server is allowed to inspect any Cookie [RFC6265] headers present in
GET request. For many web applications the value of such a Cookie is the HTTP GET request. For many web applications the value of such a
provided by the web server once the user has authenticated themselves Cookie is provided by the web server once the user has authenticated
to the web server, which could be done by many existing mechanisms. themselves to the web server, which could be done by many existing
As an alternative method, the SIP WebSocket Server could request HTTP mechanisms. As an alternative method, the SIP WebSocket Server could
authentication by replying to the Client's GET method request with a request HTTP authentication by replying to the Client's GET method
HTTP 401 status code. The WebSocket protocol [RFC6455] covers this request with a HTTP 401 status code. The WebSocket protocol
usage in section 4.1: [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 Regardless of whether the SIP WebSocket Server requires
authentication during the WebSocket handshake, authentication MAY be authentication during the WebSocket handshake, authentication can be
requested at SIP protocol level. Therefore it is RECOMMENDED that a requested at SIP protocol level. Note that RFC 3261 requires that
SIP WebSocket Client implements HTTP Digest [RFC2617] authentication all SIP implementations (which includes implementations of this
as stated in [RFC3261]. specification) implement Digest Authorization ([RFC3261] section
26.3.1).
8. Examples 8. Examples
8.1. Registration 8.1. Registration
Alice (SIP WSS) proxy.example.com Alice (SIP WSS) proxy.example.com
| | | |
|HTTP GET (WS handshake) F1 | |HTTP GET (WS handshake) F1 |
|---------------------------->| |---------------------------->|
|101 Switching Protocols F2 | |101 Switching Protocols F2 |
|<----------------------------| |<----------------------------|
| | | |
|REGISTER F3 | |REGISTER F3 |
|---------------------------->| |---------------------------->|
|200 OK F4 | |200 OK F4 |
skipping to change at page 16, line 6 skipping to change at page 16, 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]
or [RFC5922] will be made when using SIP over secure WebSocket
transport. Instead, only the checks specified by [RFC6455] will be
made. The 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
10.1. Registration of the WebSocket SIP Sub-Protocol 10.1. Registration of the WebSocket SIP Sub-Protocol
skipping to change at page 17, line 32 skipping to change at page 17, line 36
Header Field Parameter Name Values Reference Header Field Parameter Name Values Reference
------------ -------------- ------ --------- ------------ -------------- ------ ---------
Via received No [RFC3261][TBD: this document] Via received No [RFC3261][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, Nataraju A. B. Ranjit Avasarala, Xavier Marjou, Nataraju A. B., Martin Vopatek,
Alexey Melnikov.
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 to Kevin P. Fleming for his complete grammatical Special thanks to Kevin P. Fleming for his complete grammatical
review along with suggestions, comments and improvements. review along with suggestions, comments and improvements.
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,
June 2002. June 2002.
skipping to change at page 18, line 29 skipping to change at page 18, line 37
12.2. Informative References 12.2. Informative References
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS
Names", BCP 32, RFC 2606, June 1999. Names", BCP 32, RFC 2606, June 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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.
[RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol
(SIP) Extension Header Field for Registering Non-Adjacent (SIP) Extension Header Field for Registering Non-Adjacent
Contacts", RFC 3327, December 2002. Contacts", RFC 3327, December 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 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
skipping to change at page 19, line 10 skipping to change at page 19, line 13
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (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
Certificates in the Session Initiation Protocol (SIP)",
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", May 2012. [WS-API] W3C and I. Hickson, Ed., "The WebSocket API",
September 2012.
Appendix A. Implementation Guidelines Appendix A. 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.
skipping to change at page 20, line 24 skipping to change at page 20, line 31
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 A.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. Therefore the SIP WebSocket Client constructs a domain connections. A SIP WebSocket client running in such an environment
name consisting of a random token followed by the ".invalid" top- can construct a domain name consisting of a random token followed by
level domain name, as stated in [RFC2606], and uses it within its Via the ".invalid" top-level domain name, as stated in [RFC2606], and
and Contact headers. uses it within its Via and Contact headers.
The Contact URI provided by SIP UAs requesting (and receiving) The Contact URI provided by SIP UAs requesting (and receiving)
Outbound support is not used for routing requests to those UAs, Outbound support is not used for routing requests to those UAs,
thus it is safe to set a random domain in the Contact URI thus it is safe to set a random domain in the Contact URI
hostport. hostport.
Both the Outbound and GRUU specifications require a SIP UA to include Both the Outbound and GRUU specifications require a SIP UA to include
a Uniform Resource Name (URN) in a "+sip.instance" parameter of the a Uniform Resource Name (URN) in a "+sip.instance" parameter of the
Contact header they include their SIP REGISTER requests. The client Contact header they include their SIP REGISTER requests. The client
device is responsible for generating or collecting a suitable value device is responsible for generating or collecting a suitable value
 End of changes. 28 change blocks. 
68 lines changed or deleted 69 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/