- From: Harald Alvestrand via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Jan 2018 16:04:50 +0000
- To: public-webrtc-logs@w3.org
I think the problematic thing here was that if the track is muted due to setRemoteDescription, and there were packets straggling in late, it could be unmuted while the transceiver direction is invalid for unmuting. I think the proper solution is to guard the unmuting in 5.3 by a check on the transceiver state: "If packets are received again, the track is muted, and the associated transceiver's direction is still sendrecv or recvonly, unmute the track". -- GitHub Notification of comment by alvestrand Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1737#issuecomment-358352137 using your GitHub account
Received on Wednesday, 17 January 2018 16:04:53 UTC