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

Kiran Kumar Guduru <kiran.guduru@samsung.com> Mon, 21 July 2014 04:14 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 854D31B2CA1 for <rtcweb@ietfa.amsl.com>; Sun, 20 Jul 2014 21:14:23 -0700 (PDT)
X-Quarantine-ID: <IJnjY7VyIStA>
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 IJnjY7VyIStA for <rtcweb@ietfa.amsl.com>; Sun, 20 Jul 2014 21:14:20 -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 78C381B2A9E for <rtcweb@ietf.org>; Sun, 20 Jul 2014 21:14:20 -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 <0N91006RCNRU4530@mailout3.samsung.com> for rtcweb@ietf.org; Mon, 21 Jul 2014 13:14:18 +0900 (KST)
Received: from epcpsbgx2.samsung.com ( [172.20.52.124]) by epcpsbgr4.samsung.com (EPCPMTA) with SMTP id CA.13.13369.9939CC35; Mon, 21 Jul 2014 13:14:17 +0900 (KST)
X-AuditID: cbfee690-b7fb56d000003439-af-53cc939907ea
Received: from epmailer03 ( [203.254.219.143]) by epcpsbgx2.samsung.com (EPCPMTA) with SMTP id 28.D7.22787.2939CC35; Mon, 21 Jul 2014 13:14:10 +0900 (KST)
Message-id: <38.D7.22787.2939CC35@epcpsbgx2.samsung.com>
Date: Mon, 21 Jul 2014 04:14:10 +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: 20140721034940086@kiran.guduru
Msgkey: 20140721034940086@kiran.guduru
X-EPLocale: en_US.windows-1252
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: 20140721034940086@kiran.guduru
X-ParentMTR:
X-ArchiveUser:
X-CPGSPASS: N
MIME-version: 1.0
Content-type: multipart/related; boundary="=_NamoWEC-fg44f0yf5w"
X-Generator: Namo ActiveSquare 7 7.0.0.45
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMJsWRmVeSWpSXmKPExsWyRsSkRnfm5DPBBl+n21is/dfO7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujJ5nX9kK+r4xVTzcvZ+tgbH/DVMXIyeHkIC6xIbV99hAbAkB E4lTK5+zQ9hiEhfurQeKcwHVLGWUWDFnJlxR16cWVojEHEaJlY3tYB28AhYS2x/MApvKIqAq 8XjJF7A4G1DDrxNrGEFsYYEoiRM3IepFBEIlFiycCjaUWSBConHOGlaIi5Qk1l69yQoxU1Di 5MwnLBCLVSUufFvFDBFXk2ia3skMEZeTWDL1MhOEzSsxo/0pC0x82tc1UDXSEudnbWCE+Wzx 98dQcX6JY7d3APVygPU+uR8MM2b35i9Q/wpITD1zEKpVS+Lkmd9QcT6JNQvfssCM2XVqOTNM 7/0tc5nQnc8s4CRxcdkpqHpNiUeLWlkmMCrPQlKGzoZpgbANJb7Me8wIYStKTOl+yA5h20mc 3DODBVNcVeLKkWvMsxjZwWom52BTMWvxf9YFjNyrGEVTC5ILipPSi0z0ihNzi0vz0vWS83M3 MQJT2Ol/zybsYLx3wPoQ40RGYMxOZJYSTc4HJsG8knhDYzMjC1MTU2Mjc0szWgorifOqPUoK EhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cA4+5xZhs+k0MqvT+xmXOitaH/FwXnyW2fc+dZf pk931qqYhpxzlVtmtZzl5unaZZ+0eWR7LQwv19RXT/mx7xzrwbtxueWmSWVBuj0W3cysZxOn PHzZ33Fb73X/pWcq2/mS3fui+0xe+n6a2HHm/ZpkAbfNBzfX+Nx6JDE5Qb+pZbGHyq+MHD4l luKMREMt5qLiRADhdrYCpgMAAA==
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELsWRmVeSWpSXmKPExsVy+t/tft1Jk88EGzyZIG2x9l87uwOjx5Il P5kCGKPSbDJSE1NSixRS85LzUzLz0m2VvIPjneNNzQwMdQ0tLcyVFPISc1NtlVx8AnTdMnOA pioplCXmlAKFAhKLi5X07WyK8ktLUhUy8otLbJWiDc2N9IwM9EyN9AxNY60MDQyMTIFqEtIy ep59ZSvo+8ZU8XD3frYGxv43TF2MnBxCAuoSG1bfYwOxJQRMJLo+tbBC2GISF+6tB4pzAdXM YZRY2djODpJgEVCVeLzkC5jNBtTw68QaRhBbWCBK4sRNiBoRgVCJBQungg1lFoiQaJyzhhVi mZLE2qs3wWxeAUGJkzOfsEAsU5W48G0VM0RcTaJpeiczRFxOYsnUy0wQNq/EjPanLDDxaV/X QNVIS5yftYER5ujF3x9Dxfkljt3eAdTLAdb75H4wzJjdm79A/SsgMfXMQahWLYmTZ35Dxfkk 1ix8ywIzZtep5cwwvfe3zGVCdz6zgJPExWWnoOo1JR4tamWZwCg7C0kZOhumBcI2lPgy7zEj hK0oMaX7ITuEbSdxcs8MFkxxVYkrR64xz2JkB6uZnINNxazF/1kXMHKvYhRNLUguKE5KrzDS K07MLS7NS9dLzs/dxAhOmM8W7WD8d976EKMAB6MSD+8C5jPBQqyJZcWVuYcYVYDmPNqw+gKj FEtefl6qkgjviQygNG9KYmVValF+fFFpTmrxIcb9jMA0MZFZSjQ5H5jm80riDY1NzE2NTS0M DM3NzQaPsJI4r/ytpCAhgfTEktTs1NSC1CKYF5g4OKUaGC327Hk91eKzdfCZpxLlrx0Kbt7n rfad5RMxuXD6nB3Gnm989c4lXD+7gV9knfHiZ9HLH30K2m+WGL48wGL777s5yus8Mtctn/5g NbNcYanXG7OlJq9KLdjNOAOmV2loXOLYbrv40EU7eXuvsE/vL0+wm+semBNjw8i0VPfYt1l1 f6ZZPvq2S0yJpTgj0VCLuag4EQDyGXW9RQQAAA==
DLP-Filter: Pass
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/udQEPwYnw-MINeniboAtG-PpzxQ
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: Mon, 21 Jul 2014 04:14:23 -0000

Samsung Enterprise Portal mySingle

Hi Justin,

I don't feel the number of API addition, is a big problem :).

I feel this is very useful to add in 1.0. I don't know what made you feel the existing usecases to be contrived. AFAIK, apps has that intellegence to analyze on the bandwidth utilization.

 

One use case I missed in the draft and I would like to add in the next version is, the problem arising at gateways, which can only be solved by apps, but never by browser as explained below.

 

"Considering the usecase off an application is serving the needs between webrtc client and non-webrtc client (IMS for example), that does not support the mandatory codecs specified for WebRTC, then gateways will solve the problem by transcoding.

If a browser is supporting codecs which don't need this kind of transcoding, but giving low priority to them, then according to existing specifications, the gateway has to accept the offer with priorities specified by webrtc (considering the case for webrtc client as offerer) client through answer, then again gateway has to send the offer with its order of priority to change to codec preferences, resulting in a second offer-answer negotiation."  In this kind of usecases API are known about the priority of codecs required and we can avoid this kind of unnecessary signaling if APIs are provided to apps to prioritize the codecs.

 

I hope this example will add some more value to this idea.

 

 

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

Sender : Justin Uberti<juberti@google.com>

Date : Jul 21, 2014 12:30 (GMT+09:00)

Title : Re: 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.

Without a specific, concrete example, I remain unconvinced that this is worth doing in the 1.0 timeframe. Post-1.0, we can probably find a way to provide this sort of lower-level control.


On Sat, Jul 12, 2014 at 9:41 PM, franklin blek <franklin.blek@gmail.com> wrote:
Hi,
The draft seems to explain codec preferences in a good way.
I think this has a good potenitial to be a part of WebRTC1.0.


 
On Sat, Jul 5, 2014 at 10:26 AM, Kiran Kumar Guduru <kiran.guduru@samsung.com> wrote:

Hi,

A new version of codec preferences draft has been published, by modifying as per the review comments received.

Please review and let me know your comments.

 

Thanks & Regards,

Kiran.

 

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

Sender : internet-drafts@ietf.org<internet-drafts@ietf.org>

Date : Jul 02, 2014 18:28 (GMT+09:00)

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

 


A new version of I-D, draft-guduru-rtcweb-codec-preferences-01.txt
has been successfully submitted by Kiran Kumar Guduru and posted to the
IETF repository.

Name: draft-guduru-rtcweb-codec-preferences
Revision: 01
Title: WebRTC Codec Preferences
Document date: 2014-07-02
Group: Individual Submission
Pages: 7
URL:            http://www.ietf.org/internet-drafts/draft-guduru-rtcweb-codec-preferences-01.txt" target="_blank" rel="nofollow">http://www.ietf.org/internet-drafts/draft-guduru-rtcweb-codec-preferences-01.txt
Status:         https://datatracker.ietf.org/doc/draft-guduru-rtcweb-codec-preferences/" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/draft-guduru-rtcweb-codec-preferences/
Htmlized:       http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01" target="_blank" rel="nofollow">http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01
Diff:           http://www.ietf.org/rfcdiff?url2=draft-guduru-rtcweb-codec-preferences-01" target="_blank" rel="nofollow">http://www.ietf.org/rfcdiff?url2=draft-guduru-rtcweb-codec-preferences-01

Abstract:
   WebRTC specifies to implement a minimum set of required codecs to
   ensure guaranteed interoperability between WebRTC peers.  WebRTC
   allows browser implementers to support vendor specific codecs apart
   from mandatory codecs.  This document specifies the way for
   JavaScript applications to give preferences for media codecs in
   WebRTC context out of the available codecs in browser for creating
   the offer / answer.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at http://tools.ietf.org/" target="_blank" rel="nofollow">tools.ietf.org.

The IETF Secretariat

 

 

http://ext.samsung.net/mailcheck/SeenTimeChecker?do=5b0f67af9090da35275855522705c978a6eec23bffd6f82352ccaaa5e78d7917de6eee2be874e0523ecd3146ba1edb3ef4bcdeced46ed5ee08cece8541bc14eacf878f9a26ce15a0" width="0" height="0">