Re: WebRTC and backpressure (how to stop reading?)

On 26 March 2014 09:17, Michael Tuexen <> wrote:
> Could you explain how you can the underlying SCTP channel supports
> backpressure per stream? SCTP supports a flow control which affects
> all streams, but not a flowcontrol per stream.

Oh dear - you're quite right! I hadn't looked at the code yet for the
case of multiple data channels. The fact that each DataChannel runs
over a single SCTP connection is a real nuisance then.

Let's imagine a complex app: someone's bound to implement a
torrent-like protocol on top of WebRTC at some point, which would
require several channels between peers. It's perfectly possible for an
app to want to block reading from one of the channels, eg the user
needs to select a download directory, or the application wants to show
a warning or security prompt before continuing to read from the
channel. We'd want to be able to continue to process data in the
background from the other channels though.

> It does not only have an ideal external interface, SCTP doesn't
> provide a flowcontrol per stream. Not ready data on one stream
> would affect the other streams...

>From my point of view then, the problem is using SCTP streams for the
data channels, rather than opening a new SCTP association for each
channel. We have every single port number available (because the port
numbers used to distinguish SCTP connections are encapsulated, private
to the WebRTC protocol).

What was the reasoning for using streams - simply to avoid the SCTP handshake?

The port number can apparently be selected currently using a "data
codec", some sort of a pseudo-codec with a port number property. I
don't know if Chrome/Firefox use that? The SCTP port numbers are
essentially unused, so I think it would be preferable just to make a
new SCTP connection per channel, with the SCTP port set to
`5001+$ssrc` (say). Then it would still be possible to change the base
port to 6001 if the protocol gets bumped up.

This would be a breaking change only to applications using more than
one data channel.


Nicholas Wilson:
Site and blog:

Received on Wednesday, 26 March 2014 13:19:26 UTC