Looks good to me, but I'd prefer /as/because/ Gorry > 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) >> > >