(In reply to comment #0)
> There is no API allowing a developer to prioritize video over audio or vice
> versa. Nor to set the priority of the data channel above or below that of
> audio and/or video. Nor to set the priority of individual data channels
> above or below one another and/or audio and video.
> 
> Priority APIs have been discussed at previous F2F meetings, though
> individual stream priority was not resolved.

I recently sent a proposal to the list: http://lists.w3.org/Archives/Public/public-webrtc/2013Jan/0005.html

But there is no agreement yet on the right way to do this.

I'd like to +1 this bug. I think now would be a good time to get a good API proposals and get it into the spec.

(In reply to comment #2)
> I'd like to +1 this bug. I think now would be a good time to get a good API
> proposals and get it into the spec.

I brought forward before, and am proposing again, that we - in a similar vein to how a "RTCDTMFSender" sender is created off a PeerConnection but bound to a MediaStreamTrack - allow for the creation of an object that allows setting of priority and other transport related things per track using the established Constraints model.

So we could add to PeerConnection something like:

     RTCTransportHandler createTransportHandler (MediaStreamTrack track);

The TransportHandler would use Constraints, e.g.:

interface RTCTransportHandler {
     readonly attribute MediaStreamTrack track;
     TrackTransportConstraints? constraints ();
     void applyConstraints (TrackTransportConstraints constraints);
     attribute EventHandler onoverconstrained;
};

Constraints could be:

* Priority
* bitrate (min, max)
* audio content (speech or general audio)
* video codec operation (VBR, CBR)

and so on (and of course we need to agree on an initial set).

I second Stefan's proposal.

I support considerring priority API now.

The WG consensus is that we can live without this for the 1.0 API version

The likely control surface is the RTPSender API.

I am NOT ok with closing this bug and would like it reopened. I think there are several of us that feel it is very important to have this API in 1.0 and varios browse can decide what part of they want to implement