Payload Working Group                                      S. Nandakumar
Internet-Draft                                                     Cisco
Intended status: Standards Track                             C. Holmberg
Expires: June 10, 2014                                          Ericsson
                                                        December 7, 2013


  Payload specific parameters for specifying video resolution in SDP.
          draft-nandakumar-payload-sdp-max-video-resolution-00

Abstract

   With the rise in realtime communication applications supporting
   video, there is a need for receivers of the video to setup
   appropriate expectations on their receive capacity for handling
   various video image resolutions.  Setting up the maximum supported
   image resolution that could be handled by an Endpoint is important to
   successfully decode and render the received video streams.  This
   document proposes SDP format specific parameters for specifying the
   maximum image width and height resolutions along with their behavior
   under the [RFC3264] Offer/Answer SDP usage.

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 June 10, 2014.

Copyright Notice

   Copyright (c) 2013 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Nandakumar & Holmberg     Expires June 10, 2014                 [Page 1]


Internet-Draft        Video Resolution Negotiation         December 2013


   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Payload Format Parameters . . . . . . . . . . . . . . . . . . . 3
     3.1.  Media Type Registration . . . . . . . . . . . . . . . . . . 3
   4.  SDP Parameters  . . . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  Mapping of the parameters to SDP  . . . . . . . . . . . . . 4
     4.2.  Usage with SDP offer/answer . . . . . . . . . . . . . . . . 4
   5.  SDP Examples  . . . . . . . . . . . . . . . . . . . . . . . . . 4
     5.1.  Successful Scenario . . . . . . . . . . . . . . . . . . . . 4
     5.2.  Failure Scenario  . . . . . . . . . . . . . . . . . . . . . 5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 6




























Nandakumar & Holmberg     Expires June 10, 2014                 [Page 2]


Internet-Draft        Video Resolution Negotiation         December 2013


1.  Terminology

   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.


2.  Introduction

   Off late, multimedia communication sessions are increasingly
   supporting video by default.  This is further fueled with the advent
   of IETF technology standards such as RTCWeb, CLUE.  In order to
   successfully decode an incoming video stream, the decoder at the
   Endpoint must be capable of handling the image resolution of the
   received video streams, amongst other things.  This document defines
   SDP payload format specific paramaters (a=fmtp) to setup an upper
   limit on the receiver's capability in successfully handling various
   image resolutions of the incoming video stream.  It also describes
   [RFC3264] Offer/Answer procedures for the same.

   Individual RTP Payload specifications that intend to specify limits
   on the decoder's image resolution handling MUST refer to the
   parameters defined in this document to achieve the functionality.


3.  Payload Format Parameters

   The media subtype parameters max-recv-width and max-recv-height
   specified below MAY be used to signal the capabilities of a receiver
   implementation.  These parameters MUST NOT be used for any other
   purposes.

3.1.  Media Type Registration

   New Parameters
   1.  max-recv-width: The value of max-recv-width is an integer
       indicating maximum horizontal image range in pixels.  When max-
       recv-width is signaled, the sender MUST NOT send any media with
       horizontal image resolutions higher than the value requested by
       the receiver.
   2.  max-recv-height: The value of max-recv-height is an integer
       indicating maximum vertical image range in pixels.  When max-
       recv-height is signaled, the sender MUST NOT send any media with
       vertical image resolutions higher than the value requested by the
       receiver.






Nandakumar & Holmberg     Expires June 10, 2014                 [Page 3]


Internet-Draft        Video Resolution Negotiation         December 2013


4.  SDP Parameters

4.1.  Mapping of the parameters to SDP

   The parameters max-recv-width, max-recv-height when present, MUST be
   included in the "a=fmtp" line of SDP.  These parameters are expressed
   as a media type string, in the form of a semicolon separated list of
   parameter=value pairs.

   When signaled, both the attributes MUST be included and they signal
   the capabilities of a media receiver's implementation.  These
   parameters are implicitly downgradable from the media sender's
   perspective, i.e, they express the upper limit for a media sender's
   possible behavior.  Thus a media sender MAY select to set its encoder
   using only lower/lesser or equal values of these parameters when
   sending media.

4.2.  Usage with SDP offer/answer

   The interpretation of the parameters max-recv-width and max-recv-
   height depends on the SDP direction attribute.  When the direction is
   sendrecv or recvonly, the value of this parameter indicates the
   ranges of horizontal and vertical image resolutions the media
   receiver is capable of rendering successfully.  When the direction is
   sendonly, these attributes have no interpretation and MUST be ignored
   by the receiving Endpoint, if present.

   If the media sender is not capable of sending any resolution lower
   than or equal to the values requested by the media receiver, the
   Offer/Answer procedure is considered as failed.

   An SDP Answerer MUST NOT include these parameters in the SDP Answer
   unless they are specified in the associated SDP Offer.

   If the SDP Answer doesn't contain these parameters, the Offerer MUST
   follow the procedures in the same way as if these parameters were
   never sent in the first place.  This might happen if the Answerer
   doesn't support/understand these parameters.


5.  SDP Examples

5.1.  Successful Scenario

   The example SDP below shows an Offer from an Endpoint that is capable
   of receiving up to [720,576] video image resolution for the VP8 codec
   with Payload Type 96.




Nandakumar & Holmberg     Expires June 10, 2014                 [Page 4]


Internet-Draft        Video Resolution Negotiation         December 2013


   m=video 62537 RTP/SAVPF 96
   a=rtpmap:96 VP8/90000
   a=fmtp:96 max-fr=30;max-recv-width=720;max-recv-height=576
   a=sendrecv

                                 SDP Offer

   The example SDP below shows an Answer from an Endpoint that is
   capable of receiving only up to [640,480] video image resolutions.

   m=video 62537 RTP/SAVPF 96
   a=rtpmap:96 VP8/90000
   a=fmtp:96 max-fr=30;max-recv-width=640;max-recv-height=480
   a=sendrecv

                                SDP Answer

5.2.  Failure Scenario

   The example SDP below shows an Offer from an Endpoint that is capable
   of receiving up to [720,576] video image resolution for the H.264
   codec with Payload Type 100.

m=video 62537 RTP/SAVPF 100
a=rtpmap:100 H264/90000
a=fmtp:100
  profile-level-id=42800d;max-mbps=40500;max-recv-width=720;max-recv-height=576
a=sendrecv

                                 SDP Offer

   The example SDP below shows the Answer rejecting the above SDP Offer,
   since the receiver of the SDP is unable to support the Offerer's
   requested image resolutions for sending the media.

   m=video 0 RTP/SAVPF 100
   a=rtpmap:100 H264/90000

                                SDP Answer


6.  IANA Considerations

   The parameters specified in Section 3 of this document will be
   registered with the IANA.






Nandakumar & Holmberg     Expires June 10, 2014                 [Page 5]


Internet-Draft        Video Resolution Negotiation         December 2013


7.  Acknowledgements

   The authors would like to thanks Cullen Jennings, Ali C. Began,
   Harald Alvestrand and Roni Evens for their review and valuable
   comments.


8.  Normative References

   [RFC3264]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
              with Session Description Protocol (SDP)", RFC 3264,
              June 2002.

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


Authors' Addresses

   Suhas Nandakumar
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: snandaku@cisco.com


   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com
















Nandakumar & Holmberg     Expires June 10, 2014                 [Page 6]