[webrtc-pc] Recycling an m= section may not remove the old transceiver's remote track from its stream

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

== Recycling an m= section may not remove the old transceiver's remote track from its stream ==
There's a particular corner case that, according to the current "apply a description" algorithm, will leave a dangling track as part of a remote stream when an m= section is recycled.

In most cases this won't happen, because the track will be removed during the offer/answer that rejects the m= section. For example:

1. Local offer adding `sendrecv` transceiver.
2. Remote `sendrecv` answer.
3. Local offer stopping transceiver.
4. Remote `inactive` answer (track removed from stream here).
5. Local offer recycling m= section...

But consider this:

1. Local offer adding `sendrecv` transceiver.
2. Remote `sendrecv` answer.
3. Remote re-offer, still `sendrecv`.
4. Local answer stopping the transceiver (track not removed, because that only happens when applying remote descriptions).
5. Local offer recycling m= section.
6. Remote answer.

When the transceiver is rejected by a local answer, the "process the removal of a remote track" steps will never be followed.

So, assuming we want to fix this, when should the remote track actually be removed?

* When stopping the transceiver (in between steps 3 and 4)?
* When applying a local description with the transceiver stopped (step 4)?
* When applying a local description that recycles the m= section (step 5)?
* When applying a remote description that "accepts" the recycling (step 6)?

If done at step 6, this would match the existing pattern of "only remote descriptions change remote tracks/streams." It may be hard to specify that clearly though.

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

Received on Wednesday, 21 February 2018 21:23:35 UTC