- From: docfaraday via GitHub <sysbot+gh@w3.org>
- Date: Wed, 10 Jan 2018 19:07:49 +0000
- To: public-webrtc-logs@w3.org
> If this were the intention, then why support additional offers in the "have offer" state in the first place? We could just say "this isn't allowed" and let the application do the rollback itself. Syntactic sugar. > Plus, I think doing this would have its own problems. The rollback would remove the previously created transceiver, and the new remote offer would create a new one, which seems counter-intuitive. _Not_ doing this seems counter-intuitive to me. A second SRD(offer) doesn't make any sense to me unless it means "disregard that previous SRD (ie; rollback), and instead use this new one". Maybe we could word-smith this a little bit by deferring all of the various track/stream/transceiver updates until the new offer is applied. > Also, when you say "fix issue #1706," do you mean "fire events on rollback" or not? I mean fire the events on rollback. Consider a scenario where we do a subsequent SRD(offer) that disables the send bit on some m-sections, and maybe adds some m-sections; I would expect that we would see removetrack/mute events for the old offer, and then some track events for the new tracks. Or, for even more fun, consider a SRD(offer) that adds an m-section, and a subsequent SRD(offer) that doesn't have it. -- GitHub Notification of comment by docfaraday Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1729#issuecomment-356704404 using your GitHub account
Received on Wednesday, 10 January 2018 19:07:53 UTC