Internet DRAFT - draft-nandakumar-payload-sdp-max-video-resolution
draft-nandakumar-payload-sdp-max-video-resolution
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]
