Re: [MMUSIC] Wisdom sought: Prioritization of codecs

Adam Roach <adam@nostrum.com> Thu, 15 November 2012 19:55 UTC

Return-Path: <adam@nostrum.com>
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 A906821F8522 for <mmusic@ietfa.amsl.com>; Thu, 15 Nov 2012 11:55:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.304
X-Spam-Level:
X-Spam-Status: No, score=-102.304 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, SPF_PASS=-0.001, 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 zJscDpV1TeqA for <mmusic@ietfa.amsl.com>; Thu, 15 Nov 2012 11:55:14 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9290E21F8421 for <mmusic@ietf.org>; Thu, 15 Nov 2012 11:55:14 -0800 (PST)
Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAFJt1GH089083 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 15 Nov 2012 13:55:02 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <50A54895.7030006@nostrum.com>
Date: Thu, 15 Nov 2012 13:55:01 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
References: <50A4AC20.5030306@alvestrand.no> <50A4AE7F.4040403@alvestrand.no> <50A51F04.5090502@alum.mit.edu>
In-Reply-To: <50A51F04.5090502@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
Cc: mmusic@ietf.org
Subject: Re: [MMUSIC] 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: Thu, 15 Nov 2012 19:55:15 -0000

On 11/15/12 10:57, Paul Kyzivat wrote:
> The whole notion of codec preference breaks down even more for 
> multiplexed streams. You may very explicitly prefer/require different 
> streams to use different codecs.
>
> So I don't think we can rely too much on parsing the existing text for 
> guidance on how to use SDP to represent multiplexed sessions. (Unless 
> of course we use bundle, with a separate m-line for each stream.) 
> AFAIK we are breaking new ground here.

This kind of "we fixed this problem once and get to fix it all over 
again" issue is exactly the kind of thing I was speaking to at the 
microphone in MMUSIC in Atlanta. The further we drift from the 
established semantics of SDP, the less applicable previously developed 
mechanisms become. Bundle and similar approaches that maintain one m= 
line per stream allow us to leverage 14 years of extensions and 
clarifications. If we decide to split from that (rather fundamental, 
IMHO) characteristic of SDP, we are effectively forking the protocol, 
and throwing away years of prior work.

/a