W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > April 2018

Re: [webrtc-pc] RTCDataChannel.send during 'closing' state

From: Bernard Aboba via GitHub <sysbot+gh@w3.org>
Date: Fri, 27 Apr 2018 16:41:11 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-385026266-1524847270-sysbot+gh@w3.org>
@lgrahl 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."

-- 
GitHub Notification of comment by aboba
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1827#issuecomment-385026266 using your GitHub account
Received on Friday, 27 April 2018 16:41:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:01 UTC