Re: New issue: switching sources

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
>
>