Re: [AVTCORE] [MMUSIC] BUNDLE: a single stream with multiple MIDs?

Iñaki Baz Castillo <ibc@aliax.net> Wed, 13 July 2016 08:55 UTC

Return-Path: <ibc@aliax.net>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C520A12B00A for <avt@ietfa.amsl.com>; Wed, 13 Jul 2016 01:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level:
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aliax-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9Pc2WdBc0S7 for <avt@ietfa.amsl.com>; Wed, 13 Jul 2016 01:55:15 -0700 (PDT)
Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com [209.85.161.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B0412D675 for <avt@ietf.org>; Wed, 13 Jul 2016 01:55:15 -0700 (PDT)
Received: by mail-yw0-f181.google.com with SMTP id l125so37159507ywb.2 for <avt@ietf.org>; Wed, 13 Jul 2016 01:55:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aliax-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+t45jW5fzH3QGGggCvqOCmPLSRtesRC3T/OY29kSU9Q=; b=BU7n7qtOGJFq9Srw6MJWfWg3Xj74UuD+wXqf8GNSDnCRhjLHXjfRt7UHTTbemjKxYM NAxhX7FnwAyYBsKT5clwqp0EZ9LoFVJOdD25cnAh5S8yDGXYeZujRLncd3fiZlfI3kgv 3Q/wfJF7af0KCab93dGDEVv6lDE0g7K/lUTu/NK+HklhOWUQa3T4TTwMSPEryCuodztl JnZ9HfSesos6CHLGR1g1VLRPyl/QMxbdgbPJOKSOHWxLCNG0pr9f2OIpFB9Wzqo/8K8K KDvIHxUhdKbTvX8s5WLfFuXtFn/W+nktJ6YcWBt37rCi5Xz94GOJ2nNr1+KmbUbaDTZq 1fJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+t45jW5fzH3QGGggCvqOCmPLSRtesRC3T/OY29kSU9Q=; b=jcYIWmrc/RyGzaN+e3A1q4B8xWJiqzwWPMvizrGP2BJxWhqZ6+7OYnky9xNoh8jXCy k0blZXaVSc9H7DuqsF8q4rcmuOxK/gh7F6AOyqvSQlUnQ4LYnui7B3hZRDAi//d34ijy xb1XpAP+WTnGsv1xMs4nYchncdWfbL67EKoCe/WZjM7Y4CikslAZvZktA3h2hdhkatxc eeEnnACfB3ghiznKfELG3UL8LSQrTBI7HQ1thY8a1F5KZj61z9S21ZQ+Z57ohdtSmYg9 aUkRUwbq3e4MirpHpwZGrDGTCrLzNVffblpVc3Ui7Sec48yPozN7BXCs5FPVjaGAFfK3 g5Yw==
X-Gm-Message-State: ALyK8tJ+JtHvEz4Pxv5Ksa3MN+tffJtJKOQB+Vxku0AIAw5S5dxgGuBP04BUIw60b6GBGfyfUEqydwYhtLtZ9A==
X-Received: by 10.13.234.211 with SMTP id t202mr4629622ywe.262.1468400054785; Wed, 13 Jul 2016 01:54:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.37.33.213 with HTTP; Wed, 13 Jul 2016 01:53:55 -0700 (PDT)
In-Reply-To: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com>
References: <6C642BD1-679B-4CCA-9148-DD4A7ACB48A4@vidyo.com>
From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Wed, 13 Jul 2016 10:53:55 +0200
Message-ID: <CALiegf=JJTPma0hZPtDk7=Qg0S5+LMQDjZv7xfz=BYqQw2=M=g@mail.gmail.com>
To: Jonathan Lennox <jonathan@vidyo.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/ytht1r_5Js04vq3GHRm0s-K3Vzo>
Cc: IETF AVTCore WG <avt@ietf.org>, mmusic <mmusic@ietf.org>
Subject: Re: [AVTCORE] [MMUSIC] BUNDLE: a single stream with multiple MIDs?
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jul 2016 08:55:19 -0000

2016-07-08 0:36 GMT+02:00 Jonathan Lennox <jonathan@vidyo.com>:
> The use case is where one m-line has a semantic of “always view this person” (my boss, say, or my customer); and another m-line has a semantic of “the current loudest speaker”.

Why is another m-line required for the "current loudest speaker" at all?

Who the current speaker is can be known by means of RTP header
extensions in client side. It can be also signaled by the server in
any custom way (out of the scope of SDP). Any of those mechanisms is
better than having yet another artificial m-line for that purpose.

I don't know CLUE, but assuming it pursuits similar aim than BUNDLE, I
think we should keep to a more declarative SDP syntax in which each
m-line represents a specific "media stream track" from a single
participant in the session, identified by a fixed MID (plus RID if the
sender switches to another media encoding).

If we can not even guarantee that, then SDP becomes extremely hard to
understand.


-- 
Iñaki Baz Castillo
<ibc@aliax.net>