Closed Bug 694808 Opened 13 years ago Closed 12 years ago

Implement data channels for WebRTC PeerConnections

Categories

(Core :: WebRTC: Networking, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jesup, Unassigned)

References

Details

(Keywords: dev-doc-needed, Whiteboard: [WebRTC], [blocking-webrtc+] [qa-])

Per discussions, probably via SCTP-over-DTLS-over-UDP, with both reliable and unreliable channels.  The SCTP implementation will probably come from BSD
SCTP over DTLS over (ICE/UDP), per IETF

This is the master/meta bug
Depends on: 729511
Depends on: 729512
Depends on: dtls
Blocks: 694807
Blocks: 731429
Depends on: 733002
Assignee: rjesup → nobody
Component: Video/Audio → WebRTC: Networking
QA Contact: video.audio → webrtc-networking
Depends on: 776818
QA Contact: jsmith
Whiteboard: [WebRTC]
Whiteboard: [WebRTC] → [WebRTC], [blocking-webrtc+]
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
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?
Flags: in-testsuite?
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.  :-)
Clearing in-testsuite flag - there's already bugs on file for tracking the datachannel tests.
Flags: in-testsuite?
(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.
Flags: in-testsuite?
(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.
Flags: in-testsuite?
Whiteboard: [WebRTC], [blocking-webrtc+] → [WebRTC], [blocking-webrtc+] [qa-]
Blocks: 1050930
You need to log in before you can comment on or make changes to this bug.