Re: PeerConnection Data Channel

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,

Some thoughts follow... I'm assuming:

(a) We're negotiating DTLS-SRTP, so the appropriate stuff is already
in the SDP to do the fingerprint exchange, etc. However, we're going
to just send data as DTLS records intermixed with SRTP.
(b) That we want to signal the existence of the stream in SDP, even
though it's not to be used with RTP.

The API Justin suggested looks pretty OK. From a bits-on-the-wire
perspective, we need to address two issues:

(a) How do we layer the bits over DTLS?
(b) How do we signal the presence of a data stream in SDP?


DTLS LAYERING
Minimally, we want to package each write() as a DTLS record.  The
natural way to do this is to provide a record header that indicates
the stream. So, for instance, one could do something like:

  struct {
    uint16 stream_id;
    opaque data[];
  } StreamData;

If datagram-mode writes don't span DTLS records, this is all that's
required for datagram. For stream modes, we'd obviously need to
define whatever stream header was used to provide reliability, etc.
So, the receiving logic in the browser would look something like:

   processRecord(const unsigned char *data, size_t len) {
     uint16_t stream_id = ntohs(*((uint16_t *)data));
     data += 2;
     len-=2;

     if(streams_.find(stream_id) != streams_.end()){
       streams_[stream_id].dispatch(data, len);
     }
   }


SIGNALING IN SDP
Roughly speaking, we need to convey to the other side:

(a) the stream-id
(b) the application type

There are probably a number of possibilities here, and the
example Justin shows would work fine, except that it uses
an RTP payload type for data which won't ever appear in
RTP, which is a little inefficent, but probably harmless.

Another possibility... I'm not an SDP expert, but if we cheat a bit,
we might be able to encode this in an m-line like so:

   m=application <stream-id> <tbd> peerconnectiondatagram

Note that you're not allowed to use '-' in the fmt type, so
it's not totally great either.

I don't have any firm commitments here on how this should work
and am happy to defer to people who understand SDP better than
I. There are probably a lot of ways to encode this information
that would make sense.


With regard to your specific questions:

- Signalling the DTLS (not RTP) framing in SDP
See above.

- Supporting a single DTLS channel per PeerConnection
As noted above, you'd have one DTLS channel, but multiple peer
channels.

- How congestion control for the DTLS channel could work
This is a tough question. In general, I think we're going to have
to decide whether we want to do per-channel flow control or overall
flow control for each PeerConnection. If the former, the best thing
to do is layer a congestion control protocol on top of the stream.
Note that you will need to do this for stream transports anyway.
If the second.... that's a tougher one since we want it to span
RTP and raw data.

- Surely something I've forgotten.....
Me too.


Best,
-Ekr

Received on Friday, 9 September 2011 23:14:20 UTC