Internet DRAFT - draft-schwarz-mmusic-bfcp-usage-data-channel

draft-schwarz-mmusic-bfcp-usage-data-channel



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