- From: Timothy B. Terriberry <tterriberry@mozilla.com>
- Date: Mon, 06 Feb 2012 14:18:17 -0800
- To: Harald Alvestrand <harald@alvestrand.no>
- CC: public-webrtc@w3.org
Harald Alvestrand wrote: > This way, reliable, sequenced datagrams would be on one channel; > unreliable, unsequenced ones would be on another, giving consistency. This is entirely at the discretion of the sender, right? If the receiver needs to rely on a particular data channel being ordered or reliable, it's probably making a number of assumptions about what's in it (that the sender would do well to conform to if it wants the receiver to work correctly). As long as we don't expose whether or not a data channel is reliable in the API on the receiving side (and I don't see a need to... the sender can drop or reorder datagrams before it ever gives them to the SCTP stack, so it's not like we're exposing the receiver to anything it wouldn't have had to deal with before), we can still make the API on the sending side use one set of options per channel without imposing any additional restrictions on what non-browser peers might do. That would give us the option to add a sender API with per-packet options later if we ever saw the need.
Received on Monday, 6 February 2012 22:20:42 UTC