Re: [MMUSIC] draft-ietf-mmusic-msid-16 is out of sync with WebRTC 1.0

[Cullen Jennings <[e-mail]>]

> On Sep 12, 2017, at 12:30 PM, Taylor Brandstetter <[e-mail]> wrote:
> 
> Maybe a detailed example will make this more clear:
> 	• Endpoint A ("Alice") creates PeerConnection, adds track to it. Suppose this track's ID is "trackA".
> 	• RTCRtpTransceiver is created, along with an RTCRtpReceiver that has a track with a randomly generated ID. Let's call it "generatedA".
> 	• Endpoint B ("Bob") does the same thing; suppose they added a track with ID "trackB", and a remote track was created with ID "generatedB".
> 	• Alice creates offer, signals to Bob.
> 	• Bob applies remote description. The SDP contains "a=msid:streamA trackA", but Bob's remote track ("generatedB") already exists. So it just gets added to a stream, and the ID "trackA" gets ignored.
> 	• Bob creates answer, signals to Alice.
> 	• Same thing. The SDP contains "a=msid:streamB trackB", but the track ("generatedA") already exists and the ID "trackB" is ignored.
> The MSID draft clearly doesn't align with this. It assumes a track is always created when a new track ID is seen in SDP.
>  
> 

Thanks - that makes it perfectly clear. 

What I would have expected to happen in this case is when Bob applies the remote description, the trackID of that track changes from "generatedB" to "trackA". It seems like that track is being reused to now carry "trackA" and is the only way the data survives. It also mirrors what would have happened if the track was not created ahead of time and just crated by Bob applying the remote offer.