RE: RTCDataChannel characteristics and failures -API description - comment to the 20140127 version

[Raju] I want to point out one of the important characteristic of "reliable channel", which is if data can't be delivered (aftere set retransmissions) then the SCTP association is aborted and closed. This is per SCTP RFC 4960 "8.1.  Endpoint Failure Detection"(http://tools.ietf.org/html/rfc4960#page-100).
Good.
This is my assumption of what would be the result of that failure. Please verify:

It will cause an onerror callback. And an onclose as well?
At least the onerror would need a reason parameter, indicating transmission error.
What was successfully transmitted may approximately be judged by looking at the remaining sendbuffer. But there is always a risk that the receiver received something successfully but the sender never got the acknowledgement, so exact state cannot be judged.
The receiving side will at least get an onclose callback. That will be either by signaling from the sender or by timeout on of heartbeats on the channel.
[Raju] PeerConnection spec<http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel> does not clearly specify when onerror () callback is used. Clarifications are probably needed in this spec as to when onerror and/or onclose() callbacks are called. Spec mention onclose() is called when some error happens but not sure if the error happens after onopen() or before onopen(). If I had to guess, onerror() is called for errors happened before onopen() and onclose() is called for errors (including ICE connectivity fails or data transmission failure) after onopen().


There is also an ICE continuity check that can fail in bad communications environments and cause the SCTP association to abort and close.  This can happen also for an unreliable channel.
That type will be signalled by an onerror callback, and a parameter indicating the problem type. Both ends will get the indication and both reliable and unreliable channels will be closed.

Note that heartbeats and ICE connectivity checks can cause failure also on idle channels.
[Raju] Correct. The PeerConnection spec does mention about use of error parameter:
“3. If the transport<http://dev.w3.org/2011/webrtc/editor/webrtc.html#dfn-underlying-data-transport> was closed with an error, fire an NetworkError event at channel.
4. Fire a simple event named close<http://dev.w3.org/2011/webrtc/editor/webrtc.html#event-datachannel-close> at channel.
”
Regards
Raju