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]
