- From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
- Date: Thu, 29 Mar 2018 11:16:36 +0000
- To: public-webrtc-logs@w3.org
You're correct, I found the section that covers the third case - it's in 6.2.: > In some cases, the user agent may be unable to create an RTCDataChannel's underlying data transport. For example, the data channel's ID may be outside the range negotiated by the [RTCWEB-DATA] implementations in the SCTP handshake. When the user agent determines that an RTCDataChannel's underlying data transport cannot be created, the user agent MUST queue a task to run the following steps: [...] But what's the point of assigning the ID while setting the remote description? The data channel doesn't open before the SCTP handshake took place. It would be much simpler to do ID assignment and validation once and not twice. And FWIW also much simpler to test since testing the second case before the third is very brittle. > As for DTLS role changes, we could say "only the first role selected matters" [...] Sounds good. Maybe make this an internal slot that can only be set once? -- GitHub Notification of comment by lgrahl Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1818#issuecomment-377203546 using your GitHub account
Received on Thursday, 29 March 2018 11:16:39 UTC