On Mar 23, 2016, at 3:07 AM, Magnus Westerlund
<magnus(_dot_)westerlund(_at_)ericsson(_dot_)com> wrote:
Hi,
Below is the first round on a question, that looks like it needs to be
addressed, thus I bring it into a public discussion.
Den 2016-03-22 kl. 19:48, skrev Paul E. Jones:
The other comment I have is the following:
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.
Yes, a browser knows if a MediaStreamTrack's source is a live
source, i.e. camera or microphone or a file. Which would indicate
the difference between interactive or non. However, I don't
understand what the Flow Type description for video contains "with
or without audio" as the flow definitions in RTCWEB transport
document all indicate flows as containing a single media type. Can
you please clarify?
This relates to the table that follows. The intent is that if a
WebRTC application is sending audio and video (e.g., a
videoconference call), then the same DSCP values might be used for
both the audio and video flows. On the other hand, if only a video
flow is sent alone (perhaps the audio source is an entirely different
device), then the browser can still use the same packet marking.
So, I started commenting on this because, the "Flow Types" in the table are
not really defined. And my interpretation was not that the audio could be
given the same markings as the Video. I only interpreted it as being valid
for the video flow. Thus, I think the actual "flow type" values in Table 1
needs to be better defined. To my knowledge these types are not defined in
any other RTCWeb document.
Which codec it came from make is pretty clear if it is audio or video in the
browser implementation. The word “flow” has many meanings in all the different
contexts but it seems like section 4 is pretty clear on breaking flow down into
media and data types then breaking media down into the various types in the
table and defining them.
Are you getting at the issue of it a audio stream that is with a synchronized
video stream can use the same markings as the video stream ? This tries to
leave the options open and let people read things like Section 4 of RFC 7657.
I think what is needed is a definition list for what is meant. I can see that
pointers for example into RFC 4594 may help making these definitions more
compact.
One thing that might be a bit tricky is actually the difference between
interactive and non-interactive (streaming) usages of WebRTC RTP streams. It
becomes a question if the WebRTC endpoint actually accurately can classify
these differences.
We decided at some point that if the browser is using SRTP, it is assumed to be
interactive and the webrtc specs point at using this. If it is streamed over
HTTP with something like DASH then it is non interactive and browsers could use
the non interactive markings but I don’t think any of the streaming media docs
have been updated yet to point that out.
Yes, a live media source, like an camera or microphone can on first order be
used for classification as interactive, while a file source is
non-interactive. But even the first, can in the application context be
non-interactive. An example would be an lecturer application. Relaxing the
delay from the lecturer to the audience is likely fine, especially if one
have a "raise hand" mechanism and only explicitly invites participants to ask
questions. To my knowledge there are no API surface to indicate these
preferences on the MediaStream or MediaStreamTrack level.
I think this document have a potential valuable difference for the
interactive vs non-interactive, but the rest of the current solution has
difficulties to utilize this difference. From my perspective I am fine with
retaining the difference, but the definition must be clear so that
implementers select the right one. And likely the non-interactive will not be
much utilized until additional API knobs are created.
Agree but I think it is the WebRTC spec that needs to be clear on that, not
this draft.
Cheers
Magnus Westerlund
----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB | Phone +46 10 7148287
Färögatan 6 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto:
magnus(_dot_)westerlund(_at_)ericsson(_dot_)com
----------------------------------------------------------------------