Re: [rtcweb] revisiting MTI

Daniel-Constantin Mierla <> Mon, 15 December 2014 22:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 78F451A1F04 for <>; Mon, 15 Dec 2014 14:53:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NzQ0XUSyfSBl for <>; Mon, 15 Dec 2014 14:53:30 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 73C631A1F02 for <>; Mon, 15 Dec 2014 14:53:25 -0800 (PST)
Received: by with SMTP id x12so15791859wgg.38 for <>; Mon, 15 Dec 2014 14:53:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:reply-to:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=cPw/gAvV1ZANR0zR1IeQBPbrbKU5O7Oeqzqjn8q5wvM=; b=F+KqF3HUyoNzRIfTSy5YxuLDbPSJrdP6PnYCLfSxBhctvfDxcIk00RTCxwVsL/iFra 3iV/1L7MqZs/Axx9FIjf24W16Hrytk4HFZbYkIsULmim8v18ryMiU/UWBxO6t9DfxMJO 7JgCgYkoPDtdGeWpZhQDVNssekjC7LK1OFHLLlOa40MxcGB9c5VF7/bOgc9Q/EEwIpR7 Kp2vGzDwdWLrYWIfw5feYGyL9ziyTXtho5RcnREdov71BZND8zauT3bCLMfFEw0QzcNj 791M2imPEx3d4ga6bTpA/zoxgzJLp9k2RaKI6hVRlSqM11F6GZb+n6ZKkmsaucFb7VWi IRUA==
X-Received: by with SMTP id qg9mr35447236wic.29.1418684004297; Mon, 15 Dec 2014 14:53:24 -0800 (PST)
Received: from ([2a01:4f8:a0:638e::2]) by with ESMTPSA id n5sm14887082wic.6.2014. for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Dec 2014 14:53:23 -0800 (PST)
Message-ID: <>
Date: Mon, 15 Dec 2014 23:53:21 +0100
From: Daniel-Constantin Mierla <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Peter Saint-Andre - &yet <>, Ted Hardie <>
References: <> <> <> <> <> <> <> <> <> <> <20141215192409.GN47023@verdi> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Cc: "" <>
Subject: Re: [rtcweb] revisiting MTI
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: Mon, 15 Dec 2014 22:53:32 -0000

On 15/12/14 23:18, Peter Saint-Andre - &yet wrote:
> On 12/15/14, 3:03 PM, Ted Hardie wrote:
>> On Mon, Dec 15, 2014 at 1:37 PM, Peter Saint-Andre - &yet
>> < <>> wrote:
>>     Not as far as I can see.
>>     Ten years ago if we'd had this discussion, H.261 might have been
>>     MTI. Ten years from now, H.264 will seem ancient, too.
>>     I fully expect that someone in the IETF (perhaps not us) will
>>     revisit the MTI decision once we have better alternatives.
>>     Peter
>> ​The nice thing is that our current model allows us to have nice things
>> right away; as soon as they are in common, they may be selected by
>> negotiation.  What the MTI gives us is a way to avoid interoperability
>> failure.  So the key question isn't really "Is there something better?"
>> but "Is the current MTI so bad that folks aren't willing to use it, so
>> we are once again at risk of interoperability failure?".
> Some folks have expressed a concern that whatever we choose as an MTI
> codec now must always be an MTI codec. I'm trying to allay that
> concern by saying that yes, indeed, we can change our MTI codec(s) in
> the future if we please (naturally, keeping interoperability in mind
> at that future time).
Perhaps that concern was created by the phrasing of the current
proposal/draft that MTI is not going to be revisited for browsers.

On the other hand, if this is going to be adopted (not to be
misinterpreted, I don't agree with this proposal), is a quite "ugly"
compromise, probably the most unclean rough consensus so far, nothing
that is backed up with technical merits. I find it more fair to make it
explicit that this was a "last resort" compromise, with a trigger for
revisiting. It will accelerate the process for a RF codec, when having a
clear benefit out of it -- what interest would be to push money on a new
RF codec when you have to implement a paid one anyhow.

Moreover, IETF has an affinity of stating backward compatibility (see
RFC3261/SIP doing that for RFC2543), there will be always enough people
asking for that to get in the same kind of debate like here.


Daniel-Constantin Mierla!/miconda -