RE: ACTION-62, Priority API

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] 
Sent: Tuesday, January 08, 2013 1:15 AM
To: 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

Received on Tuesday, 8 January 2013 17:18:11 UTC