Re: [MMUSIC] Simulcast worries: Fallback in the a=rid language

Adam Roach <> Thu, 22 October 2015 18:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D87291AC3DF for <>; Thu, 22 Oct 2015 11:19:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.71
X-Spam-Status: No, score=-0.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_19=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BGZr67zXS7TY for <>; Thu, 22 Oct 2015 11:19:22 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 31AA91B2AE2 for <>; Thu, 22 Oct 2015 11:19:09 -0700 (PDT)
Received: from ( []) (authenticated bits=0) by (8.15.2/8.14.9) with ESMTPSA id t9MIIxuY076341 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 22 Oct 2015 13:19:00 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be
To: Harald Alvestrand <>, Martin Thomson <>, Peter Thatcher <>
References: <> <> <> <> <> <> <>
From: Adam Roach <>
Message-ID: <>
Date: Thu, 22 Oct 2015 13:18:54 -0500
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="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: "" <>
Subject: Re: [MMUSIC] Simulcast worries: Fallback in the a=rid language
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: Thu, 22 Oct 2015 18:19:24 -0000

On 10/22/15 1:13 PM, Harald Alvestrand wrote:
> Den 22. okt. 2015 16:43, skrev Adam Roach:
>> On 10/22/15 00:37, Harald Alvestrand wrote:
>>> If I tell someone I can't take more than X from them (recv), it's
>>> dangerous if they ignore it, because they can overrun my limitations
>>> through ignorance.
>> And if they don't support the simulcast mechanism at all, they'll do the
>> same thing. You're asking us to solve a problem that is unrelated to the
>> mechanism.
> I don't understand this comment.
> If that (telling the other guy not to send more in a simulcast than you
> want to handle) isn't the problem the mechanism was supposed to solve,
> what IS the point of the mechanism?
> I'm assuming that the correspondent that doesn't understand simulcast is
> restricted by other attributes like a=imageattr (well, sort of), a=fmtp
> and b=, so that this is regarded as a problem this mechanism doesn't
> have to solve.

Right, and all of those still apply, even when they *do* understand 

In any case, this is all kind of academic, unless you're proposing that 
we change things to work in the way you assert is broken. The current 
situation (in the spec) is that those RIDs containing restrictions that 
you don't understand are ignored. Not the restriction, the entire RID. I 
think your point that we might be able to allow the RIDs to say around 
for streams you're receiving (it doesn't matter if the far end restricts 
the stream it's sending in a way you don't understand) is a good one 
that we should probably take into account.