Re: [rtcweb] confirming sense of the room: mti codec

Ross Finlayson <> Fri, 12 December 2014 10:45 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 80F2F1ACCEA for <>; Fri, 12 Dec 2014 02:45:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.79
X-Spam-Level: *
X-Spam-Status: No, score=1.79 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, TVD_FROM_1=0.999, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7BSTQvizSi5T for <>; Fri, 12 Dec 2014 02:45:41 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 459161ACCDC for <>; Fri, 12 Dec 2014 02:45:41 -0800 (PST)
Received: from [] ( []) by (8.14.4/8.14.4) with ESMTP id sBCAjdRZ071100 for <>; Fri, 12 Dec 2014 02:45:40 -0800 (PST) (envelope-from
From: Ross Finlayson <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_C7CB574F-01AB-45A3-8545-3FD63B24676D"
Message-Id: <>
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Date: Fri, 12 Dec 2014 23:45:39 +1300
References: <> <>
In-Reply-To: <>
X-Mailer: Apple Mail (2.1993)
Subject: Re: [rtcweb] confirming sense of the room: mti codec
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Dec 2014 10:45:42 -0000

I also support the rough consensus reached by those of us in the room in Honolulu.

It has been said that “a good compromise is one in which all parties are unhappy”.  By that measure, this is most definitely a good compromise :-)

I think that just about everybody is unhappy about at least some aspect of this compromise.  (For example, as I noted at the microphone in Honolulu, I dislike the fact that making two codecs MTI in browsers for perpetuity - and with the likelihood that at least one of these codecs will be somewhat encumbered for at least the near future - may dampen the possibility of a flourishing ecosystem emerging in the browser space.  But I understand why many others feel that this requirement on browsers is necessary.)

So yes, we’re all a bit unhappy, but I haven’t seen any sign - in any of the recent postings on this mailing list - of an alternative compromise that is likely to gain close to the same degree of consensus.  So, continuing to debate this ad nauseam does nothing but cause further delay (which I'm sure nobody would want :-)

It’s time for us to collectively hold our noses, declare consensus on this issue, and move forward.

Ross Finlayson
Live Networks, Inc.