Re: [rtcweb] Comments on draft-jennings-rtcweb-plan-01

Martin Thomson <> Thu, 28 February 2013 17:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A3E221F8C53 for <>; Thu, 28 Feb 2013 09:07:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.716
X-Spam-Status: No, score=-6.716 tagged_above=-999 required=5 tests=[AWL=-3.417, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mEFLdK3IBuQm for <>; Thu, 28 Feb 2013 09:07:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 7609021F8C48 for <>; Thu, 28 Feb 2013 09:07:31 -0800 (PST)
Received: by with SMTP id hi18so2380672wib.15 for <>; Thu, 28 Feb 2013 09:07:30 -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; bh=59SSqKkz0IbbmVY1JWJHT8HlXIVFbfhCOCRySNCO0y4=; b=khwfi+L3zHSa3Z4+iLL2xzd4N9yPPexOUBKxer6F5J6ohwytOHWbIKN8UFQGk+v3HJ RB88bBcDvdsLP3Nynb0d30h3ttao/9Fxh51siwXow7f1/o3UHh6SQERa10q3uhuqD7iP KsXFIha4khhL6ejYJiVwOOxwXiYMuvICTn+xDimcOTXR0HKNRxD+AwedwAsXFzq+7ReI Vnid045FJaP32PK2fv2cmqTI8TwGBJxgIrs9NNm6WEcMIAq1ps3FBGkr+Cv14AjcDBeC W/b44PIN3XykDhZLaaBwAsCnkMgeBXMTi2GiNE0gFg66oI7yZ6CcWvcCI47oNJqi2Y8w D4uw==
MIME-Version: 1.0
X-Received: by with SMTP id h5mr12560487wjw.21.1362071250665; Thu, 28 Feb 2013 09:07:30 -0800 (PST)
Received: by with HTTP; Thu, 28 Feb 2013 09:07:30 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Thu, 28 Feb 2013 09:07:30 -0800
Message-ID: <>
From: Martin Thomson <>
To: Stefan Håkansson LK <>
Content-Type: text/plain; charset="UTF-8"
Cc: "" <>
Subject: Re: [rtcweb] Comments on draft-jennings-rtcweb-plan-01
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: Thu, 28 Feb 2013 17:07:32 -0000

In general, I believe that this is a largely reasonable proposal.

I too find the header extension problematic.  However, signaling based
on SSRC alone doesn't mesh well with the possibility that SSRC can
change in response to collisions.

In light of the solution for layer/simulcast-relationships, maybe the
right response is to have the first few messages on the new SSRC
indicate the old SSRC in a CSRC in case of renumbering.

That would give us the following semantics for CSRC:
 - Mixing/switching: this stream is derived from another stream
through mixing, switching or similar and this is the SSRC of that
contributing source
 - Layers: this stream depends on another stream, because it is
incomplete without it (we'd have to ensure that the pointer runs in
the one direction only, only dependent layers would have CSRC)
 - Simulcast: this stream is a (higher/lower) quality variant of the
stream with the given SSRC, either can be used as an entire
replacement (all variants would have CSRCs for all other variants)
 - Renumbering: this stream was previously known by another SSRC

A receiver can treat mixing, simulcast and renumbering using the same
logic: it can render the last packet that arrives, with the normal
allowances for selecting from simulcast streams.  Layered association
uses the mechanisms appropriate to the codec.

Stefan said:
> Is there a
> risk that the ICE -candidate's references to m-lines gets out of sync?

That one's a non-issue.  You can't remove m-blocks, so the index is consumed.