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

On 2014-02-06 22:02, Makaraju, Maridi Raju (Raju) wrote:
>
>     [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()./*
>
/*Yes, that is my point. We need to get a description on when the events 
appear and what parameters do they carry.

You may be right about the error event only appearing when something 
goes logically wrong in the application.
Then communication errors should be signaled with something else, and 
you point at the NetworkError in the discussion below as the possible 
answer.

*/
>
> *//*
>
>
>
> 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/./
>
/So for transmission failure in reliable channel, both NetworkError and 
close will be fired.
Is NetworkError a new, still undefined event type?  If so, it needs to 
be defined.

The events are summarized in chapter 11.
Maybe a good start would be to expand the TODOs in chapter 11, and 
introduce the NetworkError there if is is intended to be an event type 
of its own.

Regards
Gunnar

/
>
> //
>
> /”/
>
> */Regards/*
>
> */Raju/*
>