Re: [MMUSIC] Some more thoughts on the simulcast discussion

Paul Kyzivat <> Wed, 14 October 2015 17:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D73CB1ACE25 for <>; Wed, 14 Oct 2015 10:00:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.035
X-Spam-Status: No, score=-0.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_15=0.6, J_CHICKENPOX_19=0.6, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qV8TW5GlT6Jv for <>; Wed, 14 Oct 2015 10:00:26 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8F4FA1ACD16 for <>; Wed, 14 Oct 2015 10:00:26 -0700 (PDT)
Received: from ([]) by with comcast id V4zA1r0042JGN3p0150RHu; Wed, 14 Oct 2015 17:00:25 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id V50R1r0013Ge9ey0150RJa; Wed, 14 Oct 2015 17:00:25 +0000
References: <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Wed, 14 Oct 2015 13:00:23 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1444842025; bh=EyrYXO2lqhERdCX6ra1DtYzVvNv+4UCwA186M1IuYpA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=La3A59kKGOUpNDW3T0hs7ZrH3xVw8djCFZlWDIQT2U5PSwmKcYo5L/ULY+5UGwal+ dE0GBshxMqRKmBIV+P0ISjCkBfisaK0GAe4rhLCoMe1ub3J46sWSu/GwDgliS9nxtb ZNL1tcrh4thRiTxGCu14qN2LKDOe3AdyuPa8LA/UvqJ3lMwBNm6OqNz73OILbW2xfW 1GOOs7zJY2i6+82hi8T18UfHGM8lMA1+v3zaDDcnUZRkM3ADE+88zW5bfV778TwUHY v1pFNlIsGczbcG48M90a5ChdB56TM/friv6UE9ngEMj3uLj/zNGW3C5Z8ticxKfD27 USoBsCfURWpPg==
Archived-At: <>
Subject: Re: [MMUSIC] Some more thoughts on the simulcast discussion
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Oct 2015 17:00:28 -0000

On 10/14/15 3:10 AM, Harald Alvestrand wrote:
> 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


IIUC this is a result of lack of precision in SDP regarding what it is 

> 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.

Not necessarily which streams - rather *what things*.

The identifiers you list don't all identify the same sort of things.

I think it is necessary to go to draft-ietf-avtext-rtp-grouping-taxonomy 
and sort out which things in SDP identify which things there.

What seems clear is that SDP doesn't get the granularity right about the 
stuff it can reference. So people end up using things that aren't quite 
right, and adjusting their usage to align with what it is possible to 


> 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 mailing list