> On Apr 3, 2016, at 3:37 PM, Black, David <david.black@xxxxxxx> wrote: > > I see a couple of Magnus's points that appear to need additional text > in the draft: > > [1] Flow Type in application-facing browser API: > >>>>>> o Flow Type: The browser provides this input as it knows if >>>>>> the flow is audio, interactive video with or without audio, >>>>>> non-interactive video with or without audio, or data. > > [... snip ...] > >> The main issue here is that to me it was not clear that "Interactive >> Video with or without audio" allows for setting these DSCP values also >> for the RTP stream containing audio also. This, I do see a need for >> clarification on. > > Propose an additional sentence: > OLD > o Flow Type: The browser provides this input as it knows if the flow > is audio, interactive video with or without audio, non-interactive > video with or without audio, or data. > NEW > o Flow Type: The browser provides this input as it knows if the flow > is audio, interactive video with or without audio, non-interactive > video with or without audio, or data. For audio that is associated > with a video flow, the flow type of the associated video MAY > be used instead of the associated audio type. > > I hesitate to say anything stronger than "MAY" here. Looks good. > > [2] What does "interactive" mean in an implementation?: We could add something along lines of ..... Currently in WebRTC, media sent over RTP is assumed to be interactive while media streamed over HTTP is assumed not to be. Future WebRTC extensions could allow streamed media over RTP. > >> The issue is that this document is called: DSCP and other packet >> markings for WebRTC QoS. Then this document define something that is not >> immediately mappable onto what is being defined in the other WebRTC >> specifications. That is why I am raising that there need to be more >> clear coupling. If that coupling is to mostly happen in another >> document, can we at least then have a proposal on the table for that >> change to ensure that the result is understandable. > > Well, this TSVWG draft is definitely not the right place for a discussion of > when a video flow is interactive or non-interactive - I hope we can agree > on that. > > Beyond that, as Cullen (Jennings) is both an author of this document and > one of the chairs of the rtcweb WG, I'd suggest that he and/or the rtcweb > WG propose an appropriate location for discussion of when a video flow > is interactive or non-interactive. This TSVWG draft would then have an > additional sentence added, e.g., > > See [TBD] for further discussion of how to determine > whether a video flow is interactive vs. non-interactive. > > I believe that the added reference here ([TBD] above) would be normative. > > Cullen? That discussion happened long ago for WebRTC and we decided we did not need a JavaScript controls point in the WebRTC API to indicate if RTP was interactive or not. If people start doing streaming video over RTP we can come back and revisit this and trivially add an API to indicate that in the W3C WebRTC API. Part of what drove this decision is the likes of Netflix / ITunes / Youtube are not asking the browser vendors for streaming media over RTSP or RTP. They think HTTP works much better for this. Thus the browser vendors see no need for non interactive video over RTP. I agree with Magnus that this might change some day in the future but right now, I think it's close enough that everyone can live with it. I'm not OK in treating it like some open issue that is still in discussion that somehow holds up this spec - it's not. > > Thanks, --David (as document shepherd) >