< draft-ietf-bfcpbis-sdp-ws-uri-05.txt   draft-ietf-bfcpbis-sdp-ws-uri-06.txt >
BFCPBIS Working Group Ram. Ravindranath BFCPBIS Working Group Ram. Ravindranath
Internet-Draft G. Salgueiro Internet-Draft G. Salgueiro
Intended status: Standards Track Cisco Intended status: Standards Track Cisco
Expires: January 21, 2017 July 20, 2016 Expires: April 19, 2017 October 16, 2016
Session Description Protocol (SDP) WebSocket Connection URI Attribute Session Description Protocol (SDP) WebSocket Connection URI Attribute
draft-ietf-bfcpbis-sdp-ws-uri-05 draft-ietf-bfcpbis-sdp-ws-uri-06
Abstract Abstract
The WebSocket protocol enables bidirectional real-time communication The WebSocket protocol enables bidirectional real-time communication
between clients and servers in web-based applications. This document between clients and servers in web-based applications. This document
specifies extensions to Session Description Protocol (SDP) for specifies extensions to Session Description Protocol (SDP) for
application protocols using WebSocket as a transport. application protocols using WebSocket as a transport.
Status of This Memo Status of This Memo
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 January 21, 2017. This Internet-Draft will expire on April 19, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 21 skipping to change at page 2, line 21
3.2. ws-uri SDP Attribute . . . . . . . . . . . . . . . . . . 3 3.2. ws-uri SDP Attribute . . . . . . . . . . . . . . . . . . 3
3.3. wss-uri SDP Attribute . . . . . . . . . . . . . . . . . . 4 3.3. wss-uri SDP Attribute . . . . . . . . . . . . . . . . . . 4
3.4. ws-uri and wss-uri Multiplexing Considerations . . . . . 4 3.4. ws-uri and wss-uri Multiplexing Considerations . . . . . 4
4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5 4. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 5
4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Generating the Initial Offer . . . . . . . . . . . . . . 5 4.2. Generating the Initial Offer . . . . . . . . . . . . . . 5
4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 6 4.3. Generating the Answer . . . . . . . . . . . . . . . . . . 6
4.4. Offerer Processing of the Answer . . . . . . . . . . . . 7 4.4. Offerer Processing of the Answer . . . . . . . . . . . . 7
4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 7 4.5. Modifying the Session . . . . . . . . . . . . . . . . . . 7
4.6. Offerless INVITE Scenarios . . . . . . . . . . . . . . . 7 4.6. Offerless INVITE Scenarios . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Procedures at WebSocket Client . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.1. Registration of the 'ws-uri' SDP Media Attribute . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.2. Registration of the 'wss-uri' SDP Media Attribute . . . . 8 7.1. Registration of the 'ws-uri' SDP Media Attribute . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Registration of the 'wss-uri' SDP Media Attribute . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 9.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
The WebSocket protocol [RFC6455] enables bidirectional message The WebSocket protocol [RFC6455] enables bidirectional message
exchange between clients and servers on top of a persistent TCP exchange between clients and servers on top of a persistent TCP
connection (optionally secured with Transport Layer Security (TLS) connection (optionally secured with Transport Layer Security (TLS)
[RFC5246]). The initial protocol handshake makes use of Hypertext [RFC5246]). The initial protocol handshake makes use of Hypertext
Transfer Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket Transfer Protocol (HTTP) [RFC7230] semantics, allowing the WebSocket
protocol to reuse existing HTTP infrastructure. protocol to reuse existing HTTP infrastructure.
skipping to change at page 3, line 15 skipping to change at page 3, line 16
[RFC7395] defines a WebSocket subprotocol for the Extensible [RFC7395] defines a WebSocket subprotocol for the Extensible
Messaging and Presence Protocol (XMPP). Similarly, Messaging and Presence Protocol (XMPP). Similarly,
[I-D.ietf-bfcpbis-bfcp-websocket] defines a WebSocket sub-protocol as [I-D.ietf-bfcpbis-bfcp-websocket] defines a WebSocket sub-protocol as
a reliable transport mechanism between Binary Floor Control Protocol a reliable transport mechanism between Binary Floor Control Protocol
(BFCP) [I-D.ietf-bfcpbis-rfc4582bis] entities to enable usage of BFCP (BFCP) [I-D.ietf-bfcpbis-rfc4582bis] entities to enable usage of BFCP
in new scenarios. in new scenarios.
As defined in Section 3 of [RFC2818], when using Secure WebSockets As defined in Section 3 of [RFC2818], when using Secure WebSockets
the Canonical Name (CNAME) of the Secure Sockets Layer (SSL) the Canonical Name (CNAME) of the Secure Sockets Layer (SSL)
[RFC6101] certificate MUST match the WebSocket connection URI host. [RFC6101] certificate MUST match the WebSocket connection URI host.
While it is possible to generate self-signed certificates with In most cases it is not viable for certificates signed by well known
Internet Providers (IPs) as CNAME, in most cases it is not viable for authorities. Thus, there is a need to indicate the connection URI
certificates signed by well known authorities. Thus, there is a need for the WebSocket Client. For applications that use Session
to indicate the connection URI for the WebSocket Client. For Description Protocol (SDP) [RFC4566] to negotiate, the connection URI
applications that use Session Description Protocol (SDP) [RFC4566] to can be indicated by means of an SDP attribute. This specification
negotiate, the connection URI can be indicated by means of an SDP defines new SDP attributes to indicate the connection URI for the
attribute. This specification defines new SDP attributes to indicate WebSocket client. Applications that use SDP for negotiation and
the connection URI for the WebSocket client. Applications that use WebSocket as a transport protocol can use this specification to
SDP for negotiation and WebSocket as a transport protocol can use advertise the WebSocket client connection URI.
this specification to advertise the WebSocket client connection URI.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. SDP Considerations 3. SDP Considerations
skipping to change at page 4, line 14 skipping to change at page 4, line 14
Example: Example:
a=ws-uri:ws://example.com/chat a=ws-uri:ws://example.com/chat
Where "ws://example.com/chat" is the ws-URI defined in Section 3 of Where "ws://example.com/chat" is the ws-URI defined in Section 3 of
[RFC6455]. [RFC6455].
When the 'ws-uri' attribute is present in the media section of the When the 'ws-uri' attribute is present in the media section of the
SDP, the IP address in 'c= ' line SHALL be ignored and the full URI SDP, the IP address in 'c= ' line SHALL be ignored and the full URI
SHALL be used instead to open the WebSocket connection. The port SHALL be used instead to open the WebSocket connection. The clients
provided in the 'm= ' line SHALL be ignored too, as the 'a=ws-uri' MUST ensure that they use the URI to open the webSocket connection
SHALL provide port number when needed. and ignore the IP address in 'c=' line and port in m= line.
3.3. wss-uri SDP Attribute 3.3. wss-uri SDP Attribute
This section defines a new SDP media-level attribute, 'wss-uri' which This section defines a new SDP media-level attribute, 'wss-uri' which
can appear in any of the media sections. can appear in any of the media sections.
Example: Example:
a=wss-uri:wss://example.com/chat a=wss-uri:wss://example.com/chat
Here "wss://example.com/chat" is the wss-URI defined in Section 3 of Here "wss://example.com/chat" is the wss-URI defined in Section 3 of
[RFC6455]. [RFC6455].
When the 'wss-uri' attribute is present in the media section of the When the 'wss-uri' attribute is present in the media section of the
SDP, the IP address in 'c= ' line SHALL be ignored and the full URI SDP, the IP address in 'c= ' line SHALL be ignored and the full URI
SHALL be used instead to open the secure WebSocket connection. The SHALL be used instead to open the WebSocket connection. The clients
port provided in the 'm= ' line SHALL be ignored too, as the 'a=wss- MUST ensure that they use the URI to open the webSocket connection
uri' SHALL provide port number when needed. and ignore the IP address in 'c=' line and port in m= line.
3.4. ws-uri and wss-uri Multiplexing Considerations 3.4. ws-uri and wss-uri Multiplexing Considerations
Multiplexing characteristics of SDP attributes are described in Multiplexing characteristics of SDP attributes are described in
[I-D.ietf-mmusic-sdp-mux-attributes]. Various SDP attribute [I-D.ietf-mmusic-sdp-mux-attributes]. Various SDP attribute
multiplexing categories are introduced there. multiplexing categories are introduced there.
o The multiplexing category of the "a=ws-uri:" attribute is CAUTION. o The multiplexing category of the "a=ws-uri:" attribute is CAUTION.
o The multiplexing category of the "a=wss-uri:" attribute is o The multiplexing category of the "a=wss-uri:" attribute is
skipping to change at page 5, line 46 skipping to change at page 5, line 46
indicate the same in the "proto" field of the "m=" line. For indicate the same in the "proto" field of the "m=" line. For
example, to negotiate BFCP-over-WebSocket the "proto" value in the example, to negotiate BFCP-over-WebSocket the "proto" value in the
"m=" line MUST be TCP/WSS/BFCP if WebSocket is over TLS, else it MUST "m=" line MUST be TCP/WSS/BFCP if WebSocket is over TLS, else it MUST
be TCP/WS/BFCP. be TCP/WS/BFCP.
The offerer SHOULD assign the SDP "setup" attribute with a value of The offerer SHOULD assign the SDP "setup" attribute with a value of
"active" (the offerer will be the initiator of the outgoing TCP "active" (the offerer will be the initiator of the outgoing TCP
connection), unless the offerer insists on being a receiver of an connection), unless the offerer insists on being a receiver of an
incoming connection, in which case the offerer SHOULD use a value of incoming connection, in which case the offerer SHOULD use a value of
"passive". The offerer MUST NOT assign an SDP "setup" attribute with "passive". The offerer MUST NOT assign an SDP "setup" attribute with
a "holdconn" value. If the offerer assigns the SDP "setup" attribute a "holdconn" value.
with a value of "passive", the offerer MUST be prepared to receive an
incoming TCP connection on the IP and port tuple advertised in the
"c=" line and audio/video ports of the BFCP media stream before it
receives the SDP answer.
The following is an example of an "m=" line for a BFCP connection: The following is an example of an "m=" line for a BFCP connection:
Offer (browser): Offer (browser):
m=application 9 TCP/WSS/BFCP * m=application 9 TCP/WSS/BFCP *
a=setup:active a=setup:active
a=connection:new a=connection:new
a=floorctrl:c-only a=floorctrl:c-only
m=audio 55000 RTP/AVP 0 m=audio 55000 RTP/AVP 0
m=video 55002 RTP/AVP 31 m=video 55002 RTP/AVP 31
skipping to change at page 7, line 23 skipping to change at page 7, line 23
a=floorid:1 m-stream:10 a=floorid:1 m-stream:10
a=floorid:2 m-stream:11 a=floorid:2 m-stream:11
m=audio 50002 RTP/AVP 0 m=audio 50002 RTP/AVP 0
a=label:10 a=label:10
m=video 50004 RTP/AVP 31 m=video 50004 RTP/AVP 31
a=label:11 a=label:11
4.4. Offerer Processing of the Answer 4.4. Offerer Processing of the Answer
When the offerer receives an SDP answer, if the offerer ends up being When the offerer receives an SDP answer, if the offerer ends up being
active it MUST initiate the WebSocket connection handshake by sending active it MUST follow the procedures in Section 5.
a GET message on the negotiated media stream, towards the IP address
and port of the answerer, as per the procedures described in
[RFC6455].
4.5. Modifying the Session 4.5. Modifying the Session
Once an offer/answer exchange has been completed, either endpoint MAY Once an offer/answer exchange has been completed, either endpoint MAY
send a new offer in order to modify the session. The endpoints can send a new offer in order to modify the session. The endpoints can
reuse the existing WebSocket connection by adding reuse the existing WebSocket connection by adding
"a=connection:existing" attribute in the media section of SDP "a=connection:existing" attribute in the media section of SDP
following the rules mentioned in [RFC4145] if the ws-uri values and following the rules mentioned in [RFC4145] if the ws-uri values and
the transport parameters indicated by each endpoint are unchanged. the transport parameters indicated by each endpoint are unchanged.
Otherwise, following the rules for the initial offer/answer exchange, Otherwise, following the rules for the initial offer/answer exchange,
skipping to change at page 8, line 5 skipping to change at page 7, line 48
In some scenarios an endpoint (e.g., a browser) originating the call In some scenarios an endpoint (e.g., a browser) originating the call
(UAC) can send an offerless INVITE to the server. The server will (UAC) can send an offerless INVITE to the server. The server will
generate an offer in response to the INVITE. In such cases the generate an offer in response to the INVITE. In such cases the
server MUST send an offer with setup attribute as "passive" so as to server MUST send an offer with setup attribute as "passive" so as to
accept incoming connection and MUST include "a=wss-uri" or "a=ws-uri" accept incoming connection and MUST include "a=wss-uri" or "a=ws-uri"
attribute in the media section depending on whether the server wishes attribute in the media section depending on whether the server wishes
to use WebSocket or secure WebSocket. The SDP offer sent by the to use WebSocket or secure WebSocket. The SDP offer sent by the
server will look like the example in Section 4.3. server will look like the example in Section 4.3.
5. Security Considerations 5. Procedures at WebSocket Client
The webSocket client MUST always initiate the outgoing TCP connection
and hence the SDP a=setup attribute MUST be always "active" for the
WebSocket client in its SDP offer/answer. In the below example, the
WebSocket client is the offerer and hence assigns "setup" attribute
with a value of "active".
The WebSocket server is a server on Internet and hence MUST always
assign SDP "setup" attribute with a value of "passive". This also
avoids the need to use ICE between WebSocket Client and WebSocket
Server as the connection model here would be a typical client to
server web connection.
Once the offer/answer is complete the client MUST initiate the
WebSocket connection handshake by sending a GET message on the
negotiated media stream, towards the IP address and port of the
answerer, as per the procedures described in [RFC6455]. If there are
multiple records returned for the connection URI in the "a=wss-uri"
or "a=ws-uri" then the clients MAY use procedures in Section 4 of
[RFC6555] to attempt the connection towards the server. When no port
is passed in the "a=wss-uri" or "a=ws-uri" attribute, the default
ports (80 or 443) is used.
6. Security Considerations
An attacker may attempt to add, modify, or remove 'a=ws-uri' or An attacker may attempt to add, modify, or remove 'a=ws-uri' or
'a=wss-uri' attribute from a session description. This could result 'a=wss-uri' attribute from a session description. This could result
in an application behaving undesirably. Consequently, it is strongly in an application behaving undesirably. Consequently, it is strongly
RECOMMENDED that integrity protection be applied to the SDP session RECOMMENDED that integrity protection be applied to the SDP session
descriptions. For session descriptions carried in SIP [RFC3261], S/ descriptions. For session descriptions carried in SIP [RFC3261], S/
MIME is the natural choice to provide such end-to-end integrity MIME is the natural choice to provide such end-to-end integrity
protection. protection.
It is also RECOMMENDED that the application signaling traffic being It is also RECOMMENDED that the application signaling traffic being
transported over a WebSocket communication session be protected by transported over a WebSocket communication session be protected by
using a secure WebSocket connection (using TLS [RFC5246] over TCP). using a secure WebSocket connection (using TLS [RFC5246] over TCP).
6. IANA Considerations The WebSocket clients have to initiate the TCP connection to the
WebSocket server identified by the FQDN in a=ws/a=wss-uri. Further
as with any other web connection, the clients will verify the servers
certificate. The WebSocket client MUST follow the procedures in
[RFC7525] while setting up TLS connection with webSocket server.
6.1. Registration of the 'ws-uri' SDP Media Attribute 7. IANA Considerations
7.1. Registration of the 'ws-uri' SDP Media Attribute
NOTE to RFC Editor: Please replace "XXXX" with the number of this NOTE to RFC Editor: Please replace "XXXX" with the number of this
RFC. RFC.
This document defines a new SDP media-level attribute "ws-uri" in This document defines a new SDP media-level attribute "ws-uri" in
Section 3.2 and requests that IANA to register the following SDP att- Section 3.2 and requests that IANA to register the following SDP att-
field under the Session Description Protocol (SDP) Parameters field under the Session Description Protocol (SDP) Parameters
registry as follows: registry as follows:
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
skipping to change at page 8, line 47 skipping to change at page 9, line 23
| Charset Dependent: | No | | Charset Dependent: | No |
| Purpose: | The 'ws-uri' attribute is intended to be | | Purpose: | The 'ws-uri' attribute is intended to be |
| | used as a connection URI for opening the | | | used as a connection URI for opening the |
| | WebSocket connection. | | | WebSocket connection. |
| Appropriate values: | A ws-URI as defined in [RFC6455] | | Appropriate values: | A ws-URI as defined in [RFC6455] |
| Contact name: | Gonzalo Salgueiro | | Contact name: | Gonzalo Salgueiro |
| Contact e-mail: | gsalguei@cisco.com | | Contact e-mail: | gsalguei@cisco.com |
| Reference: | RFCXXXX | | Reference: | RFCXXXX |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
6.2. Registration of the 'wss-uri' SDP Media Attribute 7.2. Registration of the 'wss-uri' SDP Media Attribute
NOTE to RFC Editor: Please replace "XXXX" with the number of this NOTE to RFC Editor: Please replace "XXXX" with the number of this
RFC. RFC.
This document defines a new SDP media-level attribute "wss-uri" in This document defines a new SDP media-level attribute "wss-uri" in
Section 3.3 and requests that IANA to register the following SDP att- Section 3.3 and requests that IANA to register the following SDP att-
field under the Session Description Protocol (SDP) Parameters field under the Session Description Protocol (SDP) Parameters
registry as follows: registry as follows:
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
skipping to change at page 9, line 27 skipping to change at page 10, line 5
| Purpose: | The 'wss-uri' attribute is intended to be | | Purpose: | The 'wss-uri' attribute is intended to be |
| | used as a connection URI for opening the | | | used as a connection URI for opening the |
| | WebSocket connection over a secure | | | WebSocket connection over a secure |
| | transport. | | | transport. |
| Appropriate values: | A wss-URI as defined in [RFC6455] | | Appropriate values: | A wss-URI as defined in [RFC6455] |
| Contact name: | Gonzalo Salgueiro | | Contact name: | Gonzalo Salgueiro |
| Contact e-mail: | gsalguei@cisco.com | | Contact e-mail: | gsalguei@cisco.com |
| Reference: | RFCXXXX | | Reference: | RFCXXXX |
+---------------------+---------------------------------------------+ +---------------------+---------------------------------------------+
7. Acknowledgements 8. Acknowledgements
Thanks to Christer Holmberg for raising the need for a BFCP- Thanks to Christer Holmberg for raising the need for a BFCP-
independent SDP attribute for WebSocket Connection URI. independent SDP attribute for WebSocket Connection URI.
The authors wish to acknowledge Paul Kyzivat, Suhas Nandakumar, The authors wish to acknowledge Paul Kyzivat, Suhas Nandakumar,
Christer Holmberg and Charles Eckel for their invaluable suggestions Christer Holmberg, Charles Eckel and Dan Wing for their invaluable
and review comments. suggestions and review comments.
8. References 9. References
8.1. Normative References 9.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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
DOI 10.17487/RFC4145, September 2005, DOI 10.17487/RFC4145, September 2005,
<http://www.rfc-editor.org/info/rfc4145>. <http://www.rfc-editor.org/info/rfc4145>.
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, DOI 10.17487/RFC6455, December 2011, RFC 6455, DOI 10.17487/RFC6455, December 2011,
<http://www.rfc-editor.org/info/rfc6455>. <http://www.rfc-editor.org/info/rfc6455>.
8.2. Informative References 9.2. Informative References
[I-D.ietf-bfcpbis-bfcp-websocket] [I-D.ietf-bfcpbis-bfcp-websocket]
Pascual, V., Roman, A., Cazeaux, S., Salgueiro, G., R, R., Pascual, V., Roman, A., Cazeaux, S., Salgueiro, G., R, R.,
and S. Murillo, "The WebSocket Protocol as a Transport for and S. Murillo, "The WebSocket Protocol as a Transport for
the Binary Floor Control Protocol (BFCP)", draft-ietf- the Binary Floor Control Protocol (BFCP)", draft-ietf-
bfcpbis-bfcp-websocket-10 (work in progress), June 2016. bfcpbis-bfcp-websocket-10 (work in progress), June 2016.
[I-D.ietf-bfcpbis-rfc4582bis] [I-D.ietf-bfcpbis-rfc4582bis]
Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C. Camarillo, G., Drage, K., Kristensen, T., Ott, J., and C.
Eckel, "The Binary Floor Control Protocol (BFCP)", draft- Eckel, "The Binary Floor Control Protocol (BFCP)", draft-
ietf-bfcpbis-rfc4582bis-16 (work in progress), November ietf-bfcpbis-rfc4582bis-16 (work in progress), November
2015. 2015.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-13 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-14
(work in progress), June 2016. (work in progress), September 2016.
[I-D.pd-dispatch-msrp-websocket] [I-D.pd-dispatch-msrp-websocket]
Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G., Dunkley, P., Llewellyn, G., Pascual, V., Salgueiro, G.,
and R. R, "The WebSocket Protocol as a Transport for the and R. R, "The WebSocket Protocol as a Transport for the
Message Session Relay Protocol (MSRP)", draft-pd-dispatch- Message Session Relay Protocol (MSRP)", draft-pd-dispatch-
msrp-websocket-12 (work in progress), May 2016. msrp-websocket-15 (work in progress), August 2016.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
[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,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<http://www.rfc-editor.org/info/rfc3261>. <http://www.rfc-editor.org/info/rfc3261>.
skipping to change at page 11, line 10 skipping to change at page 11, line 40
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure [RFC6101] Freier, A., Karlton, P., and P. Kocher, "The Secure
Sockets Layer (SSL) Protocol Version 3.0", RFC 6101, Sockets Layer (SSL) Protocol Version 3.0", RFC 6101,
DOI 10.17487/RFC6101, August 2011, DOI 10.17487/RFC6101, August 2011,
<http://www.rfc-editor.org/info/rfc6101>. <http://www.rfc-editor.org/info/rfc6101>.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, DOI 10.17487/RFC6555, April
2012, <http://www.rfc-editor.org/info/rfc6555>.
[RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual, [RFC7118] Baz Castillo, I., Millan Villegas, J., and V. Pascual,
"The WebSocket Protocol as a Transport for the Session "The WebSocket Protocol as a Transport for the Session
Initiation Protocol (SIP)", RFC 7118, Initiation Protocol (SIP)", RFC 7118,
DOI 10.17487/RFC7118, January 2014, DOI 10.17487/RFC7118, January 2014,
<http://www.rfc-editor.org/info/rfc7118>. <http://www.rfc-editor.org/info/rfc7118>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7395] Stout, L., Ed., Moffitt, J., and E. Cestari, "An [RFC7395] Stout, L., Ed., Moffitt, J., and E. Cestari, "An
Extensible Messaging and Presence Protocol (XMPP) Extensible Messaging and Presence Protocol (XMPP)
Subprotocol for WebSocket", RFC 7395, Subprotocol for WebSocket", RFC 7395,
DOI 10.17487/RFC7395, October 2014, DOI 10.17487/RFC7395, October 2014,
<http://www.rfc-editor.org/info/rfc7395>. <http://www.rfc-editor.org/info/rfc7395>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
[WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012. [WS-API] W3C and I. Hickson, Ed., "The WebSocket API", May 2012.
Authors' Addresses Authors' Addresses
Ram Mohan Ravindranath Ram Mohan Ravindranath
Cisco Systems, Inc. Cisco Systems, Inc.
Cessna Business Park, Cessna Business Park,
Kadabeesanahalli Village, Varthur Hobli, Kadabeesanahalli Village, Varthur Hobli,
Sarjapur-Marathahalli Outer Ring Road Sarjapur-Marathahalli Outer Ring Road
Bangalore, Karnataka 560103 Bangalore, Karnataka 560103
 End of changes. 22 change blocks. 
50 lines changed or deleted 83 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/