W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2011

Re: PeerConnection Data Channel

From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 5 Sep 2011 06:35:44 -0700
Message-ID: <CABcZeBMKRKaAQE8WJmV0o7SUwOVZJTovh1jg3TT+XBZ96du2Lw@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: Matthew Kaufman <matthew.kaufman@skype.net>, Justin Uberti <juberti@google.com>, public-webrtc@w3.org
Yes, I can do this, but not before Thursday... I'm on vacation Mon-Wed
and just squeezing
in a tiny bit of email before I go. I should be able to get to it
before end of week.


On Mon, Sep 5, 2011 at 1:58 AM, Harald Alvestrand <harald@alvestrand.no> wrote:
> Eric, would it be possible for you to write up a description on roughly the
> same level of detail as Justin's on a solution that just uses DTLS to
> support a "send data" call on the PeerConnection API?
> I think that includes:
> - Signalling the DTLS (not RTP) framing in SDP
> - Supporting a single DTLS channel per PeerConnection
> - How congestion control for the DTLS channel could work
> - Surely something I've forgotten.....
>            Harald
> On 09/03/11 17:10, Eric Rescorla wrote:
>> On Fri, Sep 2, 2011 at 11:17 AM, Matthew Kaufman
>> <matthew.kaufman@skype.net>  wrote:
>>> On 9/2/11 7:12 PM, Justin Uberti wrote:
>>> On Fri, Sep 2, 2011 at 1:57 PM, Matthew
>>> Kaufman<matthew.kaufman@skype.net>
>>> 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.
>> -Ekr
Received on Monday, 5 September 2011 13:36:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:21 UTC