- From: jan-ivar via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 Dec 2017 17:39:10 +0000
- To: public-webrtc-logs@w3.org
(Ok, found the FF bug, which [surprisingly](https://bugzilla.mozilla.org/show_bug.cgi?id=1423314#c1) was that stream arg is missing in the track event in this case)
Turns out the `direction` attribute matters for things other than legacy.
To recap our understanding (assuming a well-configured `pc1.onnegotiationneeded`):
1. `pc1.addTransceiver('video');` must cause `pc2.ontrack` to fire, so `replaceTrack` will work later.
2. `pc1.addTransceiver('video', {direction: "recvonly"});` mustn't.
So the competing use-cases for addTransceiver here seem to be:
1. Add a null-track "sendrecv" transceiver we can use sender.replaceTrack on later @stefhak
2. Add a "recvonly" transceiver, because we don't want to offer to send anything. @fippo
If we ignore one of these use cases, then determining the default for `direction` is easy. With both in mind, do we feel we have the default right?
--
GitHub Notification of comment by jan-ivar
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1662#issuecomment-352499721 using your GitHub account
Received on Monday, 18 December 2017 17:39:12 UTC