Re: [webrtc-pc] addTransceiver woes

(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