- From: Miguel París via GitHub <sysbot+gh@w3.org>
- Date: Tue, 29 Nov 2016 17:19:27 +0000
- To: public-webrtc-logs@w3.org
mparis has just created a new issue for https://github.com/w3c/webrtc-pc: == Receive a track multiple times == Hello, while implementing we are dealing with the case of receiving the same track twice. There are typically 2 cases: ### Receive a track previously removed As explained in [1]: > When the other peer stops sending a track in this manner, an ended event is fired at the MediaStreamTrack object. The problem is that when the track is ended, it cannot be reused again [2]. So how should we manage the case of receiving again a track that has been set as ended? ### Receive the same track multiple times The same track can be sent multiple times using addTransceiver[3]. How the receiver side should deal with this case? A priori, we could have different MediaStreamTrack objects with the same ID and performing multiple onTrack events, but the ID should be unique, so this is not a proper solution. ## Solution proposal As solution, I think that we must not allow sending a track more than once through addTransceiver in the same way addTrack is doing [4]: >If an RTCRtpSender for track already exists in senders, throw an InvalidAccessError exception and abort these steps. And in the case that a receiver get this situation, it should reject the m-line associated. In the case that the user wants send the same media multiple times, she should clone the track to generate a new ID. What do you think about that? Best!! ## Refs [1] https://www.w3.org/TR/webrtc/#dom-rtcpeerconnection-addtransceiver [2] https://www.w3.org/TR/mediacapture-streams/#idl-def-MediaStreamTrackState.ended [3] https://www.w3.org/TR/webrtc/#dom-rtcpeerconnection-addtransceiver [4] https://www.w3.org/TR/webrtc/#dom-rtcpeerconnection-addtrack Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/954 using your GitHub account
Received on Tuesday, 29 November 2016 17:19:33 UTC