Re: [rtcweb] [MMUSIC] Extremely drafty minutes

Ted Hardie <> Tue, 05 March 2013 21:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CEC0421F881D; Tue, 5 Mar 2013 13:26:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FpU-Yt34AG4C; Tue, 5 Mar 2013 13:26:26 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c02::229]) by (Postfix) with ESMTP id 7FA9A21F87FF; Tue, 5 Mar 2013 13:26:25 -0800 (PST)
Received: by with SMTP id j5so6775091iaf.0 for <multiple recipients>; Tue, 05 Mar 2013 13:26:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=BB7LyMd/ANd7ImshFunJznsj57UMxQPNpd3XUKjfXoU=; b=dZWJxmqkj3PbfBFbUQpKjBxSg8cf+QAtx04077xx8cNgk9RRRVR9q6SMd6vnva1jdJ VFRyheg6G3G2A0CYgIclc4soESFz1V8c7M/pEQ0ViQnf0TozgqfQyfyYMLah3F7kEqcH 0k/W04bzCPZuGeRwXDgN4exLmrGByR7ZPXN9tbjF6JL4Te+eXLSbr6ma+DRfTYIBJr10 D/e97oFpzfW2zJErAx+OdWBvdtUvcYy43+U8FUfrol4m1o+j/IJBCYZ6yz+zEbj9/BBh ytSyk3mtJzSAARZ6a4rm6Z55aGc7EUHbe6INhka6iceBtxIMPQ4yVkqK1P+ew1WUFpln +8nA==
MIME-Version: 1.0
X-Received: by with SMTP id r9mr7814974igj.96.1362518784931; Tue, 05 Mar 2013 13:26:24 -0800 (PST)
Received: by with HTTP; Tue, 5 Mar 2013 13:26:24 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Tue, 5 Mar 2013 13:26:24 -0800
Message-ID: <>
From: Ted Hardie <>
To: "Charles Eckel (eckelcu)" <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" <>, "" <>, Harald Tveit Alvestrand <>
Subject: Re: [rtcweb] [MMUSIC] Extremely drafty minutes
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Mar 2013 21:26:27 -0000

On Tue, Mar 5, 2013 at 9:06 AM, Charles Eckel (eckelcu)
<> wrote:

> One question I have is in regard to the following point from the Feb 5 summary.
> " All SSRCs related to a single peer connection (which could encompasses more than one MediaStreams having more than one track) would come from a single SSRC space. "
> Is this a restatement of an opinion expressed at the mic, or does it carry some weight as a working group consensus? I recall discussion in this area, but I did not think consensus was reached that this is the way to go. If that is the case, I think the notes should mention that more discussion is needed.

My understanding of this is that it was expressed as a requirement by
WebRTC on the work of RTCWEB, needed as part
of the mechanics of how to plumb connections via the API.  The base
requirement is "a consistent identifer space for all the
media that will be plumbed"; the SSRCs are the identifiers available.
I may be mis-stating this, though, so it might be helpful
if Stefan or Harald commented, as I think it was one of them that
actually expressed it.

As context for those who might be able to add their own understanding
here, this is the relevant part of the draft

For signaling, among the points raised:  CLUE and RTCWEB likely have
two different usage patterns.
For CLUE, multiple media sources will be common, multiple encodings
per media source will be the norm,
multiple endpoints may be visible even in unicast transport, and there
may be one or more RTP session.
For RTCWEB, the current theory is that there is a single RTP session
per media type,
if not a single RTP session full stop.  All SSRCs related to a single
peer connection (which could
encompasses more than one MediaStreams having more than one track)
would come from a single
SSRC space.