- From: Taylor Brandstetter via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 Feb 2018 21:23:30 +0000
- To: public-webrtc-logs@w3.org
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