So, summarizing Magnus's concerns with proposals: > > [1] Flow Type in application-facing browser API: > > 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. Magnus - does that new text suffice? > > [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. I believe the proposed additional sentence addresses the question of how a browser determines whether a video flow is interactive. This proposed sentence will need to cite a WebRTC document that contains a statement to that effect, as I don't think this draft is the right place to be the primary reference for that statement. Magnus - would this approach be ok? Thanks, --David > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@xxxxxx] > Sent: Friday, April 15, 2016 10:48 AM > To: Black, David > Cc: Magnus Westerlund; ietf@xxxxxxxx; tsvwg-chairs@xxxxxxxx; draft-ietf-tsvwg- > rtcweb-qos@xxxxxxxx; tsvwg@xxxxxxxx > Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-rtcweb-qos-15.txt> (DSCP and > other packet markings for WebRTC QoS) to Proposed Standard > > > > 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) > >