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

Harald Alvestrand <> Thu, 22 October 2015 05:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A31E81B2E2F for <>; Wed, 21 Oct 2015 22:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MOMNmwa_biIZ for <>; Wed, 21 Oct 2015 22:37:55 -0700 (PDT)
Received: from ( [IPv6:2001:700:1:2::117]) by (Postfix) with ESMTP id 4F7361B2DFA for <>; Wed, 21 Oct 2015 22:37:36 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E8CE7C037D; Thu, 22 Oct 2015 07:37:35 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rnM_Xidlix7Z; Thu, 22 Oct 2015 07:37:34 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:1:6990:e3f4:94de:b939] (unknown [IPv6:2001:470:de0a:1:6990:e3f4:94de:b939]) by (Postfix) with ESMTPSA id 7DA6F7C0350; Thu, 22 Oct 2015 07:37:34 +0200 (CEST)
To: Martin Thomson <>, Peter Thatcher <>
References: <> <> <> <>
From: Harald Alvestrand <>
Message-ID: <>
Date: Thu, 22 Oct 2015 07:37:32 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
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 05:37:57 -0000

On 10/22/2015 12:23 AM, Martin Thomson wrote:
> On 21 October 2015 at 15:05, Peter Thatcher <> wrote:
>> But if you have max-goats and max-dogs and max-cats and the answerer
>> supports max-dogs but not max-goats or max-cats,  how can it structure it to
>> offer all the combinations of what might work and what might not?
> Yes, combinatorial explosion ensues.
> My view is that we aren't likely to add enough of these extensions
> that we will ever reach that explosion point.
> And if enough time lapses between introduction of different things,
> you can start to make assumptions about things, and do things like
> bundle max-dogs and max-cats together.  Sure, the guy who understands
> (not supports) only max-dogs falls back to the baseline, but as long
> as you have a baseline you don't suffer too badly.
> In practice, I think that this will only create a modest amount of
> pressure not to extend.  I can't actually think of a downside to that.
> BTW, this is a repeat of a similar discussion we had in HTTP.  There,
> we settled on having parameters be ignored if not supported.  I don't
> think that's feasible in this context because things like limits are
> important.
The logic is in fact different for the two directions.

If I tell someone I'm going to stick to a limit they don't know about
(send), no harm will come from ignoring the parameter - I can stick to
the limit anyway.

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.

That tells me that:

a) we need to think more about this
b) sendrecv is a bad idea

Surveillance is pervasive. Go Dark.