[ortc] RTCDataChannel: transition to `closing`?

aboba has just created a new issue for https://github.com/w3c/ortc:

== RTCDataChannel:  transition to `closing`? ==
Lennart has raised the question as to how an application determines that a remote peer has called RTCDataChannel.close().  The specification appears to indicate that this causes a transition of `.readyState` to `closing`, with no resulting event (e.g. `onclose` event handler is not fired).  Adding an `onclosing` event handler seems icky. 

Looking at RFC 6525 and Section 6.7 of draft-ietf-rtcweb-data-channel, one way to handle this would be to have receipt of an incoming stream reset cause .readyState to transition to closed. The receipt of an incoming stream reset causes an outgoing stream reset to be sent. While after sending an outgoing stream reset the peer could transition .readyState to closing and await receipt of a re-configuration response with a result of success prior to transitioning .readyState to closed, after sending the outgoing stream reset, data can neither be sent nor received so closed might be more appropriate.

"6.7. Closing a Data Channel

Closing of a data channel MUST be signaled by resetting the
corresponding outgoing streams [RFC6525]. This means that if one
side decides to close the data channel, it resets the corresponding
outgoing stream. When the peer sees that an incoming stream was
reset, it also resets its corresponding outgoing stream. Once this
is completed, the data channel is closed. Resetting a stream sets
the Stream Sequence Numbers (SSNs) of the stream back to 'zero' with
a corresponding notification to the application layer that the reset
has been performed. Streams are available for reuse after a reset
has been performed.

[RFC6525] also guarantees that all the messages are delivered (or
abandoned) before the stream is reset."

Please view or discuss this issue at https://github.com/w3c/ortc/issues/838 using your GitHub account

Received on Saturday, 28 April 2018 00:15:28 UTC