- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Tue, 17 Jul 2018 09:54:31 +0000
- To: public-webrtc-logs@w3.org
> > (Side-note: so "early media" only applies answerer -> offerer, not offerer -> answerer?) > > I believe so. An answerer can send media in parallel with its answer (from example). So early media reception is only a thing on the offerer side, where tranceiver.direction already tells you which receivers you can expect reception on. Hmm, but transceiver.[[Receiver]].[[Receiver[Rtcp]Transport]] is not set until SRD(answer)? Doesn't sound like media is able to arrive any earlier than always creating new transceivers? Is "early media" entirely hypothetical? > [...] I.e. reception starts after answers. > > The asymmetry is that while offerer-side events fire in SRD(answer) which makes sense, answerer-side events fire early in SRD(offer), not SLD(answer), which does not make sense. > > In hindsight, a mistake. I believe the only reason we fire events in SRD(offer) is because track.stop() was the initial API for rejecting incoming media many moons ago, so you needed the tracks to reject. That is no longer the case, but we may be stuck with it. > > [...] > > ... and the only thing people should be doing before SLD(answer) is reject things (by either modifying tranceiver.direction or calling transceiver.stop(). Thanks for the enlightening comments. I'm no longer sure "isActive" is needed. This all is surprisingly complicated though. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1920#issuecomment-405526997 using your GitHub account
Received on Tuesday, 17 July 2018 09:54:34 UTC