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

Harald Alvestrand <> Thu, 15 October 2015 21:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 060671A1B8E for <>; Thu, 15 Oct 2015 14:00:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kEajZZUCDfZd for <>; Thu, 15 Oct 2015 14:00:56 -0700 (PDT)
Received: from ( [IPv6:2001:700:1:2::117]) by (Postfix) with ESMTP id 213DB1A1B83 for <>; Thu, 15 Oct 2015 14:00:55 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED6A27C03AD; Thu, 15 Oct 2015 23:00:54 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dBV5gzKliURC; Thu, 15 Oct 2015 23:00:54 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPSA id 05E8A7C03A0; Thu, 15 Oct 2015 23:00:53 +0200 (CEST)
To: Adam Roach <>,
References: <> <> <> <>
From: Harald Alvestrand <>
Message-ID: <>
Date: Thu, 15 Oct 2015 23:00:53 +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: <>
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: Thu, 15 Oct 2015 21:00:58 -0000

On 10/15/2015 10:46 PM, Adam Roach wrote:
> On 10/14/15 15:28, Harald Alvestrand wrote:
>> On 10/14/2015 07:00 PM, Paul Kyzivat wrote:
>>> On 10/14/15 3:10 AM, Harald Alvestrand wrote:
>>> 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 describe.
>> We are worrying about the same set of issues.
> This is actually the exact problem that RID seeks to solve: by
> defining a new construct rather than trying to leverage existing ones
> (which, as you observe, end up being ill-fitting in many cases), we
> are able to point quite precisely at the *thing* of interest, instead
> of obliquely waving at some badly-matched proxy for that thing.

That is the good thing about RID: That it is able to point precisely at
one specific media stream.
[distraction: can two media streams have the same RID but different
SSRCs? What does that mean if it's legal? Where do we enforce the
restriction if it's illegal?]

That was also the good thing about a=SSRC (modulo the collision problem).

Now we "only" have to define:

- What exactly we can state about the thing we're pointing at
- What language(s) we use to make those statements
- How those statements are resolved against all the *other* tools inside
SDP that can be used to make statements about things that might also
happen to refer to the thing we're pointing at.

It's possible that we can define RID in such a way that the answers are
simple enough that they can be written down and agreed upon quickly.

But I can't see us succeeding without at least considering the issues.

> /a

Surveillance is pervasive. Go Dark.