W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2015

Re: Summary of replace track status

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>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D2425EE@ESESSMB209.ericsson.se>
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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:44 UTC