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

On Mon, Jul 21, 2014 at 12:14 AM, Kiran Kumar Guduru <
kiran.guduru@samsung.com> wrote:

>  Hi Justin,
>
> I don't feel the number of API addition, is a big problem :).
>
You are proposing expanding the API surface of WebRTC 1.0 by over 10%. This
is a significant addition (the current PeerConnection object itself only
has 21 methods), and doesn't count the codec object that would have to be
added to the spec to complete this design.

> 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.
>
I think the examples are contrived, because they don't show how the apps
would use this API to accomplish the desired behavior. Apps certainly don't
know the power characteristics of the various codecs (i.e. whether they are
hardware-backed or not), and only have indirect knowledge of the bandwidth
situation; they don't have all the details on congestion that the browser
has access to, and could end up incorrectly dropping to a low-bandwidth
codec, or oscillating between codecs, because of the lack of detailed
information.

> 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.
>

This is a useful example, thanks for explaining this. But I think this is
the wrong solution. Quoth RFC3264, S. 7:

*   When the offerer receives the answer, it MAY send media on the*
*   accepted stream(s) (assuming it is listed as sendrecv or recvonly in*
*   the answer).  It MUST send using a media format listed in the answer,*
*   and it SHOULD use the first media format listed in the answer when it*
*   does send.*

Note the use of SHOULD vs MUST. Ergo, even if the offer has m=audio 1111
RTP/SAVPF X Y Z, it is completely legal for the callee to apply its own
priorities and send with codec Y or Z instead of X if there are compelling
reasons to do so. This makes more sense to me than doing an immediate
re-offer, or adding APIs to reorder the browser's codec list.

>
>
>
>
> ------- *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
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
>
>