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.
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. 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.
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
----------------------------------------------------------------------