694808 - Implement data channels for WebRTC PeerConnections

Status: RESOLVED FIXED

(Core :: WebRTC: Networking, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

Per discussions, probably via SCTP-over-DTLS-over-UDP, with both reliable and unreliable channels.  The SCTP implementation will probably come from BSD

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

SCTP over DTLS over (ICE/UDP), per IETF

This is the master/meta bug

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Randell, it would be great to get some feedback from you what type of tests we would need here. Also do you have any documentation link available so I can read in this topic for all the different types of channels?

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

The documentation is largely the working-group archives.

The dictionary has this:

/* If either maxRetransmitTime or maxRetransmitNum are set, it's
   unreliable, else it's a reliable channel.  If both are set it's an
   error.  outOfOrderAllowed can be used with any type of channel.  The
   equivalent of UDP is { outOfOrderAllowed: true, maxRetransmitNum: 0 }.
   The TCP equivalent is {}. */
dictionary DataChannelInit {
  boolean outOfOrderAllowed;
  unsigned short maxRetransmitTime;
  unsigned short maxRetransmitNum;
};

time is in milliseconds.

Tests (a single or small number of tests can exercise most of all of these functionalities):

opening channels works (currently only after onconnection; this will be changed soon to allow creation of channels before CreateOffer)
Verify the label and attributes of a datachannel get passed to the receiver, and different values for label work ("", long labels).  Invalid values.  Null option dictionaries

transferring text, blob and arraybuffer data
that the receiver can choose blob or arraybuffer
transfers of large (>1mb) data
large numbers of sends in a short time
Bidirectional data
large numbers of datachannels (>100)
closing datachannels then opening others
Final data sent is received after closing a datachannel i.e.
   channel.send("foo"); // this should be received
   channel.close();
Sending data when the other side closes

That's a start.  :-)

Comment 4

[Jason Smith [:jsmith]]

Clearing in-testsuite flag - there's already bugs on file for tracking the datachannel tests.

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2]]

(In reply to Jason Smith [:jsmith] from comment #4)
> Clearing in-testsuite flag - there's already bugs on file for tracking the
> datachannel tests.

Well, it doesn't mean we can't have this flag set here. Please don't remove it again because it's important for me to track the work. Instead we should add all already filed bugs to the dependency list.

Comment 6

[Jason Smith [:jsmith]]

(In reply to Henrik Skupin (:whimboo) from comment #5)
> (In reply to Jason Smith [:jsmith] from comment #4)
> > Clearing in-testsuite flag - there's already bugs on file for tracking the
> > datachannel tests.
> 
> Well, it doesn't mean we can't have this flag set here. Please don't remove
> it again because it's important for me to track the work. Instead we should
> add all already filed bugs to the dependency list.

The work is tracked. It's in bug 796889, bug 796891, bug 796894, bug 796895. if more tests are needed, then file bugs for them. But tracking on this meta bug isn't the right way to go here.