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> 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]
> 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
>
>