[MMUSIC] The pick-a-config debate - perhaps an useful example

Harald Alvestrand <harald@alvestrand.no> Mon, 27 May 2013 20:49 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id D216D21F8EB1 for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 13:49:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.999
X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_19=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id igMs3pIiIAcE for <mmusic@ietfa.amsl.com>; Mon, 27 May 2013 13:49:18 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no []) by ietfa.amsl.com (Postfix) with ESMTP id A3B2721F8EAF for <mmusic@ietf.org>; Mon, 27 May 2013 13:49:18 -0700 (PDT)
Received: from localhost (localhost []) by eikenes.alvestrand.no (Postfix) with ESMTP id 0C67339E129 for <mmusic@ietf.org>; Mon, 27 May 2013 22:49:15 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([]) by localhost (eikenes.alvestrand.no []) (amavisd-new, port 10024) with ESMTP id a16qllBAqj8L for <mmusic@ietf.org>; Mon, 27 May 2013 22:49:14 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:617e:a2cf:458e:2a0d] (unknown [IPv6:2001:470:de0a:27:617e:a2cf:458e:2a0d]) by eikenes.alvestrand.no (Postfix) with ESMTPSA id DC45539E0D7 for <mmusic@ietf.org>; Mon, 27 May 2013 22:49:13 +0200 (CEST)
Message-ID: <51A3C6C9.6050606@alvestrand.no>
Date: Mon, 27 May 2013 22:49:13 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: mmusic <mmusic@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [MMUSIC] The pick-a-config debate - perhaps an useful example
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, 27 May 2013 20:49:23 -0000

I don't like the name "demux", as I've said before.
Neither do I like the term "select an m-line", because I don't think 
that's the only possible solution to the problem we're facing.

I think the problem we're facing can be illustrated like this: What 
resolution is permitted in the following config? (apologies in advance 
for syntactic brokenness)

a=group:BUNDLE foo bar

a=imageattr:* [x=160,y=100]

a=imageattr:* [x=640,y=480]

Now, the video is the same. The payload type is the same. But the sender 
of this SDP has stated an opinion about the image size that is in the 
form of M-line-related attributes.

Query: Is this the problem we're discussing?

Some solutions that have been suggested:

My interpretation of Plan A: Create two payload types that both mean "vp8".

a=imageattr:* [x=160,y=100]

a=imageattr:* [x=640,y=480]

My interpretation of a pure Plan B: Do SSRC-related signalling.

a=ssrc:4378 imageattr:* [x=160,y=100]
a=ssrc:9736 imageattr:* [x=640,y=480]

(we don't need a second m-line here)

For this particular attribute, there's also a plan with features of both:

a=imageattr:96 [x=160,y=100]
a=imageattr:97 [x=640,y=480]

but this one works only with a=imageattr because imageattr has a payload 

A fourth solution is to decode the first frame, figure out how big it 
is, and see if we have a config it fits into. That sounds bizarre.

A fifth solution is to declare a complete ban on conflicting attributes 
in bundled M-lines. Just Don't Do It.
That reduces the expressive power of M-lines to what I was thinking 
about when I wrote the first bundle proposal: It's a way to describe a 
single RTP session, and what you can't say about a single RTP session, 
you can't say about a bundle describing a single RTP session either.

But that might not be what people want.