< 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/ |