RE: ACTION-62, Priority API

If we are going to have something like an “RTCTransportHandler” object get added, why can’t we instead just have an architecture that starts with the right decomposition of this problem into the right number of objects onto which the controls map in a relatively obvious way?

Matthew Kaufman

From: Justin Uberti [mailto:juberti@google.com]
Sent: Tuesday, January 8, 2013 5:03 PM
To: DRUTA, DAN
Cc: Stefan Håkansson LK; public-webrtc@w3.org
Subject: Re: ACTION-62, Priority API

This is an interesting proposal. However, given that the relationship between MediaStreamTracks and transports is can be fairly arbitrary (a track could be split onto multiple transports, or multiple tracks could be muxed on a single transport), I think this should have some other name, like EncodingController (since it really is controlling how the media is being encoded).

The problem then becomes that encoding options are currently controlled by the SessionDescription, which indicates which codec to use, the max bitrate to send with, the SSRCs to use; as such adding a different control surface to control other encoding options like minimum bitrate makes things very complicated.

So I would suggest a fourth option, extending the RTCSessionDescription object with new methods to allow these additional encoding properties to be specified.

On Tue, Jan 8, 2013 at 9:17 AM, DRUTA, DAN <dd5826@att.com<mailto:dd5826@att.com>> wrote:
Hi Stefan,

I think your proposal makes sense and it has flexibility besides the fact that it reuses some existing patterns.
There are two additional things we should consider and I'm not sure how they would be reflected in the API yet:
1. When updating the priority on the track, if that track is part of a bundle the browser should either throw an error or unbundle automatically if the bundle contains tracks that have different priorities. In any case, bundling will have a role in the fulfillment of the priority request.
2. I think that RTCTransportHandler would need a convenience method to return the 5 tuple to the developer. This will be used when negotiating QoS with the network (if necessary).

Thanks,
Dan


-----Original Message-----
From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com<mailto:stefan.lk.hakansson@ericsson.com>]
Sent: Tuesday, January 08, 2013 1:15 AM
To: public-webrtc@w3.org<mailto:public-webrtc@w3.org>
Subject: ACTION-62, Priority API

ACTION-62, http://www.w3.org/2011/04/webrtc/track/actions/62, "Propose
Priority API" was assigned to me at Lyon.

There are several way to do this, e.g.
* Constraints at addStream time
* Fortran style, e.g.
** pc.setPriority(track, priority);
* Fortran style with constraints
** pc.applyConstraints(track, constraints); //constraint for priority
included
* Follow what we did for DTMF, allow the creation of a separate object
** pc.createTransportController(track);
** Operate on the "TransporController".

After some thinking, I think I prefer the last solution (i.e. enable the
creation of a separate object to handle transport related things) in
combination with re-using constraints in the way Travis proposed in v6 [1].

There are a couple of reasons for this:
* Constraints at addStream time can't handle tracks added to a stream at
a later time, nor does it allow for changes
* I think we will not only want to change priority, but also things like
bit-rate, video codec operation (CBR, VBR), DTX on/off, . - this means
the Fortral style design would make the PeerConnection API grow a lot
* Fortran style with Constraints is quite OK, but gives no natural place
for reporting if during the session a constraint can (temporarily) not
be met

So what I propose is basically:

* Add one new method to PeerConnection:
** createTransportHandler - takes a track (must be in a MediaStream in
localStreams - otherwise there will be an error) as argument and returns
a RTCTransportHandler object

* The RTCTransportHandler (and please propose better names!) uses
constraints in the same way is outlined in section 6.2 of [1]
** Initial constraints are priority and bitrate - we can add later as we
see need

This design is very similar to the one selected for DTMF, re-uses
constraints and how they are proposed to be used with MediaStreamTracks.

I have attached a pdf with a more complete proposal.

Is this a reasonable approach?

Stefan

[1]
http://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/proposals/SettingsAPI_proposal_v6.html