One document matched: draft-alvestrand-rtcweb-resolution-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-alvestrand-rtcweb-resolution-00"
ipr="trust200902">
<front>
<title abbrev="Resolution negotiation">RTCWEB Resolution
Negotiation</title>
<author fullname="Harald Alvestrand" initials="H. T." surname="Alvestrand">
<organization>Google</organization>
<address>
<email>harald@alvestrand.no</email>
</address>
</author>
<date day="30" month="April" year="2012" />
<abstract>
<t>This draft offers a proposal for a fragment of the SDP usage rules
for RTCWEB: Requirements for supporting resolution negotiation.</t>
<t>It proposes to use SDP both for initial and within-call resolution
configuration, and suggests that COP should be mentioned as an optional,
not mandatory, mechanism.</t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>This draft offers a proposal for a fragment of the SDP usage rules
for RTCWEB: Requirements for supporting resolution negotiation.</t>
<t>It proposes to use SDP, <xref target="RFC6236"></xref> in particular,
both for initial and within-call resolution configuration, with the
"a=recv-ssrc:imageattr" mechanism from <xref
target="I-D.lennox-mmusic-sdp-source-selection"></xref> as a per-stream
mechanism, and suggests that Codec Operation Point (COP) specified in
<xref target="I-D.westerlund-avtext-codec-operation-point"></xref>
should be mentioned as an optional, not mandatory, mechanism.</t>
</section>
<section title="Requirements">
<t>The relevant requirement for video resolution negotiation from the
RTCWEB use cases document <xref
target="I-D.ietf-rtcweb-use-cases-and-requirements"></xref> is:</t>
<t><list style="symbols">
<t>F25 The browser SHOULD use encoding of streams suitable for the
current rendering (e.g. video display size) and SHOULD change
parameters if the rendering changes during the session.</t>
</list></t>
<t>The scenarios from which this requirement is derived are:</t>
<t><list style="symbols">
<t>4.2.1 Simple Video Communication Service - user changes size of
video during the session.</t>
<t>4.2.2 Simple Video Communication Service, NAT/FW that blocks UDP
- as above</t>
<t>4.2.3 Simple Video Communication Service, global service provider
- as above</t>
<t>4.2.4 Simple Video Communication Service, enterprise aspects - as
above</t>
<t>4.2.5 Simple Video Communication Service, access change -
bandwidth available changes dramatically during call (wired Ethernet
to 3G)</t>
<t>4.2.6 Simple Video Communication Service, QoS - as 4.2.5</t>
<t>4.2.7 Simple Video Communication Service with sharing - as
above</t>
<t>4.2.8 Simple video communication service with inter-operator
callling - as above</t>
<t>4.2.10 Multiparty video communication - user changes size of
video</t>
<t>(4.3.3 Video conferencing system with central server does NOT
list F25 as a derived requirement, but notes that "it is important
that the delay from when a video stream is selected for display
until the video can be displayed is short").</t>
</list></t>
<t>Formulating the requirements in a form more amenable to
implementation, there needs to be specified functions that allow the
implementation:</t>
<t><list style="symbols">
<t>To negotiate a maximum spatial resolution for all videos at call
setup time</t>
<t>To negotiate a maximum temporal resolution ("frame rate") across
all videos at call setup time</t>
<t>To negotiate other parameters as needed to ensure that the sender
will not send a stream that the receiver is unable to handle.</t>
<t>To indicate the desire of the recipient for a particular spatial
or temporal resolution on a particular video source, at any given
time during the call</t>
<t>To indicate the intent of the sender to send a video source in a
particular spatial or temporal resolution, at any given time during
the call</t>
</list>This document does not mention other requirements.</t>
</section>
<section title="Initial negotiation of parameters">
<t>We assume that the normal (payload-dependent) procedures for codec
negotiation are sufficient to negotiate any codec parameters needed to
ensure that the decoder can handle all incoming streams.</t>
<t>After the initial negotiation, the following variables MUST have a
known value for each RTP session (represented by one or more m=
lines):</t>
<t><list style="symbols">
<t>The maximum X-resolution of any handlable video stream</t>
<t>The maximum Y-resolution of any handlable video stream</t>
<t>The maximum bitrate in bits per second</t>
<t>The maximum framerate in frames per second</t>
</list></t>
<t>An RTCWEB client MUST support negotiation of resolution using the
"imageattr" attribute, as documented in <xref
target="RFC6236"></xref>.</t>
<t>An RTCWEB client MUST support a SAR value of 1.0 (square pixels), and
MAY choose to support only the 1.0 value of the "sar" attribute.</t>
<t>The interpretation of the negotiation is that any video stream in the
m= line containing the a=imageattr attribute will have a resolution
within the bounds established by the negotiation.</t>
<t>An RTCWEB client MUST support negotiation of the "a=framerate"
attribute, as specified in <xref target="RFC4566"></xref> section 6.
Note that this is an upper bound on framerate; there is no lower bound
negotiated.</t>
<t>These bounds MAY be renegotiated over the course of the call, but
MUST NOT be renegotiated to render any currently transmitted video
stream out of bounds</t>
<t>These bounds may be supplemented by payload-specific mechanisms, and
there is no guarantee that all resolutions within the bounds can be
supported.</t>
</section>
<section title="Per-stream declaration of desired video resolution">
<section title="SDP-based per-stream declaration">
<t></t>
<t>An RTCWEB client MUST support per-SSRC requests for video
resolutions, as described in <xref
target="I-D.lennox-mmusic-sdp-source-selection"></xref>. To be
precise, it MUST support the a=remote-ssrc:<ssrc> framerate: and
a=remote-ssrc:<ssrc>imageattr: attributes.</t>
<t>This satisfies the requirement to indicate the desire of the
recipient for a particular spatial or temporal resolution.</t>
<t>We assume that the media sent from a sender to a receiver contains
enough information inside the media format to tell what the resolution
and framerate is.</t>
<t>The bounds specified for a single stream MUST be within the bounds
previously negotiated for the whole session.</t>
<t>This mechanism does not form a negotiation; as specified in the
referenced document, it is a declaration by the recipient of what
stream formats he desires, and the sender will respond by changing the
video he sends. The sender SHOULD honor the requests by the
receiver.</t>
<t>The mere fact that a stream is within the bounds negotiated for the
session is not a sufficient condition for guaranteeing that the stream
will be accepted; any number of issues, including temporary lack of
resources at the recipient. Thus, the sender MUST always be prepared
for one or more media streams to be refused by the recipient.</t>
</section>
<section title="COP-based per-stream declaration">
<t>An RTCWEB client MAY support the COP mechanism <xref
target="I-D.westerlund-avtext-codec-operation-point"></xref> to
negotiate the resolution of video within the limits established by the
SDP negotiation without the need for additional SDP exchanges.</t>
</section>
<section title="Tradeoffs discussion">
<t>This section may be deleted before publication as an RFC; its main
purpose is to discuss the decision to make the SDP-based mechanism a
MUST and the COP-based mechanism a MAY.</t>
<t>Both mechanisms work by having the receiver declare a wish for a
resolution, and the sender switching to that resolution. The main
differences are:</t>
<t><list style="symbols">
<t>In SDP, given the nature of the RTCWEB signalling model, the
notification that a change is needed must be sent to the
Javascript, which then has to use the createOffer mechanism to
create a suitable SDP object, and use whatever mechanism is used
for negotiation to send that request to the sender.</t>
<t>In COP, the decision to signal can possibly be taken either at
Javascript level or inside the browser, but once the decision is
taken, all further messaging is done by the browser using RTCP
packets; Javascript is not involved.</t>
<t>For SDP, signalling follows the signalling path, which may be
via a data channel along the media path, or may be via a
completely different mechanism.</t>
<t>For COP, signalling always follows the media path's return
path.</t>
<t>For SDP, the unbounded nature of the imageattr= specification
allows a wide variety of sizes to be requested, including possibly
unsuitable ones.</t>
<t>For COP, the list of alternatives is created explicitly using
the Operation Point mechanism.</t>
<t>For SDP, the signalling transport is (presumably) done using a
reliable transport</t>
<t>For COP, timeout and retransmission must be implemented in the
requester.</t>
<t>For SDP, if imageattr= is already supported, the changes to the
parsers involved are small.</t>
<t>For COP, support involves embedding a completely new
functionality set within the RTCP components of the RTP-supporting
libraries.</t>
<t>For SDP, the defining draft specifies some other mechanisms
that are not mentioned here, such as "pause".</t>
<t>For COP, the defining draft specifies some configurations that
are not part of the RTCWEB requirements set, such as
multicast.</t>
<t>SDP does not consider the case of substreams for scalable video
media.</t>
<t>COP deos consider configuration of substreams.</t>
<t>For SDP, an IPR disclosure seeming to assert RF licensing has
been made against the defining draft <xref
target="ipr-ssrc"></xref>.</t>
<t>For COP, an IPR disclosure asserting RAND (not RF) licensing
has been made against the defining draft, with no assertion on
which parts of the draft it applies to. <xref
target="ipr-cop"></xref></t>
</list></t>
</section>
</section>
<section title="Usage considerations">
<t>This section notes briefly some of the situations in which resizing
might be desirable.</t>
<t><list style="symbols">
<t>Change of display window size on screen (window manager resize,
for instance)</t>
<t>Changing the display target between a smaller and a larger window
("large current talker", for instance)</t>
<t>Retargeting of the display to a different display surface
("attach external monitor", for instance)</t>
<t>Temporary CPU or GPU overload due to media stream processing
conflicting with other tasks, including handling a large number of
media streams</t>
<t>Recovery from such overload situations</t>
<t><<< more? >>></t>
</list>Adaptation to bandwidth changes (congestion control) is NOT
included in this set, since a more correct model for this is that it
should be detected by the sender and the receiver operating in tandem,
and the sender should decide which flows, if any, need their bitrates
changed.</t>
<t>Turning video streams off (mute) is also not included; use of "size =
0" has been suggested as one mechanism for video mute, but this proposed
mechanism is not addressed in this memo.</t>
</section>
<section title="Relation to WebRTC API constraints">
<t>It is intended that the resolution negotiation be influenced by the
constraints set by the application of either mandatory or optional
constraints at the WebRTC API, as registered in the registry established
by <xref target="I-D.burnett-rtcweb-constraints-registry"></xref>.</t>
<t>The following relationships hold for all attributes that the
implementation intends to satisfy (note that the constraints listed here
have NOT been registered yet):</t>
<t>video-min-height >= value of imageattr y= xyrange lower bound</t>
<t>video-max-height <= value of imageattr y= xyrange upper bound</t>
<t>video-min-framerate is not represented in SDP</t>
<t>video-max-framerate <= value of a=framerate attribute</t>
<t>video-min-aspect-ratio <= value of imageattr "par=" prange lower
bound</t>
<t>video-max-aspect-ratio >= value of imageattr "par=" prange upper
bound</t>
<t>The implementation is free to increase "min" values or decrease "max"
values (make requirements more restrictive) and add "step" in order to
fit with its implementation restrictions.</t>
<t>Constraints specified at PeerConnection creation time are reflected
as SDP-wide values. Constraints specified when creating a MediaStream or
attaching a MediaStream to a PeerConnection are reflected as
ssrc-specific values.</t>
<t>The envisioned usage is that the application will not use the values
specified by the client directly, but choose the minimum of the
specified bounds and the implementation limitations of the browser,
adjusted for any odd requirements of the codec or soft/hardware, and
choose a representation in the SDP that adequately represents the
possible configurations.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document makes no request of IANA.</t>
<t>Note to RFC Editor: this section may be removed on publication as an
RFC.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>All considerations related to normal usage of SDP apply to this
memo.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t></t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.4566'?>
<?rfc include='reference.RFC.6236'?>
<?rfc include='reference.I-D.ietf-rtcweb-use-cases-and-requirements'?>
<?rfc include='reference.I-D.lennox-mmusic-sdp-source-selection'?>
<?rfc include='reference.I-D.burnett-rtcweb-constraints-registry'?>
<?rfc include='reference.I-D.westerlund-avtext-codec-operation-point'?>
</references>
<references title="Informative References">
<reference anchor="ipr-cop">
<front>
<title>Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR
related to draft-westerlund-avtext-codec-operation-point-00 -
https://datatracker.ietf.org/ipr/1701/</title>
<author fullname="LM ericsson">
<organization></organization>
</author>
<date day="6" month="March" year="2012" />
</front>
</reference>
<reference anchor="ipr-ssrc">
<front>
<title>Vidyo, Inc.'s Statement about IPR related to
draft-lennox-mmusic-sdp-source-selection-00 -
https://datatracker.ietf.org/ipr/1170/</title>
<author>
<organization></organization>
</author>
<date />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:40:45 |