WG MMUSIC Keith Drage, Ed. Internet Draft Juergen Stoetzer-Bradler Intended status: Standards track Albrecht Schwarz Expires: October 2016 Nokia April 4, 2016 BFCP floor control signalling over Data Channels draft-schwarz-mmusic-bfcp-usage-data-channel-02.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on October 4, 2016. Schwarz Expires October 4, 2016 [Page 1] Internet-Draft BFCP over Data Channels April 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document specifies how the Binary Floor Control Protocol (BFCP) can be instantiated as a data channel sub-protocol, using the SDP offer/answer exchange-based external negotiation defined in [I- D.ietf-mmusic-data-channel-sdpneg]. Two network configurations are documented: a WebRTC end-to-end configuration (connecting two BFCP over data channel endpoints), and a gateway configuration (connecting an BFCP over data channel endpoint with an BFCP over (TLS)/TCP/IP (or over (DTLS)/UDP/IP) endpoint). Table of Contents 1. Introduction...................................................3 1.1. Motivation................................................3 1.2. Framework of WebRTC data applications.....................4 2. Conventions....................................................4 2.1. Prescriptive language.....................................4 2.2. Notation..................................................4 3. Terminology and abbreviations..................................4 3.1. Terminology used..........................................4 3.1.1. Terminology specific for WebRTC data channel control.5 3.1.2. Terminology specific to the IP application protocol 'BFCP'......................................................5 3.2. Abbreviations used........................................6 4. Prinicples.....................................................6 4.1. BFCP Data Channel.........................................6 4.2. Session Mapping...........................................7 4.3. BFCP endpoint.............................................7 4.4. Association between conference media streams and their conference floor...............................................7 4.4.1. Background (non-WebRTC conferences)..................7 4.4.2. Association in WebRTC conferences....................7 5. End-to-End Configuration.......................................8 Schwarz Expires October 4, 2016 [Page 2] Internet-Draft BFCP over Data Channels April 2016 5.1. Basic BFCP Support........................................8 5.1.1. Session Negotiation..................................8 5.1.1.1. Use of dcmap Attribute..........................8 5.1.1.2. Use of dcsa Attribute...........................8 5.1.1.3. Example SDP Negotiation.........................9 5.1.2. Session Opening.....................................10 5.1.3. Data Framing........................................10 5.1.4. Data Sending and Reporting..........................10 5.1.5. Session Closing.....................................10 5.2. Support of BFCP-specific Functions.......................10 6. Gateway Configurations........................................10 6.1. Introduction.............................................10 6.2. Gateway-embedded Interworking Functions for BFCP.........10 6.3. Example gateway configuration in more detail.............11 7. Security Considerations.......................................11 8. IANA Considerations...........................................11 9. References....................................................11 9.1. Normative References.....................................11 9.2. Informative References...................................12 10. Acknowledgments..............................................12 11. CHANGE LOG...................................................14 11.1. Initial draft-schwarz-mmusic-bfcp-usage-data-channel-00.14 11.2. Changes against draft-schwarz-mmusic-bfcp-usage-data- channel-01....................................................14 11.3. Changes against draft-schwarz-mmusic-bfcp-usage-data- channel-02....................................................14 1. Introduction 1.1. Motivation The Binary Floor Control Protocol (BFCP) is basically used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers [RFC4582]. BFCP messages are transported either a) preferably in a reliable manner, using either unsecured TCP connections or TLS-secured TCP connections; or b) alternatively using the unreliable UDP, either unsecured or DTLS- secured DTLS connections. The UDP option is motivated by potential NAT traversal issues. Clause 6 in [RFC4582bis] describes all that legacy BFCP transport options for native BFCP endpoints (i.e., not using WebRTC). Schwarz Expires October 4, 2016 [Page 3] Internet-Draft BFCP over Data Channels April 2016 The indication and negotiation of such BFCP transports at call control signalling level is based on SDP offer/answer procedures and defined by [RFC4583] and [RFC4583bis]. WebRTC introduces another protocol stack for transporting BFCP, i.e., there are impacts and modifications related to the SDP offer/answer. Purpose of this RFC is to define the WebRTC-specific SDP signalling for BFCP-based floor control in WebRTC. 1.2. Framework of WebRTC data applications There are multiple IP application protocols which using WebRTC data channels as transport, such as MSRP or T.140 besides BFCP. The SDP- based indication and negotiation of such WebRTC data applications at call control signalling level follows common principles. The first WebRTC application from this suite is/was the MSRP-based instant messaging service for WebRTC, see [I-D.ietf-mmusic-msrp-usage-data- channel]. This specification for BFCP was derived from that document and uses an aligned clause structuring. It may be noted that the BFCP protocol as such is simpler in comparison to the MSRP, which requires an extended set of SDP elements (in comparison to BFCP) for the description of specific MSRP services and their protocol parameter settings. The NAT traversal situation at IP application protocol layer ("Layer(s) 4+") is also simpler for BFCP than for MSRP because BFCP does not carry network and/or transport address information in the BFCP message. 2. Conventions 2.1. Prescriptive language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. 2.2. Notation None. 3. Terminology and abbreviations 3.1. Terminology used This document uses the following terms: Schwarz Expires October 4, 2016 [Page 4] Internet-Draft BFCP over Data Channels April 2016 3.1.1. Terminology specific for WebRTC data channel control Data channel: A WebRTC data channel as specified in [I-D.ietf- rtcweb-data-channel]. BFCP data channel: A data channel specifically used to transport the text and presentation control information of one BFCP session. NOTE - The notion of "BFCP session" relates not necessarily to a single "SIP session", i.e., a single WebRTC call, see clause 4.2. External negotiation: Data channel negotiation based on out-of-band or in-band mechanisms other than the Data Channel Establishment Protocol specified in [I-D.ietf-rtcweb-data-protocol]. In-band: Transmission through the peer-to-peer SCTP association. Out-of-band: Transmission through the call control signaling path, e.g., using JSEP [I-D.ietf-rtcweb-jsep] and the SDP Offer/Answer model [RFC3264]. Peer: From the perspective of one of the agents in a session, its peer is the other agent. Specifically, from the perspective of the SDP offerer, the peer is the SDP answerer. From the perspective of the SDP answerer, the peer is the SDP offerer 3.1.2. Terminology specific to the IP application protocol 'BFCP' Client: see clause 2/[RFC4582]. Floor: A temporary permission to access or manipulate a specific shared resource or set of resources (see clause 2/[RFC4582]). Floor Chair: see clause 2/[RFC4582]. Floor Control: see clause 2/[RFC4582]. Floor Control Server: see clause 2/[RFC4582]. Floor Participant: see clause 2/[RFC4582]. Media Participant: see clause 2/[RFC4582]. Participant: see clause 2/[RFC4582]. Schwarz Expires October 4, 2016 [Page 5] Internet-Draft BFCP over Data Channels April 2016 3.2. Abbreviations used BFCP Binary Floor Control Protocol DTLS Datagram Transport Layer Security GCP Gateway Control Protocol ITU-T International Telecommunication Union Telecommunication Standardization Sector IWF Interworking Function JSEP Javascript Session Establishment Protocol MG (H.248) Media Gateway MGC (H.248) Media Gateway Controller SCTP Stream Control Transmission Protocol SDP Session Description Protocol SIP Session Initiation Protocol TCP Transmission Control Protocol TLS Transport Layer Security UA User Agent UDP User Datagram Protocol WebRTC Web Real-Time Communication 4. Prinicples 4.1. BFCP Data Channel In this document, an BFCP data channel is a data channel for which the instantiated sub-protocol is "BFCP", and where the BFCP-related negotiation is done as part of the SDP-based external negotiation method defined in [I-D.ietf-mmusic-data-channel-sdpneg]. Schwarz Expires October 4, 2016 [Page 6] Internet-Draft BFCP over Data Channels April 2016 4.2. Session Mapping In this design, the BFCP "session" maps to the SCTP association and the "SCTP stream pair" assigned to the data channel, and each BFCP "session" maps to one data channel exactly. 4.3. BFCP endpoint A BFCP endpoint represents in the domain of the o conferencing service: a "floor participant", a "floor chair" or a "floor control server" (see clause 3 in [RFC4582]); o signalling plane: a "client only", a "server only" or "client and server" role behaviour (see clause 4 in [RFC4583]). The signalling role characteristic is of primary interest in this RFC due to its scope on WebRTC client-embedded BFCP endpoints. 4.4. Association between conference media streams and their conference floor 4.4.1. Background (non-WebRTC conferences) A particular conference might be constituted by a single or multiple media streams. And their might be a single or multiple (static or temporary) floors per conference enabled. There are consequently one or more media streams "under the auspices of" a specific floor. That relationship is signalled via the SDP 'floorid' attribute (see clause 6 in [RFC4583]), which links a set of media streams to a specific floor. 4.4.2. Association in WebRTC conferences A conference media stream might be principally WebRTC audio, video and data streams (to be confirmed). The media stream parameter 'mstrm' in the SDP 'floorid' attribute needs consequently to be linked to a particular WebRTC media component. The binding is basically achieved by labelling a SDP media description (i.e., a WebRTC media component behind a SDP "m="- line section) using the [RFC4574] SDP "a=label:" attribute. Editor's note 1: above assumption needs to be confirmed Editor's note 2: a SDP example might be beneficial ... Schwarz Expires October 4, 2016 [Page 7] Internet-Draft BFCP over Data Channels April 2016 5. End-to-End Configuration This section describes the network configuration where each BFCP endpoint is running BFCP over a data channel. 5.1. Basic BFCP Support 5.1.1. Session Negotiation 5.1.1.1. Use of dcmap Attribute The SDP offer shall include a dcmap attribute line (defined in [I- D.ietf-mmusic-data-channel-sdpneg], within the media description for the SCTP association for each BFCP data channel session to be negotiated. The attribute includes the following data channel parameters: o "label=" labelstring o "subprotocol=" "BFCP" The labelstring is set by the BFCP application according to [I- D.ietf-mmusic-data-channel-sdpneg]. The max-retr, max-time and ordered parameters shall not be used. Rest of the SDP offer/answer procedures are per [I-D.ietf-mmusic- data-channel-sdpneg]. The following is an example of the dcmap attribute for an BFCP session to be negotiated (on default SCTP port 5000) with stream=4 and without any label: a=dcmap:4 subprotocol="BFCP" 5.1.1.2. Use of dcsa Attribute The SDP offer SHALL also include a dcsa attribute line (defined in [I-D.ietf-mmusic-data-channel-sdpneg]) within the media description for the SCTP association for each BFCP-specific SDP attribute to be negotiated for each BFCP data channel being negotiated. The BFCP-specific items that can be negotiated include at least following well-known attributes: Schwarz Expires October 4, 2016 [Page 8] Internet-Draft BFCP over Data Channels April 2016 o defined in [RFC4583]: "floorctrl", "confid", "userid", "floorid"; o defined in [RFC4583bis]: "bfcpver"; and o defined in [RFC4574]: "label". FIXTHIS ("any SDP attribute specific normative semantics? see MSRP ...") The SDP answer shall include zero or more corresponding dcsa attribute lines for each negotiated BFCP session, according to the BFCP-specific attribute negotiation rules in the corresponding specifications. A new SDP offer/answer may update the BFCP subprotocol attribute(s) while keeping the same subprotocol a=dcmap description. 5.1.1.3. Example SDP Negotiation The following is an example of an "m"-line for data channels in an SDP offer that includes the attributes needed to establish a BFCP session: m=application 21212 /DTLS/SCTP webrtc-datachannel c=IN IP4 11.9.19.65 a=max-message-size:1000 ; NOTE 1 a=sctp-port 5000 a=dcmap:1 label="floor control";subprotocol="BFCP" a=dcsa:1 floorctrl:s-only ; "floor control server only" a=dcsa:1 confid:4321 ; NOTE 2 a=dcsa:1 userid:1234 ; NOTE 3 a=dcsa:1 floorid: 1 mstrm:3 7 ; NOTE 4 NOTE 1 - Much smaller than e.g. MSRP. The purpose of "binary encoding" use in BFCP is to minimize BFCP message sizes! NOTE 2 - Conference identifier of the WebRTC embedded conferencing service. NOTE 3 - User identifier. There is a 1:1 relationship between a WebRTC client and an embedded BFCP user. (to be confirmed) NOTE 4 - Two WebRTC media components (labelled with identifiers '3' and '7') are subject of floor control. (to be confirmed) Editor's note 1: above assumption needs to be confirmed Schwarz Expires October 4, 2016 [Page 9] Internet-Draft BFCP over Data Channels April 2016 Editor's note 2: the example should be expanded in order to illustrate the location of the two labels "a=label:3" and "a=label:7" within the entire SDP offer. 5.1.2. Session Opening FIXTHIS 5.1.3. Data Framing FIXTHIS 5.1.4. Data Sending and Reporting Data sending and reporting procedures SHALL conform to [RFC4582]. 5.1.5. Session Closing FIXTHIS 5.2. Support of BFCP-specific Functions FIXTHIS 6. Gateway Configurations 6.1. Introduction FIXTHIS 6.2. Gateway-embedded Interworking Functions for BFCP FIXTHIS Schwarz Expires October 4, 2016 [Page 10] Internet-Draft BFCP over Data Channels April 2016 6.3. Example gateway configuration in more detail FIXTHIS 7. Security Considerations FIXTHIS 8. IANA Considerations FIXTHIS 9. References 9.1. Normative References [RFC2119] RFC 2119 (03/1997), "Key words for use in RFCs to Indicate Requirement Levels", BCP 14. [RFC3264] RFC 3264 (06/2002), "An Offer/Answer Model with the Session Description Protocol (SDP)". [RFC4566] RFC 4566 (07/2006), "SDP: Session Description Protocol". [RFC4574] RFC 4574 (08/2006), "The Session Description Protocol (SDP) Label Attribute". [RFC4582] RFC 4582 (11/2006), "The Binary Floor Control Protocol (BFCP)". [RFC4582bis] draft-ietf-bfcpbis-rfc4582bis (09/2015), "The Binary Floor Control Protocol (BFCP)". [RFC4583] RFC 4583 (11/2006), "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams". [RFC4583bis] draft-ietf-bfcpbis-rfc4583bis (09/2015), "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams". [I-D.ietf-rtcweb-data-protocol] draft-ietf-rtcweb-data-channel (##/2015), "WebRTC Data Channel Establishment Protocol". Schwarz Expires October 4, 2016 [Page 11] Internet-Draft BFCP over Data Channels April 2016 [I-D.ietf-rtcweb-data-channel] http://tools.ietf.org/wg/rtcweb/draft-ietf-rtcweb-data- channel/draft-ietf-rtcweb-data-channel (##/2015), "WebRTC Data Channels". [I-D.ietf-mmusic-data-channel-sdpneg] draft-ietf-mmusic-data- channel-sdpneg (##/2015), "SDP-based Data Channel Negotiation". [I-D.ietf-mmusic-msrp-usage-data-channel] draft-ietf-mmusic-msrp- usage-data-channel (##/2015), "MSRP over Data Channels". 9.2. Informative References [RFC4376] RFC 4376 (02/2006), "Requirements for Floor Control Protocols". [I-D.ietf-rtcweb-gateways] draft-ietf-rtcweb-gateways (##/2015), "WebRTC Gateways". [ITU-T H.248.94] Recommendation ITU-T H.248.94 (10/2015), "Web- based real-time communication services - H.248 protocol support and profile guidelines". Status: still work in progress in ITU-T SG16 Question 3 Free copy via: FIXTHIS [3GPP 29.334] 3GPP TS 29.334 Release 13 (2015), "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; IMS Application Level Gateway (IMS-ALG) - IMS Access Gateway (IMS-AGW); Iq Interface; Stage 3". Free copy via: ftp://ftp.3gpp.org/specs/archive/29_series/29.334/ 10. Acknowledgments FIXTHIS Schwarz Expires October 4, 2016 [Page 12] Internet-Draft BFCP over Data Channels April 2016 Authors' Addresses Keith Drage (editor) Nokia Quadrant, Stonehill Green, Westlea Swindon UK Email: keith.drage@nokia.com Dr. Juergen Stoetzer-Bradler Nokia Lorenzstrasse 10 D-70435 Stuttgart GERMANY Email: Juergen.Stoetzer-Bradler@nokia.com Dr. Albrecht Schwarz Nokia Lorenzstrasse 10 D-70435 Stuttgart GERMANY Email: Albrecht.Schwarz@nokia.com Schwarz Expires October 4, 2016 [Page 13] Internet-Draft BFCP over Data Channels April 2016 11. CHANGE LOG 11.1. Initial draft-schwarz-mmusic-bfcp-usage-data-channel-00 o The initial document represents a skeleton where almost all clauses are still empty. o The intention is to propose a document structure aligned with the MSRP draft. 11.2. Changes against draft-schwarz-mmusic-bfcp-usage-data-channel-01 o transport level security added for native BFCP transport (BFCP/TLS/TCP/IP, BFCP/DTLS/UDP/IP) o initial input text for some "placeholder sections" added, which is basically aligned with the MSRP draft 11.3. Changes against draft-schwarz-mmusic-bfcp-usage-data-channel-02 o Editorial: update of author addresses Schwarz Expires October 4, 2016 [Page 14]