Re: [MMUSIC] [dispatch] SDP negotiation of data channel sub-protocols

On Thu, Nov 7, 2013 at 12:33 PM, Hadriel Kaplan
<hadriel.kaplan@oracle.com>wrote:

>
> On Nov 7, 2013, at 1:39 AM, Harald Alvestrand <harald@alvestrand.no>
> wrote:
>
> > For normal (as I think of it) WebRTC usage, we want one m-line to
> > describe the SCTP association, and the channels are completely invisible.
>
> Sure for WebRTC, of course that's true - because they're all one media
> type: application.  Only the application above (the one in JS) knows what's
> in the specific SCTP channels, right?  My comment at the mic about this was
> for non-WebRTC cases, such as if we were to standardize MSRP, BFCP, fax,
> etc. on SCTP. (or at least that's what I thought Richard's proposal was
> for, but I could be misunderstanding it)
>
> [MB] The intent is for this to support non-WebRTC cases.  CLUE is another
example that could use this mechanism.

This is the proposed deliverables:

 – Define generic SDP procedures to enable external negotiation of
DataChannel transport for sub-protocol sessions, and to enable negotiation
of sub-protocol specific options.

– Describe how to use the generic SDP procedures negotiate DataChannel
transport for specific protocols, potentially including

MSRP, BFCP, T.140, T.38 and the CLUE control protocol.

I think part of the confusion is that the drafts were originally very
WebRTC centric.
[/MB]

> -hadriel
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>