- From: Cullen Jennings (fluffy) <fluffy@cisco.com>
- Date: Wed, 27 May 2015 21:54:53 +0000
- To: Stefan Håkansson <stefan.lk.hakansson@ericsson.com>
- CC: Peter Thatcher <pthatcher@google.com>, Adam Roach <adam@nostrum.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
> On May 23, 2015, at 1:00 AM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote: > > > Conclusion: replaceTrack should always fail (throw) if the signaling > state is not stable (this was probably apparent to everyone else already). Nah, this does not make sense to me. Imagine the following case.... I'm setting up an audio call and while I am waiting for the other side to answer I switch microphones. That seems normal and lets say that with both microphones the browser is doing all the codecs in software and has offered both 711 and opus but can easily do that from either microphone. Seems like a case liek that should work fine. I think the important thing is that when the signaling is stable, you can only swap out something where the browser can stay consistent with the previous signaling. Its exactly the same when signaling is not stable, one can only swap out with something that is consistent with the signaling which means both the previous negotieated offer/ans pair as well as the current outstanding offer (and or prAnswers).
Received on Wednesday, 27 May 2015 21:55:23 UTC