- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Fri, 22 Mar 2024 20:05:46 +0000
- To: public-webrtc-logs@w3.org
Sorry I made a typo in the OP initially (now fixed): > 1. [sRD](https://w3c.github.io/webrtc-pc/#ref-for-dfn-receptive-1)'s success task sets _"transceiver.[[[Receptive]]](https://w3c.github.io/webrtc-pc/#dfn-receptive) to true,"_ It should have said: 1. [sLD](https://w3c.github.io/webrtc-pc/#ref-for-dfn-receptive-1)'s success task sets _"transceiver.[[[Receptive]]](https://w3c.github.io/webrtc-pc/#dfn-receptive) to true,"_ IOW, the offerer is receptive in sLD(offer), allowing media to arrive ahead of sRD(answer) on renegotiation (only), e.g. if the offerer renegotiates direction from `"inactive"` to `"recvonly"` or `"sendonly"` to `"sendrecv"`. > if there is no support for early media, perhaps we could get rid of the requirement to always create receiver with a track. I know this would mean changes in onmute, onunmute, onaddtrack and onremovetrack events but just mentioning The spec supports early media, so the model is not likely to change again, for that and other reasons, like the `transceiver.receiver.track`'s lifespan being tied to the transceiver. I'm also unaware of any hardship from this invariant to web-developers / requirement on vendors. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2880#issuecomment-2015823752 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 22 March 2024 20:05:47 UTC