- From: Philipp Hancke via GitHub <sysbot+gh@w3.org>
- Date: Tue, 27 Feb 2024 06:09:37 +0000
- To: public-webrtc-logs@w3.org
MDN makes weird claims at times... This is not caused by [STUN consent freshness](https://www.rfc-editor.org/rfc/rfc7675) which generally takes place only after the connection is established. If you do something similar like this on the good old (8 years...) https://github.com/fippo/paste as follows 1/ go to index html, copy offer 2/ go to answer.html, set offer as remote description the ICE connection will actually get established (thanks to peer-reflexive candidates). But Since the offerer can not verify the DTLS fingerprint it will not respond before getting the actual answer. The answerer will send the DTLS client hello at expontential backoff times which becomes a very large time window and eventually give up (I think after an hour). But https://webrtchacks.com/the-minimum-viable-sdp/ (2015...) mumbles something about 30 seconds but it doesn't come into effect in this case. What you might try is the following: 1/ not send any candidates from the offerer 2/ tweaking the DTLS a=setup attribute in the SDP to be "active" instead of "actpass" before setting the offer at the remote end. This means the answerer will become the DTLS server. Might work but will still be brittle. -- GitHub Notification of comment by fippo Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2945#issuecomment-1965853245 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 27 February 2024 06:09:38 UTC