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]