Re: PeerConnection Data Channel

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 08:59:27 UTC