Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs)

[Roman Shpount <[e-mail]>]

I know that I would sound like I am repeating myself, but my initial
argument was that in order to interoperate with majority of legacy HD Audio
deployments without transcoding WebRTC implementations SHOULD support
G.722. The main argument that I heard against this was that
interoperability with legacy is not a justification enough for a SHOULD.
Other arguments, such as that OPUS is better sounding and more resilient to
packet loss then G.722 are irrelevant since it was never argued this way.
The fact that the list of supported codecs in 5-10 years will change
drastically is also not very relevant, since the specification can be
updated to reflect this in the future. So the only thing that we have to
discuss here is if interop deserves a SHOULD or should we just assume that
implementers will do the right thing. To be honest all I've heard so far
(and unfortunately I realize that this applies to some degree to my own
argument) was that people feel one way or the other, which is not very
helpful in reaching consensus.
_____________
Roman Shpount


On Mon, Jan 14, 2013 at 10:00 AM, Adam Roach <[e-mail]> wrote:

> This thread has been going on for quite some time now, and I wouldn't be
> surprised if there is some pressure for the chairs to call consensus in the
> next week or two.
>
> I know it's tempting to think they might simply grab the relevant messages
> and tally the support for each position, calling the issue for those with
> the larger number of proponents. In short, simple majority voting. Many
> bodies work this way -- governments, corporations, and other SDOs, just to
> name a few.
>
> We don't.
>
> As Dave Crocker[1] is fond of pointing out, it is possible to have 99
> people in support of a position and one standing against, and still fail to
> meet the IETF's standard for "rough consensus." All it takes is the failure
> of those 99 people to engage the arguments put forth by the one outlier.
> Correspondingly, you can have 50 people on one side of an issue, 50 on the
> other, and still have a clear consensus if one side is merely stating a
> position, while the other is offering up unanswered arguments.
>
> To be clear, I'm not saying that "+1" is never a valid response when
> attempting to reach consensus. However, it does not, in and of itself,
> comprise a counter-argument to points raised by supporters of the opposing
> position.
>
> To the issue at hand: roughly grouping those proponents of option 1 into
> one voice (A), and those boosting option 2 in to another (B), the
> conversation so far can be roughly summarized as:
>
> A: We'd like to see SHOULD-level support for codecs x, y, and/or z because
> gee, wouldn't it be nice?
> B: "Wouldn't it be nice" doesn't meet the criteria for RFC 2119 SHOULD.
> A: *crickets*
>
> [time passes]
>
> A: We'd like to see SHOULD-level support for codecs x, y, and/or z because
> gee, wouldn't it be nice?
> B: "Wouldn't it be nice" doesn't meet the criteria for RFC 2119 SHOULD.
> A: *crickets*
>
> That's the _exact_ kind of failure to engage that I would expect would
> cause experienced chairs to call clear consensus for supporters of option 2.
>
> This isn't a vote, it's a discussion, and discussions need to go beyond
> blindly repeating your opening arguments. If you have any interest in
> option 1 being considered further, you need to listen and respond to the
> opposing position.
>
> /a
>
>
> [1] For those of you unfamiliar with Dave Crocker's tenure in the IETF, I
> call your attention to the date and attendee list on the following
> proceedings: http://www.ietf.org/**proceedings/04.pdf<http://www.ietf.org/proceedings/04.pdf>
>
>
> On 1/14/13 02:21, [e-mail] wrote:
>
>> I also support Stephane's proposal.
>>
>>
>>  -----Ursprüngliche Nachricht-----
>>> Von: [e-mail] [mailto:rtcweb-bounces@ietf.**org<[e-mail]>
>>> ]
>>> Im Auftrag von Shida Schubert
>>> Gesendet: Sonntag, 13. Januar 2013 22:35
>>> An: Paul Coverdale
>>> Cc: [e-mail]
>>> Betreff: Re: [rtcweb] Call for Consensus Regarding Selecting
>>> Recommended Audio Codecs
>>>
>>>
>>> +1
>>>
>>> On Jan 11, 2013, at 5:56 AM, Paul Coverdale wrote:
>>>
>>>  I support Stephane's proposal for option 1. It makes good sense,
>>>> particularly for the case where AMR and AMR-WB are already
>>>>
>>> implemented
>>>
>>>> in mobile devices - there are no additional licensing issues and it
>>>> simplifies interoperability.
>>>>
>>>> ...Paul
>>>>
>>>>  -----Original Message-----
>>>>> From: [e-mail] [mailto:rtcweb-bounces@ietf.**org<[e-mail]>]
>>>>> On
>>>>> Behalf Of [e-mail]
>>>>> Sent: Friday, January 11, 2013 7:33 AM
>>>>> To: Magnus Westerlund; [e-mail]
>>>>> Subject: Re: [rtcweb] Call for Consensus Regarding Selecting
>>>>> Recommended Audio Codecs
>>>>>
>>>>> It is clear from the discussions on the rtcweb e-mail
>>>>>
>>>> reflector that
>>>
>>>> the only additional codecs to be considered are limited to the
>>>>> following very small subset of 3 codecs: AMR, AMR-WB and G.722.
>>>>> In addition to G.711, these 3 codecs cover almost all
>>>>>
>>>> legacy devices
>>>
>>>> dedicated to voice services. They are consequently needed and
>>>>> sufficient to be supported by WebRTC to make it an attractive and
>>>>> future proof technology for usage in all environments including
>>>>> mobile and for interoperability use cases with most of all
>>>>>
>>>> legacy voice terminals.
>>>
>>>> AMR and AMR-WB are indeed the most widely supported voice
>>>>>
>>>> codecs in
>>>
>>>> hundreds of millions of legacy mobile devices.
>>>>> G.722 is royalty free (including a Packet Loss Concealment
>>>>>
>>>> solution
>>>
>>>> provided in ITU-T Software Tool Library) and is the codec
>>>>>
>>>> used for HD
>>>
>>>> Voice / DECT-Cat IQ fixed devices
>>>>>
>>>>> Furthermore, considering that the reason for excluding AMR
>>>>>
>>>> and AMR-WB
>>>
>>>> from WebRTC was the licensing issue, there is no reason to NOT
>>>>> support AMR-WB and AMR at WebRTC level if these codecs are already
>>>>> implemented on the device.
>>>>>
>>>>> Therefore I support option 1 and propose the following
>>>>>
>>>> specification
>>>
>>>> according this:
>>>>> AMR-WB, AMR and G.722 are RECOMMENDED TO IMPLEMENT by WebRTC
>>>>> end-points AMR and AMR-WB MUST BE supported at WebRTC
>>>>>
>>>> level by WebRTC
>>>
>>>> end-points on 3GPP mobile devices already implementing AMR
>>>>>
>>>> and AMR-WB
>>>
>>>> (*)
>>>>>
>>>>> (*) note that the way these codecs are supported at RTC
>>>>>
>>>> Web level is
>>>
>>>> left open to implementors: either by a WebRTC specific software
>>>>> implementation of these codecs or by using APIs to access hardward
>>>>> implementation.
>>>>>
>>>>>
>>>>> -----Message d'origine-----
>>>>> De : [e-mail]
>>>>>
>>>> [mailto:rtcweb-bounces@ietf.**org <[e-mail]>] De la
>>>
>>>> part de Magnus Westerlund Envoyé : jeudi 20 décembre 2012 09:30 À :
>>>>> [e-mail] Objet : [rtcweb] Call for Consensus Regarding
>>>>> Selecting Recommended Audio Codecs
>>>>>
>>>>> WG,
>>>>>
>>>>> As an outcome of the Vancouver IETF meeting codec
>>>>>
>>>> discussions we did
>>>
>>>> promise to run a call for consensus regarding if the WG was
>>>>> interested in specifying a small set of recommended audio
>>>>>
>>>> codecs. We
>>>
>>>> are sorry this has been delayed until now.
>>>>>
>>>>> The question for the call of consensus is between two options.
>>>>>
>>>>> 1) Run a process in the WG to select and specify a small set of
>>>>> audio/speech codecs that would be RECOMMNEDED to implement by a
>>>>> WebRTC end-points
>>>>>
>>>>> 2) Do nothing and let the already specified Mandatory to Implement
>>>>> Audio codecs be the only audio codecs mentioned in the
>>>>>
>>>> WebRTC specification.
>>>
>>>> Please indicate your position by January 16th 2013.
>>>>>
>>>>> Regards
>>>>>
>>>>> Magnus Westerlund
>>>>>
>>>>>
>>>>>  ------------------------------**------------------------------**
>>> ---------
>>>
>>>> - Multimedia Technologies, Ericsson Research EAB/TVM
>>>>>
>>>>>  ------------------------------**------------------------------**
>>> ----------
>>>
>>>> Ericsson AB                | Phone  [phone]
>>>>> Färögatan 6                | Mobile [phone]
>>>>> SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>>>>>
>>>>>  ------------------------------**------------------------------**
>>> ---------
>>>
>>>> -
>>>>>
>>>>> ______________________________**_________________
>>>>> rtcweb mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>>>>
>>>>>
>>>>>  ______________________________**______________________________**
>>> _________
>>>
>>>> ___ ______________________________**___________________
>>>>>
>>>>> Ce message et ses pieces jointes peuvent contenir des informations
>>>>> confidentielles ou privilegiees et ne doivent donc pas
>>>>>
>>>> etre diffuses,
>>>
>>>> exploites ou copies sans autorisation. Si vous avez recu
>>>>>
>>>> ce message
>>>
>>>> par erreur, veuillez le signaler a l'expediteur et le
>>>>>
>>>> detruire ainsi
>>>
>>>> que les pieces jointes. Les messages electroniques etant
>>>>>
>>>> susceptibles
>>>
>>>> d'alteration, France Telecom - Orange decline toute
>>>>>
>>>> responsabilite si
>>>
>>>> ce message a ete altere, deforme ou falsifie. Merci.
>>>>>
>>>>> This message and its attachments may contain confidential or
>>>>> privileged information that may be protected by law; they
>>>>>
>>>> should not
>>>
>>>> be distributed, used or copied without authorisation.
>>>>> If you have received this email in error, please notify the sender
>>>>> and delete this message and its attachments.
>>>>> As emails may be altered, France Telecom - Orange is not
>>>>>
>>>> liable for
>>>
>>>> messages that have been modified, changed or falsified.
>>>>> Thank you.
>>>>>
>>>>> ______________________________**_________________
>>>>> rtcweb mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>>>>
>>>> ______________________________**_________________
>>>> rtcweb mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>>>
>>> ______________________________**_________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>>
>>>  ______________________________**_________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>>
>
> ______________________________**_________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>