Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt

"Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com> Mon, 21 July 2014 18:56 UTC

Return-Path: <Raju.Makaraju@alcatel-lucent.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BA41A032A for <rtcweb@ietfa.amsl.com>; Mon, 21 Jul 2014 11:56:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIk3mQkl6iDb for <rtcweb@ietfa.amsl.com>; Mon, 21 Jul 2014 11:56:39 -0700 (PDT)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37A11A026F for <rtcweb@ietf.org>; Mon, 21 Jul 2014 11:56:30 -0700 (PDT)
Received: from us70uusmtp3.zam.alcatel-lucent.com (h135-5-2-65.lucent.com [135.5.2.65]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s6LIuQ8h012426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Jul 2014 13:56:27 -0500 (CDT)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s6LIuPpg025187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 21 Jul 2014 14:56:25 -0400
Received: from US70UWXCHMBA02.zam.alcatel-lucent.com ([169.254.8.175]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 21 Jul 2014 14:56:25 -0400
From: "Makaraju, Maridi Raju (Raju)" <Raju.Makaraju@alcatel-lucent.com>
To: "kiran.guduru@samsung.com" <kiran.guduru@samsung.com>, Justin Uberti <juberti@google.com>, franklin blek <franklin.blek@gmail.com>
Thread-Topic: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt
Thread-Index: AQHPpJo4FyolNSJL+EudWqaZ2lX2RpuqcssA
Date: Mon, 21 Jul 2014 18:56:24 +0000
Message-ID: <E1FE4C082A89A246A11D7F32A95A17828E48C2E7@US70UWXCHMBA02.zam.alcatel-lucent.com>
References: <38.D7.22787.2939CC35@epcpsbgx2.samsung.com>
In-Reply-To: <38.D7.22787.2939CC35@epcpsbgx2.samsung.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.17]
Content-Type: multipart/alternative; boundary="_000_E1FE4C082A89A246A11D7F32A95A17828E48C2E7US70UWXCHMBA02z_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/nDlnYU3kAZ7I-sJsD5vbWJM1vos
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Subject: Re: [rtcweb] New Version Notification for draft-guduru-rtcweb-codec-preferences-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jul 2014 18:56:42 -0000

>This seems like a pretty big hammer to solve a fairly small problem. This proposal adds 6 new API points for the purpose of >changing the order of codecs in createOffer, which seems like a high cost-benefit ratio. And while the use cases listed here are >helpful, they seem somewhat contrived to me, since it seems unlikely that the application can make better choices about >bandwidth >or power consumption than the browser.



[Raju] Per my understanding, the main object of this draft can be achieved with no additional APIs and with just the proposed introduction of preferredAudioCodecs and preferredVideoCodecs options to RTCOfferAnswerOptions constraint of createOffer()/createAnswer().

So, IMO I don't think getCodecPreferences()/setCodecPreferences() add much value, so can be delayed or dropped.



The need for getSupportedAudioCodecs()/getSupportedVideoCodecs() in 1.0 can be questionable as the application can specify codecs order per known codecs (or get the list via a dummy createOffer() call).



The draft talks about fulfilling A5 in [I-D.ietf-rtcweb-use-cases-and-requirements], but I do not see any explicit mention of how codecs can be removed? preferredAudio/VideoCodecs constraint only specifies the order of preference. Don't you need another constraint to exclude specified codecs? It's probably a bad design to have codecs not in the preferred list be removed automatically.



BR

Raju