W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2016

[webrtc-pc] Receive a track multiple times

From: Miguel París via GitHub <sysbot+gh@w3.org>
Date: Tue, 29 Nov 2016 17:19:27 +0000
To: public-webrtc@w3.org
Message-ID: <issues.opened-192344906-1480439963-sysbot+gh@w3.org>
mparis has just created a new issue for 

== Receive a track multiple times ==
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
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?


## Refs
[1] https://www.w3.org/TR/webrtc/#dom-rtcpeerconnection-addtransceiver
[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:36 UTC

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