Re: ACTION-62, Priority API

Dan,

thanks for good feedback. Responses in-line.

On 2013-01-08 18:17, DRUTA, DAN 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.

I had not gone that far in my thinking yet. I think there should be an 
"overconstrained" event fired if the browser can't fulfill a priority 
request that is labelled as mandatory. But I think we do not know what 
e.g. priority = very-high means yet. Is it special treatment in the 
rate-adaptation, is it DSCP marking, is it something negotiated with the 
network, a combination, or anything else?

So I took the simple route of proposing an API where you can ask for 
priority and get feedback if it can't be fulfilled, and left the hard 
stuff for the IETF folks...

> 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).

That might be convenient, on the other hand I think the 5-tuple can be 
acquired via the stats API. But thinking of it, the object I propose 
could fire an event when the transport (5-tuple) changes. That could be 
convenient.

>
> 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 Wednesday, 9 January 2013 08:15:57 UTC