[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
- [MMUSIC] Some more thoughts on the simulcast disc… Harald Alvestrand
- Re: [MMUSIC] Some more thoughts on the simulcast … Paul Kyzivat
- Re: [MMUSIC] Some more thoughts on the simulcast … Harald Alvestrand
- Re: [MMUSIC] Some more thoughts on the simulcast … Harald Alvestrand
- Re: [MMUSIC] Some more thoughts on the simulcast … Adam Roach
- Re: [MMUSIC] Some more thoughts on the simulcast … Paul Kyzivat
- Re: [MMUSIC] Some more thoughts on the simulcast … Jonathan Lennox
- Re: [MMUSIC] Some more thoughts on the simulcast … Bo Burman