Significant portions of the RTP Media API are shipping, including addTrack().
This allows moving away from Chrome's legacy addStream()/removeStream() methods not in the spec. This is major milestone in spec-compliance, but there are still some caveats that need to be resolved before we are ready to deprecate addStream/removeStream()/getLocalStreams(), see notes below. Future releases will add more features, including methods on RTCRtpSender interface which initially only ships with the track attribute.
What's shipping?
RTCPeerConnection gets:
- addTrack(track, streams...)
- removeTrack(sender)
- getSenders()
RTCRtpSender interface partially implemented with:
- track
RTCTrackEvent (for ontrack) implemented minus transceiver support:
- receiver
- track
- streams
Notes & caveats
RTCRtpTransceiver and related behavior is not implemented yet. This is currently in development.
addTrack() per-spec takes 1 track and 0, 1 or multiple streams as argument:
- 1 track, 1 stream case is shipping (this is the spec-compliant way of doing addStream).
- 0 streams case: This works except it still generate a random stream ID in the SDP, resulting in a remote stream at the other endpoint.
https://crbug.com/webrtc/7933
removeTrack(): Senders are not reusable as per-spec, instead they are removed from getSenders(), blocked on transceiver work.
getLocalStreams(): This is legacy API. Note that while addStream() adds to it, addTrack(track, stream) does not add a stream to getLocalStreams(). This will be fixed in the future, but apps should not use this legacy API.