Re: [webrtc-pc] Initial data channel state is inconsistent

After talking to @jan-ivar to this is it turns out that my suggestion is not a good idea from an API's perspective.

In the _RTCDataChannelEvent_ event handler is the first time you get a reference to a newly created channel. Thus this is also the first time you can install an _onopen_ callback on the new channel. But in the scenario where the underlying transports are connected already if we then start any new channel in _open_ right away, every user of the API would have to have an if condition in the _ondatachannel_ event handler distinguishing between the first and all subsequent channels.

So for the purpose of having a consistent API which always behaves the same it seems a new channel in the _RTCDataChannelEvent_ should always start in the 'connecting' state, so that you can always setup an _onopen_ callback, which executes always the same code no matter what the initial state of the underlying transports is/was.

But that means that we would have to remove the concept of 'underlying transport' from a couple of place in the data channel sections.

GitHub Notification of comment by nils-ohlmeier
Please view or discuss this issue at using your GitHub account

Received on Friday, 9 February 2018 00:38:48 UTC