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

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

== addTransceiver-transceivers should get associated with offered m= sections ==
The steps for SRD(offer) says:

> As described by [JSEP] ([section 5.10.](https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-25#section-5.10)), attempt to find an existing RTCRtpTransceiver object, transceiver, to represent the media description. [... otherwise we create a new transceiver.]

Which references:

>             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.

I was reading this as conditions for associating existing transceivers, addTrack being an example of how transceivers could have been added beforehand. The Chrome implementers interpreted the transceiver being added by addTrack as one of the conditions. That is, a transceiver that was added by addTransceiver does not qualify, even if the resulting set of transceivers is _identical_. This seems silly to me.

This is, by design, able to set up both sending and receiving:
```
pc1.addTrack(track);
pc2.addTrack(track);
O/A exchange

Result:
- pc1's transceiver's currentDirection is sendrecv
- pc2's transceiver's currentDirection is sendrecv
- Both tracks are sent
```

But a consequence of the above is that if you use addTransceiver instead, even though the state of the transceivers are identical at the O/A exchange, pc2 is not able to send its track to pc1:
```
pc1.addTransceiver(track);
pc2.addTransceiver(track);
O/A exchange

Result:
- pc1's transceiver's currentDirection is sendrecv
- pc2's has two transceivers: [{currentDirection:null},{currentDirection:recvonly}}
- Only pc1's track is sent
```
This is just confusing. Why should addTransciever-transceivers be blocked from being associated with offers? This forced the application to do workarounds like adding media at a later stage or discouraging you from using the addTransceiver API.

Proposal: Transceivers are associated based on their own merits, not which API caused its creation.

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

Received on Monday, 25 February 2019 10:54:01 UTC