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

From: Kiran Kumar Guduru <[email-masked]>
Date: Mon, 21 Jul 2014 04:14:10 +0000 (GMT)

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<[email-masked]>

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 <[email-masked]> 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 <[email-masked]> 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 : [email-masked]<[email-masked]>

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
Status:         https://datatracker.ietf.org/doc/draft-guduru-rtcweb-codec-preferences/
Htmlized:       http://tools.ietf.org/html/draft-guduru-rtcweb-codec-preferences-01
Diff:           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 tools.ietf.org.

The IETF Secretariat

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Mon, 21 Jul 2014 18:56:24 +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