- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Fri, 29 May 2015 12:55:44 +0000
- To: "Cullen Jennings (fluffy)" <fluffy@cisco.com>
- CC: Peter Thatcher <pthatcher@google.com>, Adam Roach <adam@nostrum.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 27/05/15 23:54, Cullen Jennings (fluffy) wrote: > >> 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). I think you are right, and it also seems (based on feedback from others) that replaceTrack should work even if a renegotiation is required. > > > > >
Received on Friday, 29 May 2015 12:56:10 UTC