Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Initial pass at adding QoS API #228

Closed
wants to merge 5 commits into from
Closed

Initial pass at adding QoS API #228

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
97dd542
Initial pass at adding QoS API
fluffy May 9, 2015
1b92989
fixed typeo in id
fluffy May 10, 2015
ee68832
fixed typeo in id
fluffy May 10, 2015
4bc7e7d
changed qos to be called priority and pointed at transport draft
fluffy May 11, 2015
7b2317b
remvoed S from RTCWEB-TRANSPORTS ref
fluffy May 19, 2015
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 62 additions & 2 deletions webrtc.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2054,6 +2054,44 @@ <h4>RTCPeerConnectionIceEvent</h4>
</dl>
</section>
</section>

<section>
<h2>Priority and QoS Model</h2>

<p> Many applications have multiple media flows of the same
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this also contain a reference to rtcweb-transport, for the intra-browser prioritization aspect?

data type and often some of the flows are more important than
others. WebRTC uses the priority and Quality of Service (QoS) framework
described in [[!RTCWEB-TRANSPORT]] and [[!TSVWG-RTCWEB-QOS]]
to provide priority and DSCP marketing for packets that will
help provide QoS in some networking environments. The
priority setting can be used to indicate the relative priority
of various flows. The priority API allows the JavaScript
applications to tell the browser whether a particular media
flow is high, medium, low or of very low importance to the
application by setting the <code>RTCRtpSender.priority</code>
or <code>RTCDataChannel.priority</code> attribtues to one of
the follwing values. </p>

<section>
<h4>PriorityValue Enum</h4>
<dl class="idl" title="enum PriorityValue">
<dt>very-low</dt> <dd>See [[!RTCWEB-TRANSPORT]], Section 4.</dd>
<dt>low</dt> <dd>See [[!RTCWEB-TRANSPORT]], Section 4.</dd>
<dt>medium</dt> <dd>See [[!RTCWEB-TRANSPORT]], Section 4.</dd>
<dt>high</dt> <dd>See [[!RTCWEB-TRANSPORT]], Section 4.</dd>
</dl>
</section>

<p>
JavaScript applications that use this API should be aware
that often better overall user experience is obtained by
lowering the priority of things that are not as important
rather than raising the the priority of the things that are.
</p>


</section>

</section>

<section>
Expand Down Expand Up @@ -2481,7 +2519,17 @@ <h3>RTCRtpSender Interface</h3>
associated, via <code>setLocalDescription</code>,
with this <code><a>RTCRtpSender</a></code> object.
</dd>
</dl>

<dt>attribute PriorityValue priority</dt>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is not the right place for this attribute. As a per-ssrc attribute, it should be on RtpEncodingParams (which haven't landed in the spec yet).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think I agree.
a) RtpEncodingParams don't have a proposal yet. That means it's at risk.
b) -transport's prioritization algorithm talks about prioritization in terms of various tracks being sent at various priorities. Burying them one level down seems like the wrong idea.

Suggest we leave it on RTP sender, but say (when RtpEncodingParams gets proposed) that it can be overridden (to a lower value only, I assume) for individual SSRCs.

<dd>
The <dfn
id="dom-rtpsender-priority"><code>RTCRtpSender.priority</code></dfn>
attribute is the value of the priority setting that is used when sending
packets for this RTCRtpReceiver. It is specified in
[[!RTCWEB-TRANSPORT]], Section 4.
</dd>

</dl>
</section>

<section>
Expand Down Expand Up @@ -2511,6 +2559,7 @@ <h3>RTCRtpReceiver Interface</h3>
In the case where no a=mid attribute is present in the remote
description, a random value will be generated.
</dd>

</dl>
</section>

Expand Down Expand Up @@ -2991,7 +3040,18 @@ <h3>RTCDataChannel</h3>
selected by the script. The attribute MUST return the value to which
it was set when the <code><a>RTCDataChannel</a></code> was
created.</p>
</dd><!--
</dd>

<dt>attribute PriorityValue priority</dt>
<dd>
The <dfn
id="dom-rtcdatachannel-priority"><code>RTCDataChannel.priority</code></dfn>
attribute is the value of the priority setting that is used when sending
packets for this RTCDataChannel. It is specified in
[[!RTCWEB-TRANSPORT]], Section 4.
</dd>

<!--
<dt>readonly attribute long priority</dt>

<dd>
Expand Down