Re: PeerConnection Data Channel

On Fri, Sep 2, 2011 at 11:17 AM, Matthew Kaufman
<> wrote:
> On 9/2/11 7:12 PM, Justin Uberti wrote:
> On Fri, Sep 2, 2011 at 1:57 PM, Matthew Kaufman <>
> wrote:
>> On 9/2/11 6:52 PM, Justin Uberti wrote:
>>> I'm far from sold on RTP for this, but since I think we need a sequence
>>> number (for congestion control) and a stream id (for demux), it seems we're
>>> already halfway there. Will look at the other methods - do you recall if
>>> these were mentioned in a public draft or on the mailing list?
>> There were two IDs... Cary did a presentation at the last meeting and is
>> preparing a combined draft.
>> I believe there was discussion on the list as well from some RTP folks (or
>> maybe it was just at the microphone back in Prague?) about why putting data
>> in RTP is the wrong thing.
> Thanks, will look. Main concern is how SDES-SRTP works with something
> non-RTP. Maybe that isn't supported.
> It works fine... you just take the same SDES key you stuffed in (via
> Javascript, if we don't use SDP, perhaps) and encrypt with it.

It's actually rather more complicated than this: SRTP defines a wire protocol
that is designed to be used with external key management. You'd need to
define a new wire protocol for this application, which is sort of what this
document does, but... not well.

> DTLS is even
> more obvious of course.

Indeed. Experience has shown that designing even this kind of simple security
protocol is hard. In this case it seems extraordinarily inadvisable
given that we
have a well-defined IETF Standards Track protocol designed specifically for
the purpose of securing datagram transmissions.


Received on Saturday, 3 September 2011 15:13:28 UTC