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

"Matthew Kaufman (SKYPE)" <> Mon, 07 April 2014 19:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 74D621A082B for <>; Mon, 7 Apr 2014 12:40:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id caPs4dQJGUv9 for <>; Mon, 7 Apr 2014 12:40:14 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7B07F1A07F4 for <>; Mon, 7 Apr 2014 12:40:13 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.913.9; Mon, 7 Apr 2014 19:40:03 +0000
Received: from (2a01:111:f400:7c0c::193) by (2a01:111:e400:2c5d::19) with Microsoft SMTP Server (TLS) id 15.0.913.9 via Frontend Transport; Mon, 7 Apr 2014 19:40:04 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.918.6 via Frontend Transport; Mon, 7 Apr 2014 19:40:01 +0000
Received: from ([]) by ([]) with mapi id 14.03.0174.002; Mon, 7 Apr 2014 19:39:23 +0000
From: "Matthew Kaufman (SKYPE)" <>
To: Mary Barnes <>
Thread-Topic: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation)
Date: Mon, 07 Apr 2014 19:39:22 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10009001)(6009001)(438001)(199002)(377454003)(189002)(51704005)(50986001)(49866001)(20776003)(98676001)(95666003)(54316002)(99396002)(94316002)(84676001)(23756003)(33656001)(81542001)(79102001)(92726001)(93136001)(97186001)(6806004)(86362001)(90146001)(85306002)(63696002)(76796001)(87936001)(47776003)(2009001)(97336001)(44976005)(94946001)(97736001)(77096001)(54356001)(87266001)(77982001)(55846006)(83322001)(81686001)(19580395003)(80976001)(65816001)(56816005)(19580405001)(31966008)(74662001)(74502001)(74366001)(74706001)(81816001)(92566001)(47446002)(80022001)(66066001)(50466002)(74876001)(53806001)(15975445006)(81342001)(47976001)(47736001)(69226001)(93516002)(4396001)(76786001)(56776001)(46102001)(85852003)(2656002)(76482001)(59766001)(95416001)(83072002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR03MB025;; FPR:4C96F2F5.A5FAD7E5.3DD03D53.4CF69869.202A3; MLV:sfv; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0174BD4BDA
Received-SPF: Pass (: domain of designates as permitted sender) receiver=; client-ip=;;
Cc: "" <>
Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with media isolation)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 07 Apr 2014 19:40:18 -0000

From: rtcweb [] On Behalf Of Paul Kyzivat
> Sent: Monday, April 7, 2014 12:22 PM
> To:
> Subject: Re: [rtcweb] Isolating data channels (Re: Asking TLS for help with
> media isolation)
> > 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:

Conveniently, RTMFP was preceded by an open-source project which had no patents filed. so to the extent the "ideas" are present there (and many of them are), that's easily worked around, if one needed a starting place.

But my point wasn't to start discussing the merits of the specific approach described in that particular RFC... rather to note that the cobbled-together collection of choices that have been made, specifically gluing SCTP on to the side of RTCWEB as a way of transporting data, is highly suboptimal and that other solutions do exist.

In fact, simply allowing the data we need to be sent unsolicited as another SRTP stream would be an improvement over doing 2 round trips of SCTP setup for the problem space we are discussing in this thread.

Matthew Kaufman