[dispatch] Charter proposal: SDP negotiation of DataChannel sub-protocols

["Ejzak, Richard P (Richard)" <[e-mail]>]

This is a charter proposal for "SDP negotiation of DataChannel sub-protocols" in accordance with the Oct.  7 deadline for dispatch.

The rtcweb DataChannel is the primary mechanism available for a WebRTC application to establish transport for media protocols other than audio and video, such as MSRP, BFCP, T.140, T.38 and the CLUE control protocol.  While WebSockets is an option for transport of some of these protocols, DataChannels provides a more general solution that works in all cases, particularly peer-to-peer cases.  Many applications using these kinds of protocols (usually based on SIP or XMPP) also expect to negotiate their use with SDP.

The rtcweb DataChannel design allows two means of creating a DataChannel: either via in-band negotiation, or external negotiation.  No external negotiation mechanism is defined in the core DataChannel specification to allow applications the freedom to choose how to perform the external negotiation.

We propose to charter work to:

1.       Define generic SDP procedures to enable external negotiation of DataChannel sub-protocols to establish DataChannel transport for sub-protocol sessions, and to negotiate the use of sub-protocol specific options.

2.       Describe how to use the generic SDP procedures defined in 1 to negotiate DataChannel transport for specific protocols, potentially including MSRP, BFCP, T.140, T.38 and the CLUE control protocol.

We envision that one draft is sufficient for item 1, and one draft per protocol is needed for item 2.  We provided an early draft in http://datatracker.ietf.org/doc/draft-marcon-msrp-over-webrtc-data-channels/ that describes a solution for 1 and provides details specific to MSRP.  We have split this document in two parts and made some significant revisions based on off-line discussions (including a bar bof in Berlin).  We intend to upload both new documents well in advance of the doc deadline.

Two high level issues were identified, which the new docs will attempt to address:

1.       How will DataChannel sub-protocols be registered (re-use an existing registry or create a new one) and if it's a new registry how to define the relationship to existing protocols.  This issue deserves additional review and discussion.

2.       Issues related to SCTP stream id assignment.  We have very recently concluded that there should be no impact on the DataChannel design as long as the application has free reign to create a DataChannel at each peer using the same stream id number.

Comments/support are encouraged.

Richard