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

Re: New issue: switching sources

From: Peter Thatcher <pthatcher@google.com>
Date: Tue, 20 May 2014 07:27:10 -0700
Message-ID: <CAJrXDUEdGSaf_G8Sxp1JfPT8d8WReh2-t=H2mDPWhXSNokTi_Q@mail.gmail.com>
To: Jim Barnett <1jhbarnett@gmail.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
What do you mean by "understand the dangers"?  What dangers are there?

And in general, yes, I think we can document the implications and leave it
up to the app developer to handle it, especially since the only implication
I can see is that ​the track ID on one end doesn't match the track ID on
the other end, but that seems very minor to me.



On Tue, May 20, 2014 at 7:04 AM, Jim Barnett <1jhbarnett@gmail.com> wrote:

> It certainly sounds straightforward, but can't it cause the other end to
> suddenly start receiving something very different from what it negotiated?
>   Are we assuming that app developers will understand the dangers and
> handle them properly?
>
> On 5/20/2014 9:52 AM, Stefan Håkansson LK wrote:
>
>> On 20/05/14 15:26, Peter Thatcher wrote:
>>
>>> If we just allow RtpSender.track to be settable, and that causes the
>>> RtpSender to send media from track B instead of the previous track A,
>>> but in the SDP it's still the MSID of track A, is that really so bad?
>>>    Why does it matter?  Can't we just put a comment that says "setting
>>> RtpSender.track does not cause renegotiation and does not change the ID
>>> of the track on the remote side"?  That way, the application developers
>>> knows what they are getting.
>>>
>> This sounds like straightforward solution to me.
>>
>>
>>
>>
> --
> Jim Barnett
> Genesys
>
>
Received on Tuesday, 20 May 2014 14:28:18 UTC

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