Re: [webrtc-pc] Unable to figure out which receivers are "active".

> (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](http://w3c.github.io/webrtc-pc/#peer-to-peer-example-with-media-before-signaling)). 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.

> await pc.setRemoteDescription(offer);
// Early media is possible, and [[Receptive]] true,
// but transceiver.currentDirection is still null

This is the answerer side, where early media can't happen, and reception doesn't start—i.e. [[Receptive]] isn't true—until SLD(answer).

> [[FiredDirection]] is defined as the last applied SDP direction, regardless if it is an offer or answer. This works for the answerer, but for the offerer this would include non-"ontrack"-transceivers that have not been confirmed by the remote endpoint yet.

I don't think that's right. [[FiredDirection]] is only set in SRD(offer) and SRD(answer) where events are fired. It specifically tracks the direction we've fired events from.

> isActive

Taking a step back, symmetrically, answerer-side reception starts after SLD(answer), and offerer-side reception starts either at the same time or after SRD(answer). 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.

The last piece of this puzzle is that we can now [defer playback until `unmute`](https://blog.mozilla.org/webrtc/when-should-you-display-incoming-webrtc-video/):
```js
pc.ontrack = e => e.track.onunmute = () => video.srcObject = e.streams[0];
```

So I think it's a pilot error to expect to make any decisions about reception before SLD(answer).

... and the only thing people should be doing before SLD(answer) is reject things (by either modifying `tranceiver.direction` or calling `transceiver.stop()`.

-- 
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1920#issuecomment-404383262 using your GitHub account

Received on Thursday, 12 July 2018 04:09:32 UTC