Re: Update of RTCRtpSender "doohickey" proposal

On Tue, Apr 29, 2014 at 12:02 AM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> I like this. I have a couple of questions/comments though:
>
> 1) I'd like to see already for version 1 surface for a way to check if
> media is flowing (RTP packets are being sent) on the RTCRtpSender.
> Martin mentioned this yesterday.
>

To help figure out the exact requirements of such an API, can you post an
example use case?

>
> 2) Would pc.addTrack(...) need success/failure indication? We have been
> talking about that for addStream, but never really concluded.
>

IIRC, the arguments for success/failure notification were about wanting to
know if you had added more streams than you could send. However, I think in
reality the act of adding a stream is only one of the things that could
cause resource limits to be exceeded, so I think the error needs to come
later, e.g. in setLocalDescription.

>
> 3) I like the removal of the "removetrack" event, instead having the
> track on the remote side going to ended state. I guess the associated
> RTCRtpReceiver would also go to a terminated state. We need some text
> explaining what will happen if the same track is again added on the
> sender side.
>

This is an interesting point, but I think the simplest thing is just to
create a new, non-dead track on the remote side with the same ID.

>
> 4) I remain unconvinced that we need the stream argument for addTrack. I
> think the really simple cases can be polyfilled anyway (assume all
> tracks belong to one stream), and it does not help the advanced cases.
>
> Stefan
>
> On 28/04/14 18:00, Justin Uberti wrote:
> > Update of the proposal from earlier this year, addressing the feedback
> > from the list. Mainly, the issues with AddStream and AddTrack have been
> > resolved by adding an explicit |stream| parameter to AddTrack.
> >
> >
> > ------------------------------------------------------------------
> >
> >
> > 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.
> >
> >
>
>