Re: Next steps on RTCRtpSender "doohickey" proposal

+1

Sent from my iPhone

On 8 May, 2014, at 12:34 PM, Justin Uberti <juberti@google.com> wrote:

> 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 RemoteTrackEvent.
>                                          // note that onremovestream is not needed, since tracks are 'removed'
>                                          // simply by progressing to the ENDED state
> };
> 
>