[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                      H. Alvestrand
Internet-Draft                                                    Google
Intended status: Standards Track                          April 30, 2012
Expires: November 1, 2012


                     RTCWEB Resolution Negotiation
                 draft-alvestrand-rtcweb-resolution-00

Abstract

   This draft offers a proposal for a fragment of the SDP usage rules
   for RTCWEB: Requirements for supporting resolution negotiation.

   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.

Requirements Language

   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 RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on November 1, 2012.

Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Alvestrand              Expires November 1, 2012                [Page 1]


Internet-Draft           Resolution negotiation               April 2012


   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Initial negotiation of parameters  . . . . . . . . . . . . . .  4
   4.  Per-stream declaration of desired video resolution . . . . . .  5
     4.1.  SDP-based per-stream declaration . . . . . . . . . . . . .  5
     4.2.  COP-based per-stream declaration . . . . . . . . . . . . .  6
     4.3.  Tradeoffs discussion . . . . . . . . . . . . . . . . . . .  6
   5.  Usage considerations . . . . . . . . . . . . . . . . . . . . .  7
   6.  Relation to WebRTC API constraints . . . . . . . . . . . . . .  8
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     10.1. Normative References . . . . . . . . . . . . . . . . . . .  9
     10.2. Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
























Alvestrand              Expires November 1, 2012                [Page 2]


Internet-Draft           Resolution negotiation               April 2012


1.  Introduction

   This draft offers a proposal for a fragment of the SDP usage rules
   for RTCWEB: Requirements for supporting resolution negotiation.

   It proposes to use SDP, [RFC6236] in particular, both for initial and
   within-call resolution configuration, with the "a=recv-
   ssrc:imageattr" mechanism from
   [I-D.lennox-mmusic-sdp-source-selection] as a per-stream mechanism,
   and suggests that Codec Operation Point (COP) specified in
   [I-D.westerlund-avtext-codec-operation-point] should be mentioned as
   an optional, not mandatory, mechanism.


2.  Requirements

   The relevant requirement for video resolution negotiation from the
   RTCWEB use cases document
   [I-D.ietf-rtcweb-use-cases-and-requirements] is:

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

   The scenarios from which this requirement is derived are:

   o  4.2.1 Simple Video Communication Service - user changes size of
      video during the session.

   o  4.2.2 Simple Video Communication Service, NAT/FW that blocks UDP -
      as above

   o  4.2.3 Simple Video Communication Service, global service provider
      - as above

   o  4.2.4 Simple Video Communication Service, enterprise aspects - as
      above

   o  4.2.5 Simple Video Communication Service, access change -
      bandwidth available changes dramatically during call (wired
      Ethernet to 3G)

   o  4.2.6 Simple Video Communication Service, QoS - as 4.2.5

   o  4.2.7 Simple Video Communication Service with sharing - as above

   o  4.2.8 Simple video communication service with inter-operator
      callling - as above



Alvestrand              Expires November 1, 2012                [Page 3]


Internet-Draft           Resolution negotiation               April 2012


   o  4.2.10 Multiparty video communication - user changes size of video

   o  (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").

   Formulating the requirements in a form more amenable to
   implementation, there needs to be specified functions that allow the
   implementation:

   o  To negotiate a maximum spatial resolution for all videos at call
      setup time

   o  To negotiate a maximum temporal resolution ("frame rate") across
      all videos at call setup time

   o  To negotiate other parameters as needed to ensure that the sender
      will not send a stream that the receiver is unable to handle.

   o  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

   o  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

   This document does not mention other requirements.


3.  Initial negotiation of parameters

   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.

   After the initial negotiation, the following variables MUST have a
   known value for each RTP session (represented by one or more m=
   lines):

   o  The maximum X-resolution of any handlable video stream

   o  The maximum Y-resolution of any handlable video stream

   o  The maximum bitrate in bits per second





Alvestrand              Expires November 1, 2012                [Page 4]


Internet-Draft           Resolution negotiation               April 2012


   o  The maximum framerate in frames per second

   An RTCWEB client MUST support negotiation of resolution using the
   "imageattr" attribute, as documented in [RFC6236].

   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.

   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.

   An RTCWEB client MUST support negotiation of the "a=framerate"
   attribute, as specified in [RFC4566] section 6.  Note that this is an
   upper bound on framerate; there is no lower bound negotiated.

   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

   These bounds may be supplemented by payload-specific mechanisms, and
   there is no guarantee that all resolutions within the bounds can be
   supported.


4.  Per-stream declaration of desired video resolution

4.1.  SDP-based per-stream declaration

   An RTCWEB client MUST support per-SSRC requests for video
   resolutions, as described in
   [I-D.lennox-mmusic-sdp-source-selection].  To be precise, it MUST
   support the a=remote-ssrc:<ssrc> framerate: and a=remote-
   ssrc:<ssrc>imageattr: attributes.

   This satisfies the requirement to indicate the desire of the
   recipient for a particular spatial or temporal resolution.

   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.

   The bounds specified for a single stream MUST be within the bounds
   previously negotiated for the whole session.

   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



Alvestrand              Expires November 1, 2012                [Page 5]


Internet-Draft           Resolution negotiation               April 2012


   the video he sends.  The sender SHOULD honor the requests by the
   receiver.

   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.

4.2.  COP-based per-stream declaration

   An RTCWEB client MAY support the COP mechanism
   [I-D.westerlund-avtext-codec-operation-point] to negotiate the
   resolution of video within the limits established by the SDP
   negotiation without the need for additional SDP exchanges.

4.3.  Tradeoffs discussion

   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.

   Both mechanisms work by having the receiver declare a wish for a
   resolution, and the sender switching to that resolution.  The main
   differences are:

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

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

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

   o  For COP, signalling always follows the media path's return path.

   o  For SDP, the unbounded nature of the imageattr= specification
      allows a wide variety of sizes to be requested, including possibly
      unsuitable ones.




Alvestrand              Expires November 1, 2012                [Page 6]


Internet-Draft           Resolution negotiation               April 2012


   o  For COP, the list of alternatives is created explicitly using the
      Operation Point mechanism.

   o  For SDP, the signalling transport is (presumably) done using a
      reliable transport

   o  For COP, timeout and retransmission must be implemented in the
      requester.

   o  For SDP, if imageattr= is already supported, the changes to the
      parsers involved are small.

   o  For COP, support involves embedding a completely new functionality
      set within the RTCP components of the RTP-supporting libraries.

   o  For SDP, the defining draft specifies some other mechanisms that
      are not mentioned here, such as "pause".

   o  For COP, the defining draft specifies some configurations that are
      not part of the RTCWEB requirements set, such as multicast.

   o  SDP does not consider the case of substreams for scalable video
      media.

   o  COP deos consider configuration of substreams.

   o  For SDP, an IPR disclosure seeming to assert RF licensing has been
      made against the defining draft [ipr-ssrc].

   o  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.  [ipr-cop]


5.  Usage considerations

   This section notes briefly some of the situations in which resizing
   might be desirable.

   o  Change of display window size on screen (window manager resize,
      for instance)

   o  Changing the display target between a smaller and a larger window
      ("large current talker", for instance)

   o  Retargeting of the display to a different display surface ("attach
      external monitor", for instance)




Alvestrand              Expires November 1, 2012                [Page 7]


Internet-Draft           Resolution negotiation               April 2012


   o  Temporary CPU or GPU overload due to media stream processing
      conflicting with other tasks, including handling a large number of
      media streams

   o  Recovery from such overload situations

   o  <<< more? >>>

   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.

   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.


6.  Relation to WebRTC API constraints

   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 [I-D.burnett-rtcweb-constraints-registry].

   The following relationships hold for all attributes that the
   implementation intends to satisfy (note that the constraints listed
   here have NOT been registered yet):

   video-min-height >= value of imageattr y= xyrange lower bound

   video-max-height <= value of imageattr y= xyrange upper bound

   video-min-framerate is not represented in SDP

   video-max-framerate <= value of a=framerate attribute

   video-min-aspect-ratio <= value of imageattr "par=" prange lower
   bound

   video-max-aspect-ratio >= value of imageattr "par=" prange upper
   bound

   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.




Alvestrand              Expires November 1, 2012                [Page 8]


Internet-Draft           Resolution negotiation               April 2012


   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.

   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.


7.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


8.  Security Considerations

   All considerations related to normal usage of SDP apply to this memo.


9.  Acknowledgements


10.  References

10.1.  Normative References

   [I-D.burnett-rtcweb-constraints-registry]
              Burnett, D., "IANA Registry for RTCWeb Media Constraints",
              draft-burnett-rtcweb-constraints-registry-00 (work in
              progress), March 2012.

   [I-D.ietf-rtcweb-use-cases-and-requirements]
              Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real-
              Time Communication Use-cases and Requirements",
              draft-ietf-rtcweb-use-cases-and-requirements-06 (work in
              progress), October 2011.

   [I-D.lennox-mmusic-sdp-source-selection]
              Lennox, J. and H. Schulzrinne, "Mechanisms for Media
              Source Selection in the Session Description Protocol
              (SDP)", draft-lennox-mmusic-sdp-source-selection-03 (work



Alvestrand              Expires November 1, 2012                [Page 9]


Internet-Draft           Resolution negotiation               April 2012


              in progress), January 2012.

   [I-D.westerlund-avtext-codec-operation-point]
              Westerlund, M., Burman, B., and L. Hamm, "Codec Operation
              Point RTCP Extension",
              draft-westerlund-avtext-codec-operation-point-00 (work in
              progress), March 2012.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4566]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
              Description Protocol", RFC 4566, July 2006.

   [RFC6236]  Johansson, I. and K. Jung, "Negotiation of Generic Image
              Attributes in the Session Description Protocol (SDP)",
              RFC 6236, May 2011.

10.2.  Informative References

   [ipr-cop]  "Telefonaktiebolaget LM Ericsson (publ)'s Statement about
              IPR related to
              draft-westerlund-avtext-codec-operation-point-00 -
              https://datatracker.ietf.org/ipr/1701/", March 2012.

   [ipr-ssrc]
              "Vidyo, Inc.'s Statement about IPR related to
              draft-lennox-mmusic-sdp-source-selection-00 -
              https://datatracker.ietf.org/ipr/1170/".


Author's Address

   Harald Alvestrand
   Google

   Email: harald@alvestrand.no














Alvestrand              Expires November 1, 2012               [Page 10]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/