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

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 Tuesday, 29 April 2014 09:44:02 UTC