Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation)

[Michael Thornburgh <[e-mail]>]

> From: rtcweb [mailto:[e-mail]] On Behalf Of Mary Barnes
> Sent: Monday, April 07, 2014 12:32 PM
> 
> On Mon, Apr 7, 2014 at 2:27 PM, Matthew Kaufman (SKYPE) <[e-mail]> wrote:
> 
> 	-----Original Message-----
> 	> From: rtcweb [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> 	> Sent: Monday, April 7, 2014 12:22 PM
> 	> To: [e-mail]
> 	> Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with
> 	> media isolation)
> 	>
> 	> On 4/7/14 1:27 PM, Matthew Kaufman (SKYPE) wrote:
> 	> >
> 	> > From: rtcweb [mailto:[e-mail]] On Behalf Of Harald
> 	> >> Alvestrand
> 	> >> ...
> 	> >> (and to Matthew: At least we wouldn't have *yet* another congestion
> 	> >> context to manage, which would be the case with a separate TCP
> 	> connection.
> 	> >> There are always tradeoffs.)
> 	> >
> 	> > If it was me (and at one time, it was) I would use a protocol that allows for
> 	> multiplexing and prioritization of media and data channels over the same
> 	> secure session with shared congestion state. Over such a protocol, opening
> 	> another data stream for this purpose could be done immediately without
> 	> even a round trip.
> 	> >
> 	> > RFC 7016 documents such an approach.
> 	>
> 	> I see that the title starts with "Adobe's". Sigh.
> 
> 	Yes, but there's little stopping many of these ideas from becoming the basis for an IETF-
> developed transport protocol that actually meets the needs we have here.
> 
> [MB] Except, maybe, IPR:
>  https://datatracker.ietf.org/ipr/search/?option=document_search&id=draft-thornburgh-adobe-rtmfp
> [/MB]

we would love for RTMFP to become the basis for an IETF-developed standard transport protocol.  and as far as using RTMFP as-is, note section VI of the (most recent) above-referenced IPR disclosure: "Royalty-Free, Reasonable and Non-Discriminatory License to All Implementers."  we think it's pretty good already and published it (among other reasons) in the hopes that others would find new uses for it.

> 	> If you want to entertain something other than existing solutions for media,
> 	> why not simply run the RTP media streams over SCTP along with the data
> 	> channels?
> 
> 	Except for some critical shortcomings of SCTP (which are being fixed), this isn't actually a
> terrible idea.

except for the critical shortcomings of SCTP (for real-time communications) that aren't being fixed.

> 	Matthew Kaufman

-michael thornburgh