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

Kiran Kumar Guduru <kiran.guduru@samsung.com> Tue, 22 July 2014 03:19 UTC

Return-Path: <kiran.guduru@samsung.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 B16871A03A7 for <rtcweb@ietfa.amsl.com>; Mon, 21 Jul 2014 20:19:40 -0700 (PDT)
X-Quarantine-ID: <rEwuTQTvr2Zh>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Spam-Flag: NO
X-Spam-Score: -5.184
X-Spam-Level:
X-Spam-Status: No, score=-5.184 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_HI=-5, RELAY_IS_203=0.994, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001] 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 rEwuTQTvr2Zh for <rtcweb@ietfa.amsl.com>; Mon, 21 Jul 2014 20:19:38 -0700 (PDT)
Received: from mailout3.samsung.com (mailout3.samsung.com [203.254.224.33]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80B2A1A0393 for <rtcweb@ietf.org>; Mon, 21 Jul 2014 20:19:37 -0700 (PDT)
Received: from epcpsbgr4.samsung.com (u144.gpu120.samsung.co.kr [203.254.230.144]) by mailout3.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0N9300CTOFWN3R00@mailout3.samsung.com> for rtcweb@ietf.org; Tue, 22 Jul 2014 12:19:35 +0900 (KST)
Received: from epcpsbgx1.samsung.com ( [172.20.52.122]) by epcpsbgr4.samsung.com (EPCPMTA) with SMTP id 54.7B.13369.748DDC35; Tue, 22 Jul 2014 12:19:35 +0900 (KST)
X-AuditID: cbfee690-b7fb56d000003439-55-53cdd847ad1e
Received: from epmailer02 ( [203.254.219.142]) by epcpsbgx1.samsung.com (EPCPMTA) with SMTP id 79.F9.03708.748DDC35; Tue, 22 Jul 2014 12:19:35 +0900 (KST)
Message-id: <89.F9.03708.748DDC35@epcpsbgx1.samsung.com>
Date: Tue, 22 Jul 2014 03:19:35 +0000
From: Kiran Kumar Guduru <kiran.guduru@samsung.com>
To: Justin Uberti <juberti@google.com>, franklin blek <franklin.blek@gmail.com>
MIME-version: 1.0
X-MTR: 20140722031815591@kiran.guduru
Msgkey: 20140722031815591@kiran.guduru
X-EPLocale: en_US.utf-8
X-Priority: 3
X-EPWebmail-Msg-Type: personal
X-EPWebmail-Reply-Demand: 0
X-EPApproval-Locale:
X-EPHeader: ML
X-EPTrCode:
X-EPTrName:
X-MLAttribute:
X-RootMTR: 20140722031815591@kiran.guduru
X-ParentMTR:
X-ArchiveUser:
X-CPGSPASS: N
MIME-version: 1.0
Content-type: multipart/related; boundary="=_NamoWEC-pmbgr7ernt"
X-Generator: Namo ActiveSquare 7 7.0.0.45
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOKsWRmVeSWpSXmKPExsWyRsSkStf9xtlggwXNJhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9n8tawFNy8yVryctJutgbHlDGMXIyeHkIC6xIbV99hAbAkB E4l/p/ZD2WISF+6tB7K5gGqWMkr0rWtkgSk613YfKjGHUWLlqmVMIAleAQuJ+X82sILYLAKq Eq0zv4DF2YAafp1YA7ZNWCBZ4vuHyWBxEYFQiQULp4JtYxaIkLh/7gkLxEVKEmuv3mSFmCko cXLmE6jFqhInPlxhgYirSaw93QZ1qbjE34ZH7BA2r8SM9qdQ9XIS076uYYawpSXOz9rACPPZ 4u+PoeL8Esdu7wC6hwOs98n9YJgxuzd/gRovIDH1zEGoVi2JPU9aoGw+iTUL37LAjNl1ajkz TO/9LXOZ0J3PLOAk0TPpF9RMTYlHi1pZJjAqz0JShs6GaZkFdB0z0OrFszwhwooSU7ofskPY dhL/n+9mQRUHKVeVWNSkuICRYxWjaGpBckFxUnqRiV5xYm5xaV66XnJ+7iZGYOo5/e/ZhB2M 9w5YH2KsAkbaRGYp0eR8YOrKK4k3NDYzsjA1MTU2Mrc0o4qwkjiv2qOkICGB9MSS1OzU1ILU ovii0pzU4kOMTBycUg2M+veaniadlfbhT/m4b9NjptUfzopf5Iq92rpAO/7UHd7G78xnKnh+ XSrgy4uzvfomIW3ulxe9M3eWBh5/W+1UEREoa3ol3ypiV19fvOl9Xgnb/VySVtu0rkRc0Ui+ vTBm9effzvEmEwz2ZE4odjl/7f4ejTjtuCydr2wsEY/Db/rkZNoXdwgpsRRnJBpqMRcVJwIA Rb0BDmoDAAA=
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrAJsWRmVeSWpSXmKPExsVy+t/tPl33G2eDDfrbNS3W/mtnd2D0WLLk J1MAY1SaTUZqYkpqkUJqXnJ+SmZeuq2Sd3C8c7ypmYGhrqGlhbmSQl5ibqqtkotPgK5bZg7Q VCWFssScUqBQQGJxsZK+nU1RfmlJqkJGfnGJrVK0obmRnpGBnqmRnqFprJWhgYGRKVBNQlrG svlrWQtuXmSseDlpN1sDY8sZxi5GTg4hAXWJDavvsYHYEgImEufa7kPZYhIX7q0HsrmAauYw SqxctYwJJMEioCrROvMLmM0G1PDrxBqwQcICyRLfP0wGi4sIhEosWDgVbBCzQITE/XNPWCCW KUmsvXqTFcTmFRCUODkTIi4BNPPEhyssEHE1ibWn26COEJf42/CIHcLmlZjR/hSqXk5i2tc1 zBC2tMT5WRsYYY5e/P0xVJxf4tjtHUD3cID1PrkfDDNm9+YvUOMFJKaeOQjVqiWx50kLlM0n sWbhWxaYMbtOLWeG6b2/ZS4TuvOZBZwkeib9gpqpKfFoUSvLBEbZWUjK0NkwLbOArmMGWr14 lidEWFFiSvdDdgjbTuL/890sqOIg5aoSi5oUFzByrGIUTS1ILihOSq8w1CtOzC0uzUvXS87P 3cQITnTPFu5g/HLe+hCjAAejEg+vhfzZYCHWxLLiytxDjCpAYx5tWH2BUYolLz8vVUmEt30P UJo3JbGyKrUoP76oNCe1+BDjREZgfE9klhJNzgem57ySeENjE3NTY1MLA0NzczNaCiuJ8969 mRQkJJCeWJKanZpakFoEcxQTB6dUA6OCv+WcFysdNdM813yvv6HW0z/N+KKMrIvu+0WrPX4r bfsbLyPleL1CeYXRvQUL5kQKb1BWu7FnSqOGfoHF+T0VJ+3TCh88PyWZ+r88gmebv13er8iz rc/clXXF9VQuvs5lSzZP93Lawb0nITU//+T0E0umMnr+OtZlt6Ll652jT67aeR7rj1diKc5I NNRiLipOBACOxFDT8wMAAA==
DLP-Filter: Pass
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/XfIAA_MFnW5hqIq3leKLEcJg_XE
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
Reply-To: kiran.guduru@samsung.com
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: Tue, 22 Jul 2014 03:19:40 -0000

Samsung Enterprise Portal mySingle

Dear Raju,

Thanks for your comments.

Please see my comments inline.

 

------- Original Message -------

Sender : Makaraju, Maridi Raju (Raju)<Raju.Makaraju@alcatel-lucent.com>

Date : Jul 22, 2014 03:56 (GMT+09:00)

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

 

>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). 
  [KIRAN] New API is added for this only because, it can be called on Peerconnection irrespective of its state and the order of parsing is also easy when compared to parsing of whole SDP returned through createOffer/Answer.
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.
 
 [KIRAN] The removal of codecs is explained in section 6. 
  "The offer / answer
   SHOULD NOT contain audio codecs other than those specified by
   JavaScript application and the order of preference SHOULD be with
   high priority for the codecs first in the sequence."
 
Perhaps this is in indirect way. I will modify the statement to directly point this. I don't want to increase the constraints just for removal, which can be achieved with this constraint. So I followed this design.
BR
Raju