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

Versions: 00 draft-guduru-rtcweb-codec-preferences

rtcweb                                                         K. Guduru
Internet-Draft                                       Samsung Electronics
Intended status: Standards Track                            May 16, 2014
Expires: November 17, 2014


                        WebRTC Codec Preferences
             draft-guduru-ietf-rtcweb-codec-preferences-00

Abstract

   WebRTC working group prefers mandatory to implement codecs inside the
   browser to achieve guaranteed interoperability between two WebRTC
   peers.  WebRTC allows browser implementors to support vendor specific
   codecs apart from mandatory codecs.  This document explains the way
   to give preferences for media codecs in WebRTC context out of the
   available codecs in browser for creating the offer / answer.

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 17, 2014.

Copyright Notice

   Copyright (c) 2014 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




Guduru                  Expires November 17, 2014               [Page 1]


Internet-Draft          WebRTC-Codec-Preferences                May 2014


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  getSupportedAudioCodecs . . . . . . . . . . . . . . . . . . .   2
   4.  getSupportedVideoCodecs . . . . . . . . . . . . . . . . . . .   3
   5.  RTCOfferAnswerOptions . . . . . . . . . . . . . . . . . . . .   3
   5.1.  preferedAudioCodecs . . . . . . . . . . . . . . . . . . . .   3
   5.2.  preferedVideoCodecs . . . . . . . . . . . . . . . . . . . .   3
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   4
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   4
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   4

1.  Introduction

   WebRTC specified mandatory to implement codecs for attaining the
   interoperability between browsers and to increase the success rate
   [I-D.ietf-rtcweb-audio].  Browser implementors may support other
   codecs apart from mandatory to implement codecs.  This specification
   describes a mechanism for JavaScript application to check the
   available codecs, to give preferences among the available codecs and
   to remove some codecs if the application don't want to use them.
   This specification extends RTCPeerConnection by adding two new
   methods, getSupportedAudioCodecs and getSupportedVideoCodecs and the
   offer / answer options with sequences of audio and video codec list.
   This process will avoid the SDP mangling for removing and re-ordering
   of codecs.

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

3.  getSupportedAudioCodecs

   The getSupportedAudioCodes method of RTCPeerConnection returns the
   supported audio codecs.  This function SHOULD be called before
   calling createOffer or createAnswer mehtod.







Guduru                  Expires November 17, 2014               [Page 2]


Internet-Draft          WebRTC-Codec-Preferences                May 2014


4.  getSupportedVideoCodecs

   The getSupportedVideoCodes method of RTCPeerConnection returns the
   supported video codecs.  This function SHOULD be called before
   calling createOffer or createAnswer mehtod.

5.  RTCOfferAnswerOptions

   createOffer and createAnswer methods supports optional "options"
   attribute.  A sequence of audio and video codecs, namely
   preferedAudioCodecs and preferedVideoCodecs respectively, in
   applications prefered order SHOULD be included as optional
   constraints in RTCOfferAnswerOptions.  Next sections explain about
   preferedAudioCodecs and preferdVideoCodecs.

5.1.  preferedAudioCodecs

   preferedAudioCodecs optional constraint is a sequence of audio codecs
   in the applications prefered order.  If the application does not
   specify any codec preference, then this attribute MUST not be added
   to RTCOfferAnswerOptions.  If options attribute is not present in the
   createOffer/createAnswer, browser SHOULD arrange the codecs with
   previously specified preference, if specified earlier for that
   session, otherwise browser MAY arrange the codecs with its own
   preferences.  The prefered codec sequence MAY contain the same number
   of audio codecs returned by getSupportedAudioCodecs.  Audio codecs
   other than those supported by browser SHOULD be ignored, if present
   in preferedAudioCodecs.  If the preferedAudioCodecs does not contain
   atleast one audio codec returned by getAudioCodecs, browser SHOULD
   fire an error event UNSUPPORTED_CODECS.  The offer/answer SHOULD_NOT
   contain audo codecs other than those specified in preferedAudioCodecs
   and the order of preference SHOULD be with high priority for the
   codecs first in the preferedAudioCodecs sequence.

5.2.  preferedVideoCodecs

   preferedVideoCodecs optional constraint is a sequence of video codecs
   in the applications prefered order.  If the application does not
   specify any codec preference, then this attribute MUST not be added
   to RTCOfferAnswerOptions.  If options attribute is not present in the
   createOffer/createAnswer, browser SHOULD arrange the codecs with
   previously specified preference, if specified earlier for that
   session, otherwise browser MAY arrange the codecs with its own
   preferences.  The prefered codec sequence MAY contain the same number
   of video codecs returned by getSupportedVideoCodecs.  Video codecs
   other than those supported by browser SHOULD be ignored, if present
   in preferedVideoCodecs.  If the preferedVideoCodecs does not contain
   atleast one video codec returned by getVideoCodecs, browser SHOULD



Guduru                  Expires November 17, 2014               [Page 3]


Internet-Draft          WebRTC-Codec-Preferences                May 2014


   fire an error event UNSUPPORTED_CODECS.  The offer/answer SHOULD_NOT
   contain audo codecs other than those specified by preferedVideoCodecs
   and the order of preference SHOULD be with high priority for the
   codecs first in the preferedVideoCodecs sequence.

6.  Security Considerations

   TBD.

7.  IANA Considerations

   This document requires no actions from IANA.

8.  Acknowledgements

   TBD.

9.  Normative References

   [I-D.ietf-rtcweb-audio]
              Valin, J. and C. Bran, "WebRTC Audio Codec and Processing
              Requirements", draft-ietf-rtcweb-audio-05 (work in
              progress), February 2014.

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

Author's Address

   Kiran Kumar Guduru
   Samsung Electronics
   Samsung RnD Institute India - Bangalore
   Bangalore, Doddanakundi  560037
   India

   Phone: +91-888-4995166
   Email: kiran.guduru@samsung.com














Guduru                  Expires November 17, 2014               [Page 4]


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