- From: Michał Śledź via GitHub <sysbot+gh@w3.org>
- Date: Sun, 31 Dec 2023 13:01:03 +0000
- To: public-webrtc-logs@w3.org
Maybe that's not directly related to this issue but does it mean that there is no support for Early Media mentioned in [this blog post](https://blog.mozilla.org/webrtc/the-evolution-of-webrtc/). By Early Media I mean the ability of offerer to receive and display MediaStreamTrack before receiving remote SDP answer assuming that the offerer is willing to receive. Both the blog post I linked and JSEP RFC ([section 3.2-4](https://datatracker.ietf.org/doc/html/rfc8829#section-3.2-4)) mentions that the receive must be prepared to demux incoming streams before receiving remote SDP answer. I've created a simple [jsfiddle](https://jsfiddle.net/2t89myqo/4/) that tries to accomplish this. The flow is as follows: 1. Setup two PCs with a dummy data channel to establish ICE connection (both sides must exchange their credentials to accept connectivity checks) 2. Offer to receive audio on PC1 3. Apply offer, add audio track, create and apply answer on PC2 4. Don't apply answer on PC1 As a result, looking at chrome://webrtc-internals, I can see that the PC2 sends its audio track, PC1 receives this data on ICE candidate pair but it is not demuxed and no events like ontrack, onunmute etc. are fired. Also, nothing plays in the audio element. If we uncomment line 54 i.e. we do apply answer on PC1, PC1 successfully receives RTP stream. Is this intentional? If yes, why do we always need to create a transceiver with a receiver with a track? -- GitHub Notification of comment by mickel8 Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2880#issuecomment-1872943333 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 31 December 2023 13:01:06 UTC