- From: Sean DuBois via GitHub <sysbot+gh@w3.org>
- Date: Sun, 14 Jun 2020 01:21:45 +0000
- To: public-webrtc-logs@w3.org
Oh I completely missed your original point. I thought that the header was having issues on reception, but it is Chrome's outbound packetization that I was breaking. Was focusing on the wrong thing. Should I make a PR against the `webrtc-samples` repo? [endtoend-encryption](https://github.com/webrtc/samples/blob/gh-pages/src/content/peerconnection/endtoend-encryption/js/worker.js#L117) will sometimes encrypt the header. I don't see it explicitly enabling GFD either. ---- Unrelated, but why is GFD a requirement for this? Chrome will have to generate/capture metadata to generate the plaintext GFD and prepend it. Why not generate the payload specific header before the insertable stream as well? -- GitHub Notification of comment by Sean-Der Please view or discuss this issue at https://github.com/w3c/webrtc-insertable-streams/issues/37#issuecomment-643704130 using your GitHub account
Received on Sunday, 14 June 2020 01:21:47 UTC