Talking about the transceiver direction. The adding and reusing of sender/receiver needs to be supported whether or not we support transceiver.

Not sure what you mean by "inactive" and "resused", but there shouldn't actually be any reuse at the API layer. RTCRtpTransceivers can reuse the same m= line but the actual objects are different. Perhaps you mean reusing by addTrack? But that's no different than sender.replaceTrack which is already supported.

I was referring to 4.4.1.6 Set the RTCSessionDescription,
https://w3c.github.io/webrtc-pc/#set-the-rtcsessiondescription
...
2.2.8. If description is set as a remote description, then run the following steps:
...
2.2.8.2 As described by [JSEP] (section 5.10.), attempt to find an existing RTCRtpTransceiver object, transceiver, to represent the media description.

So I just looked up this JSEP reference for the first time...
https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-24#section-5.10

  If the m= section is sendrecv or recvonly, and there are
  RtpTransceivers of the same type that were added to the
  PeerConnection by addTrack and are not associated with any
  m= section and are not stopped, find the first (according to
  the canonical order described in Section 5.2.1) such
  RtpTransceiver.



So, I'm trying to figure out what this means. Maybe I'm misunderstanding something...

let caller = new RTCPeerConnection();
caller.addTrack(videoTrack1);  // transceiver t1 created
let callee = new RTCPeerConnection();
callee.addTrack(videoTrack2);  // transceiver t2 created

// This causes t1 to be associated with an m= section.
let offer = async caller.createOffer();
async caller.setLocalDescription(offer);

// Since t2 is not associated with an m= section yet I assume
// it will be used to receive the remote videoTrack1 from caller.
// So now t2 will use the same m= section?
async callee.setRemoteDescription(offer);
let answer = async callee.createAnswer();
async callee.setLocalDescription(answer);

// Because t2 and t1 use the same m section, the caller will
// receive the remote videoTrack2 from callee using the
// existing transceiver t1.
async caller.setRemoteDescription(answer);


Does that make sense? I would have assumed a transceiver is created for both directions but my understanding from reading the spec is that we only need one transceiver on both endpoints.

hta@ and deadbeef@ what is your take on #3 and #4?

And I assumed something similar can happen if you've removed a track and done a full O/A cycle and then you do the above again.

The only two cases where a transceiver can detach from a media section is on a rollback and after stopping a transceiver (port=0 in offer/answer). In all other cases - once it's associated with a media section, it stays with that media section.
References to "free-floating" transceivers are for transceivers created with AddTrack or AddTransceiver since the last offer/answer exchange completed. The ones detached by stopping are stopped permanently - they never come back.

Senders and receivers (one of each) are permanently attached to transceivers. Not sure that was a good move, but that's how the spec's written today.

Remember: Senders and receivers are unidirectional: One sends, the other receives.
Transceivers are bidirectional. We use them with both a sender and a receivers.

In the example in #4 - yes, those two tracks are supposed to end up described by the same media section. That's what's interoperable with non-browser SDP, and the point of the whole shenanigan with transceivers and media sections.

Thanks!
Okay so they can be "recycled" in the sense of #4 that they may have been created prior (e.g. getReceivers() will list it before the first ontrack event). But once in-use for media, it's a one-time deal, and after stopping a transceiver they will never be "recycled".
The special case of rollback might undo a stop, but it is not recycled for other media in the sense we're talking about.

I will keep this bug open since using an existing sender/receiver like described in #4 is not supported yet, but it is possible this bug becomes a NO-OP when we support transceivers.

This is an old bug fixed by the addition of transceviers.