RE: Update of Doohickey/AddTrack proposal

Hi!

Nice going! The addition makes the pipeline clearer in my mind!

However, haven’t we had discussions about also have API support for managing the bitrate (and pattern) in absolute terms on track and transport/peerconnection level? It was not obvious in Your proposal if and how
that is supported. Was something dropped in cut and paste, ☺:
  // for multiple encodings: simulcast (audio or video), layered coding
  // specify the codec to use, resolution, bitrate, and any dependencies for each encoding

Did You have in mind adding such stuff, e.g. absolute bandwidth allocation on outgoing flows and as well as caps in aggregate of outgoing flows on individual Transport path?

Right now, I am leaning towards having this in WebRTC 1.0 would add to its viability for mobile deployment but I would like to hear what others have in mind.

Regards
Göran


From: Justin Uberti [mailto:juberti@google.com]
Sent: den 19 december 2013 04:36
To: public-webrtc@w3.org
Subject: Update of Doohickey/AddTrack proposal

Based on some feedback I've received, I've slightly updated my proposal (originally inspired by Martin) on doohickeys and replacing AddStream with AddTrack. See below:

------------------------------------------------------------------------

I suggest we call the SendDoohickeys RtpSenders and the corresponding receive-side objects RtpReceivers. 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 RtpSender as a return value from AddTrack (which replaces AddStream). You get a RtpReceiver as an argument to the new onaddtrack callback (which replaces onaddstream). The actual track object can be obtained as a property from the RtpReceiver (see below).

For getting access to ICE/DTLS info, both RtpSenders and RtpReceivers can also have a reference to a DtlsTransport 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:

interface DtlsTransport {
  attribute RTCIceConnectionState state;
  attribute sequence<ArrayBuffer> remoteCertificates;
  //... more stuff as needed
};

interface RtpSender {
  readonly attribute MediaStreamTrack track;
  readonly attribute DtlsTransport transport;
  // various tweakable attributes
  attribute bool active;  // controls "am I sending RTP"
  attribute PriorityLevel priority;  // for relative bandwidth allocation
  // for multiple encodings: simulcast (audio or video), layered coding
  // specify the codec to use, resolution, bitrate, and any dependencies for each encoding
  attribute sequence<EncodingParams> encodings;
};


interface RtpReceiver {
  readonly attribute Transport transport;
  readonly attribute MediaStreamTrack track;
  // more stuff as needed
};

partial interface PeerConnection {
  RtpSender addTrack(MST);  // replaces addStream
  void removeTrack(RtpSender);  // replaces removeStream
  readonly attribute sequence<RtpSender> senders;
  readonly attribute sequence<RtpReceiver> receivers;
  EventHandler onaddtrack;  // replaces onaddstream; onremovestream is not needed
};

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 ---> Transport ---> (The Internet) ---> Transport ---> 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 Transport; N is controlled by the policy specified for BUNDLE.