[webrtc-pc] Legacy getRemoteStreams() in Unified Plan

henbos has just created a new issue for https://github.com/w3c/webrtc-pc:

== Legacy getRemoteStreams() in Unified Plan ==
Chrome's legacy getRemoteStreams() is currently, under Plan B, defined as:

> All streams of all receivers.

This works because inactive receivers are removed. In Unified Plan, this does not work because transceivers stick around forever. We can look at their currentDirection though:

> All streams of all active receivers. An active receiver is a receiver whose transceiver's currentDirection is "sendrecv" or "recvonly".

currentDirection is chosen, as opposed to direction, because otherwise merely offering to receive would count as a receiver being "active". This does not jive with current definitions of getRemoteStreams().

There is a problem here though. The receiver's currentDirection is not updated at setRemoteDescription(offer), but rather at setLocalDescription(answer). We get a changing behavior:
```
const offer = await caller.createOffer();
await caller.setLocalDescription(offer);
// In Plan B, this updates callee.getRemoteStreams():
await callee.setRemoteDescription(offer);
const answer = await callee.createAnswer();
// In Unified Plan, this is where callee.getRemoteStreams() is updated:
await callee.setLocalDescription(answer);
await caller.setRemoteDescription(answer);
```

In order for the browser or application to know what receivers are "active" we need to expose what direction was offered/answered by the remote end.

Questions:
1. Is this what [[FiredDirection]] is? Added in https://github.com/w3c/webrtc-pc/pull/1867.
2. Does this motivate exposing this as an attribute to the application?

Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1890 using your GitHub account

Received on Thursday, 14 June 2018 08:58:55 UTC