W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2014

Next steps on RTCRtpSender "doohickey" proposal

From: Justin Uberti <juberti@google.com>
Date: Wed, 7 May 2014 21:34:51 -0700
Message-ID: <CAOJ7v-3kAkdCrm+4LKxH2CfJa2AsV1zHk5k-r4AcpT09Ey-JNg@mail.gmail.com>
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Trying to bring this discussion to a conclusion... I sense consensus around
the following:
- General concept of doohickeys, i.e. RTCRtpSender, RTPRtpReceiver.
- addTrack(track, streamId)/removeTrack and onaddtrack.
- Implicit cloning never occurs. This means that if you want to add a track
twice to a PC, you need to first clone it.

More discussion is still needed on:
- RTCRtpEncodingParams
- RTCDtlsTransport

Therefore I would like to advance the initial, uncontroversial parts of
this proposal, i.e. what I describe below. We can then discuss the exact
nature of the encodings and transport objects separately on the list, and
at the interim meeting.

// the "send" doohickey

interface RTCRtpSender {

 readonly attribute MediaStreamTrack track;


// the "receive" doohickey

interface RTCRtpReceiver {

 readonly attribute MediaStreamTrack track;


// parameter to the onaddtrack event

interface AddTrackEvent : Event {

 readonly attribute RtpReceiver receiver;

 readonly attribute MediaStreamTrack track;

 readonly attribute MediaStream stream;


partial interface RTCPeerConnection {

// because a track can be part of multiple streams, the id parameter

  // indicates which particular stream should be referenced in signaling

 RTCRtpSender addTrack(track, streamId);  // replaces addStream; fails if
|track| has already been added

 void removeTrack(RTCRtpSender);  // replaces removeStream

 sequence<RTCRtpSender> getSenders();

 sequence<RTCRtpReceiver> getReceivers();

 EventHandler onaddtrack;  // replaces onaddstream; event object is

                                        // note that onremovestream is not
needed, since tracks are 'removed'

                                        // simply by progressing to the
ENDED state

Received on Thursday, 8 May 2014 04:35:38 UTC

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