Payload Working Group | S. Nandakumar |
Internet-Draft | Cisco |
Intended status: Standards Track | C. Holmberg |
Expires: June 13, 2014 | Ericsson |
December 10, 2013 |
Payload specific parameters for specifying video resolution in SDP.
draft-nandakumar-payload-sdp-max-video-resolution-00
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.
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 13, 2014.
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 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.
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.
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.
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.
New Parameters
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.
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.
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.
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
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
The parameters specified in Section 3 of this document will be registered with the IANA.
The authors would like to thanks Cullen Jennings, Ali C. Began, Harald Alvestrand and Roni Evens for their review and valuable comments.
[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. |