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

Cullen Jennings <fluffy@iii.ca> Wed, 05 June 2013 00:01 UTC

Return-Path: <fluffy@iii.ca>
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 8390B21F9A21 for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 17:01:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.48
X-Spam-Level:
X-Spam-Status: No, score=-0.48 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, J_CHICKENPOX_15=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O9--gUOkz4AI for <mmusic@ietfa.amsl.com>; Tue, 4 Jun 2013 17:01:47 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9632021F9A1F for <mmusic@ietf.org>; Tue, 4 Jun 2013 17:01:47 -0700 (PDT)
Received: from [10.70.232.182] (unknown [64.104.46.217]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 841A922E200; Tue, 4 Jun 2013 20:01:38 -0400 (EDT)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <51A859D4.7030201@alvestrand.no>
Date: Mon, 03 Jun 2013 16:49:36 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <5FC23AD9-69DA-45E2-8F54-646CEB578115@iii.ca>
References: <51A3C6C9.6050606@alvestrand.no> <C5E08FE080ACFD4DAE31E4BDBF944EB11352451A@xmb-aln-x02.cisco.com> <51A859D4.7030201@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
X-Mailer: Apple Mail (2.1503)
Cc: mmusic <mmusic@ietf.org>
Subject: Re: [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: Wed, 05 Jun 2013 00:01:53 -0000

On May 31, 2013, at 2:05 AM, Harald Alvestrand <harald@alvestrand.no> wrote:

> On 05/30/2013 07:47 PM, Cullen Jennings (fluffy) wrote:
>> On May 27, 2013, at 2:49 PM, Harald Alvestrand <harald@alvestrand.no> wrote:
>> 
>>> a=group:BUNDLE foo bar
>>> 
>>> m=video
>>> a=mid:foo
>>> a=imageattr:* [x=160,y=100]
>>> a=rtpmap:96:vp8
>>> 
>>> m=video
>>> a=mid:bar
>>> a=imageattr:* [x=640,y=480]
>>> a=rtpmap:96:vp8
>>> 
>>> Now, the video is the same.
>> Small nit … as far as I am concerned, if the above is a 3264 based offer, the video could be from two different cameras. You need some other signaling to indicate it is simulcast.
>> 
> I did not intend it to say whether it was simulcast or not - I wasn't thinking of simulcast when I wrote it, just about "one of the parties says he wants two different, incompatible resolutions". "The video is the same" was badly formulated; I meant "The video codec is the same".

Ah - make sense. Thanks.