Re: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs)

Harald Alvestrand <harald@alvestrand.no> Mon, 19 November 2012 16:50 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2988021F84EB for <mmusic@ietfa.amsl.com>; Mon, 19 Nov 2012 08:50:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nNcA4AavWyXl for <mmusic@ietfa.amsl.com>; Mon, 19 Nov 2012 08:50:47 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 747F821F855E for <mmusic@ietf.org>; Mon, 19 Nov 2012 08:50:46 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1F3C739E197; Mon, 19 Nov 2012 17:50:45 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixFhbJZceTmM; Mon, 19 Nov 2012 17:50:44 +0100 (CET)
Received: from [172.16.33.61] (unknown [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id 7018639E04C; Mon, 19 Nov 2012 17:50:44 +0100 (CET)
Message-ID: <50AA6363.7040201@alvestrand.no>
Date: Mon, 19 Nov 2012 17:50:43 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: Adam Roach <adam@nostrum.com>
References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu> <50A54895.7030006@nostrum.com> <50A9BFD4.3000601@alvestrand.no> <50AA527C.6060200@nostrum.com> <50AA588B.9090805@alvestrand.no> <50AA5D55.6080006@nostrum.com>
In-Reply-To: <50AA5D55.6080006@nostrum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] M-line philosophy (Re: Wisdom sought: Prioritization of codecs)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2012 16:50:49 -0000

On 11/19/2012 05:24 PM, Adam Roach wrote:
> On 11/19/12 10:04, Harald Alvestrand wrote:
>> On 11/19/2012 04:38 PM, Adam Roach wrote:
>>>
>>>
>>> There are, at the moment, 176 attributes in the IANA registry that 
>>> are applicable to m= sections:
>>> ...
>>> Some of these are applicable to the RTP session; others only make 
>>> sense as applied to a single media stream.
>> And some make absolutely no sense at all in the RTCWEB context.
>
> Perhaps not for RTCWEB, but I'm fairly certain that we'd like to see 
> the same solutions applies to CLUE as RTCWEB. I concede that some of 
> these are applicable only to technologies that are dead or dying; 
> however...
>
>> I have at one point in my life dealt with T-series fax
>
> ...T.38 fax isn't one of them. Sadly.
What's your scenario where T.38 fax over RTP is relevant when file 
transfer over a reliable channel is available between the same 2 devices?
>
> It sure would be nice to discount all of the existing mechanisms, but 
> I suspect that they're not as wholly worthless are you're implying. 
> Perhaps when I have a bit more time, I'll sit down and do a 
> mechanism-by-mechanism evaluation of applicability of each to RTCWEB 
> and CLUE. Until then, I expect it's relatively safe to assume that 
> people haven't been putting values into that registry by performing 
> utterly meaningless work; and, further, that only a fraction of it has 
> been overtaken by technological progress.
90% is also a fraction. But I agree it's unlikely to be that high.

>
> /a