Re: [webrtc-pc] addTransceiver-transceivers should get associated with offered m= sections (#2108)

> The thinking was: if you add a transceiver, you mean to add a new transceiver. If you add a track, then your expectation is (historically) more likely to be symmetrical.

And if you call addTransceiver(), you do get a new transceiver. So why not use it in the answer? Presumably because you want to ensure that you can offer-to-receive in the future, and...

> By having both methods you get to choose.

...but you do get to choose, even if addTranscievers() are treated the same as addTrack()-transceivers.

If you do addTransceiver() followed by createOffer() your additional transceivers become new m= sections and you're happy.
If you receive an offer after having done addTransceiver(), and your transceiver ended up being used in the answer, this is easily observable, and you can simply call addTransceiver() again (just look at which transceivers have a currentDirection: null when you're in a stable state).

> I personally think this has some merit, but one would need to weigh the trade-offs, and I don't see any new information here.

The benefit of addTrack() over addTransceiver(), in my opinion, is that it doesn't necessarily create a new transceiver, so you avoid having to do extra code for "do I already have one that I can reuse? If so replaceTrack() and change direction manually". This is for convenience and for track-minded people. The track-minded person thinks "adding a track means I can send a track". The transceiver-minded person thinks "a transceiver matches to m= sections". Or with the current design, "a transceiver matches to m= sections, with some caveats that I have to keep track of myself".

Right now whether or not a transceiver is usable is based on historical information that is not explicitly stored anywhere, and is not observable to someone who uses getTransceivers() to get a sense of the state in comparison to the expected O/A behavior.

> given the history of this, should this issue be closed?

I think not. If we want some transceivers to be special we should call it out. Bare minimum with an [[IsUsableInRemoteOffer]] internal slot, but possible even an attribute to expose this to the JS application, so that it can easily figure out whether or not new transceivers are needed. This is currently very much implicit and involves interpreting a JSEP line correctly.

I still think we should consider not making transceivers special though because, as I explained, this special functionality is not needed to achieve what its intention was, and anyone who cares about this should already have a clue about the relationship between transceivers and m= sections.

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

Received on Friday, 1 March 2019 13:25:22 UTC