- From: henbos via GitHub <sysbot+gh@w3.org>
- Date: Mon, 25 Nov 2019 12:08:46 +0000
- To: public-webrtc-logs@w3.org
Time has passed since this issue was filed, and after having reviewed the webrtc.org implementation I think I have a better idea about what needs or doesn't need rolling back. Transports on offer will need to be rolled back ([slide](https://docs.google.com/presentation/d/1QEdMf6Ixg1NNvHoZUvO29njrSKn9pdF1WqcrFWI4uX8/edit#slide=id.g6b7f95ec98_0_6)), for example. As well as mid, and created-and-not-blessed-by-addTrack transceivers. direction/currentDirection is a non-issue, because direction is the control surface (not affected by O/A) and currentDirection is only set in answers, i.e. never needs to be rolled back. For bundling, there are multiple transports on offers, it's not a case of re-configuring them I don't think. So ignoring editorial issue #2332, I'm happy with "rollback" . There are only a couple of question marks in my head, that I think require clarification by the spec: 1. What is the effect of ICE restart? Does this need to be rolled back? What happens with generated candidates, will they get rejected by addIceCandidate? Is this something the app needs to be prepared for? Should we add a "note"? 2. What happens if you swap out codecs? Early media-reasoning would suggest that codecs are applied at SLD(offer) rather than SRD(answer). This implies that existing packets on the wire with an old codec would get dropped while have-local-offer. If offers were proposed to be changed and we roll back, then what we need to do on rollback is the revert codec settings. This assumes we don't do anything special for smooth transition when changing codecs. -- GitHub Notification of comment by henbos Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/2324#issuecomment-558127202 using your GitHub account
Received on Monday, 25 November 2019 12:08:51 UTC