> however, as currently specified, the RTCRtpSender is always created with a track Well, the "Create an RTCRtpSender" algorithm takes a track as input. But it can be null, and it will be if it's created by SRD. The relevant statement is "Create an RTCRtpSender, sender, from the media description.", which doesn't mention creating a track. > The RTPReceiver track is not nullable. Should it be? No; there should be a 1:1 relationship between the `RTCRtpReceiver` and its track. Or, was your idea to have `addTrack` produce an `RTCRtpReceiver` with a `null` track, such that a track with the correct ID will be produced if the next thing that happens is `setRemoteDescription`? I don't think this is worth the added complexity. Though maybe it's what we'd need to do if we really wanted to avoid breaking existing apps that have expectations about track IDs. -- GitHub Notification of comment by taylor-b Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1128#issuecomment-298068850 using your GitHub accountReceived on Friday, 28 April 2017 18:12:30 UTC
This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:40 UTC