- From: Christer Holmberg via GitHub <sysbot+gh@w3.org>
- Date: Fri, 09 Feb 2024 18:07:35 +0000
- To: public-webrtc-logs@w3.org
> This thread made me take a closer look at RFC 8864. I filed an errata on it: https://www.rfc-editor.org/errata/eid7805 It's a good catch. Now, it's some years since the RFC was published, and AFAIR I was not very deeply involved in the work, so without digging in the mail- and meeting minutes archives I ASSUME that the 8864 authors simply applied the DCEP rules without considering that the SDP offer takes place BEFORE the DTLS roles have been determined. Now, my own speculations about why this has not been raised from the implementation community before: - In all data channel use-cases I have seen, the data channel and the data channel usage (e.g., RTT) are created by the offerer in the initial O/A exchange. After that no additional data channel usages are created. So, the answerer may accept whatever stream identifier (odd or even) it receives. - In most (all?) data channel use-cases I have seen, when the offerer sends ACTPASS, the receiver returns PASSIVE. So, the offerer assumes it will become that DTLS client. I have also seen cases where the offerer offers ACTIVE, in which case it knows it will become DTLS client (if the answerer accepts the offer). -- GitHub Notification of comment by cdh4u Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2931#issuecomment-1936381658 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 9 February 2024 18:07:38 UTC