Re: Update of RTCRtpSender "doohickey" proposal

On 2014-04-30 07:06, Justin Uberti wrote:
>     3) I like the removal of the "removetrack" event, instead having the
>     track on the remote side going to ended state. I guess the associated
>     RTCRtpReceiver would also go to a terminated state. We need some text
>     explaining what will happen if the same track is again added on the
>     sender side.
>
>
> This is an interesting point, but I think the simplest thing is just to
> create a new, non-dead track on the remote side with the same ID.
>

For clarification. It's the counter-part of the "removestream" event (on 
RTCPeerConnection) that this proposal is leaving out right? We still 
have the "removetrack" event on MediaStream (which can be used in other 
cases than RTCPeerConnection)?

/Adam

Received on Wednesday, 30 April 2014 05:16:14 UTC