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 accountReceived on Sunday, 14 June 2020 01:21:47 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:51 UTC