[MMUSIC] Some more thoughts on the simulcast discussion

Harald Alvestrand <harald@alvestrand.no> Wed, 14 October 2015 07:10 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA741A90B3 for <mmusic@ietfa.amsl.com>; Wed, 14 Oct 2015 00:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Level:
X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 kculBiRcbcYh for <mmusic@ietfa.amsl.com>; Wed, 14 Oct 2015 00:10:46 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) by ietfa.amsl.com (Postfix) with ESMTP id 326071A1B9E for <mmusic@ietf.org>; Wed, 14 Oct 2015 00:10:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 3E56A7C035E for <mmusic@ietf.org>; Wed, 14 Oct 2015 09:10:45 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPDumuMrlWuP for <mmusic@ietf.org>; Wed, 14 Oct 2015 09:10:44 +0200 (CEST)
Received: from hta-hippo.lul.corp.google.com (unknown [74.125.57.93]) by mork.alvestrand.no (Postfix) with ESMTPSA id 321177C01CE for <mmusic@ietf.org>; Wed, 14 Oct 2015 09:10:44 +0200 (CEST)
To: "mmusic@ietf.org" <mmusic@ietf.org>
From: Harald Alvestrand <harald@alvestrand.no>
X-Enigmail-Draft-Status: N1110
Message-ID: <561DFFF3.5040703@alvestrand.no>
Date: Wed, 14 Oct 2015 09:10:43 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/xSePoqrrUbX5-AVgjhXkatIxroE>
Subject: [MMUSIC] Some more thoughts on the simulcast discussion
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 14 Oct 2015 07:10:47 -0000

This note is in response to yesterday's simulcast discussion. It's not
directly related to the current proposals, and doesn't criticize or
suggest changes to them in detail; it's more of a "step back".

It seems to me that simulcast is just the latest iteration of a
recurring problem, which can be roughly described as

  HOW DO WE SPECIFY CONSTRAINTS ON A MEDIA STREAM?

It seems to me also that we've consistently failed to come up with
viable, reusable, architecturally clean solutions to this problem. So
perhaps it's time to step back.

The problem can be broken into three logical parts:

- WHICH media stream(s) are we talking about?
- WHAT constraints do we want to describe for it?
- WHEN do we want these constraints to apply?

The first question (WHICH) has often been answered with "media section",
"ssrc", "payload type" or "payload type inside a media section"; the
current debate suggests adding "rid" to the mix. SSRC is said to be
unsuitable because the rules say that other session participants can
force you to change your SSRC by colliding with it.

The second question has had numerous answers, all with slightly
different syntax and semantics:

- fmtp parameters (which don't have agreed-upon cross-codec syntax)
- a=imageattr parameters
- b=, a=ptime, lots of ad hoc parameters
- the COP proposal
- the current rid proposal

The third question includes answers of "after (re)negotiation", "at
random times signalled in RTP" (the COP proposal), "whenever a stream is
active (it can be paused)" and so on. It also includes the question of
"who decides" - at the moment, proposals seem to be of the form
"proposer sets the limits, responder can accept these limits or propose
tighter ones; responder's limits are always accepted", but that's not
the only way this can be imagined - even within the confines of SDP usage.

Lapsing into similes: It seems to me that we would be better off if we
could avoid inventing more incompatible drive trains and making sure we
have a reusable wheel and a reusable gearbox.

     Harald