Re: [Bug 25497] New: RTCRtpSender / Receiver objects need to be added to the specification

I think this needs a lot more discussion before we start making bugs for it. 


On Apr 29, 2014, at 3:43 AM, bugzilla@jessica.w3.org wrote:

> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25497
> 
>            Bug ID: 25497
>           Summary: RTCRtpSender / Receiver objects need to be added to
>                    the specification
>           Product: WebRTC Working Group
>           Version: unspecified
>          Hardware: PC
>                OS: Linux
>            Status: NEW
>          Severity: normal
>          Priority: P2
>         Component: WebRTC API
>          Assignee: public-webrtc@w3.org
>          Reporter: harald@alvestrand.no
>                CC: public-webrtc@w3.org
> 
> The proposal for RTCRtpSender /Receiver sent to the mailing list on April 28 is
> reproduced below. The April 28 meeting seemed to agree that this is a sensible
> direction, but details may need adjusting before integrating.
> 
> I suggest we call the SendDoohickeys RTCRtpSenders and the corresponding
> receive-side objects RTCRtpReceivers. These objects allow control of how a
> MediaStreamTrack is encoded and sent on the wire, including "hold" state,
> prioritization, and multiple encodings (e.g. simulcast).
> 
> You get a RTCRtpSender as a return value from AddTrack (which replaces
> AddStream). You get a RTCRtpReceiver as an argument to the new onaddtrack
> callback (which replaces onaddstream). The actual track object can be obtained
> as a property from the RTCRtpReceiver (see below).
> 
> For getting access to ICE/DTLS info, both RTCRtpSenders and RTCRtpReceivers can
> also have a reference to a RTCDtlsTransport object, which will have its own
> state variables, including the RTCIceConnectionState of that particular
> transport, and the .remoteCertificates for the DTLS connection. This allows
> applications to monitor the state of individual transports, as well as inspect
> the certificates for individual transports.
> 
> The actual interface is as follows:
> 
> // used with RTCRtpSender
> 
> interface RTCDtlsTransport {
> 
> attribute RTCIceConnectionState state;
> 
> sequence<ArrayBuffer> getRemoteCertificates();
> 
> //... more stuff as needed
> 
> };
> 
> // used with RTCRtpSender
> 
> interface RTCRtpEncodingParams {
> 
>   double               priority = 1.0;  // relative priority of this encoding
> 
>   unsigned int       maxBitrate = null;  // maximum bits to use for this
> encoding
> 
>   boolean             active;  // sending or "paused/onhold"
> 
> };
> 
> // the "send" doohickey
> 
> interface RTCRtpSender {
> 
> readonly attribute MediaStreamTrack track;
> 
> readonly attribute RTCDtlsTransport transport;
> 
> // 1-N encodings; in the future, N can be > 1, for simulcast or layered coding
> 
> // Each EncodingParams specifies the details of what to send (e.g. bitrate)
> 
> sequence<RTCRtpEncodingParams> getEncodings();
> 
> };
> 
> // the "receive" doohickey
> 
> interface RTCRtpReceiver {
> 
> readonly attribute RTCDtlsTransport transport;
> 
> readonly attribute MediaStreamTrack track;
> 
> // more stuff as needed
> 
> };
> 
> // parameter to the onaddtrack event
> 
> interface RemoteTrackEvent : 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
> 
> RtpSender addTrack(track, streamId);  // replaces addStream
> 
> 
> 
> void removeTrack(RtpSender);  // replaces removeStream
> 
> sequence<RtpSender> getSenders();
> 
> sequence<RtpReceiver> 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
> 
> };
> 
> For backcompat, addStream, removeStream, getLocalStreams, getRemoteStreams, and
> onaddstream can be trivially polyfilled in JS, so there is minimal impact on
> current applications.
> 
> All together, the pipeline looks like this:
> 
> Source ---> MST ---> RtpSender ---> DtlsTransport ---> (The Internet) --->
> DtlsTransport ---> RtpReceiver ---> MST ---> <video/>
> 
> Each RtpSender/Receiver references a single MST, although a single
> RtpSender/Receiver can send/receive multiple encodings (e.g. simulcast).
> 
> There are N RtpSenders/Receivers per DtlsTransport; N is controlled by the
> policy specified for BUNDLE.
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.
> 
>

Received on Wednesday, 30 April 2014 20:27:55 UTC