Re: [rtcweb] CNAMEs and multiple peer connections

Magnus Westerlund <> Mon, 10 March 2014 15:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 503771A043E for <>; Mon, 10 Mar 2014 08:19:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.24
X-Spam-Status: No, score=-1.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id T2ovF_zyoc9e for <>; Mon, 10 Mar 2014 08:19:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AE7791A031D for <>; Mon, 10 Mar 2014 08:19:42 -0700 (PDT)
X-AuditID: c1b4fb32-b7f4c8e0000012f5-c3-531dd8088b69
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id D4.85.04853.808DD135; Mon, 10 Mar 2014 16:19:36 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 16:19:35 +0100
Message-ID: <>
Date: Mon, 10 Mar 2014 16:19:35 +0100
From: Magnus Westerlund <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: Martin Thomson <>, Justin Uberti <>
References: <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJLMWRmVeSWpSXmKPExsUyM+JvjS7HDdlgg+8rtS22ThWyuHbmH6PF 2n/t7A7MHjtn3WX3WLCp1GPJkp9MAcxRXDYpqTmZZalF+nYJXBlvrtsUnBermLjlA2sD41ah LkZODgkBE4nb9w6wQthiEhfurWfrYuTiEBI4wSjx59FrNpCEkMByRokdVwxAbF4BbYmfTzaz gNgsAqoSH08uArPZBCwkbv5oBKsXFQiW2HngNyNEvaDEyZlPwGpEgOK3jt5lBrGZBdQl7iw+ xw5iCwtYSTw5fIAFYvF+Jonp3y+DNXMKBEocf/ANyOYAuk5coqcxCKJXU6J1+292CFteonnr bGaIO7UlGpo6WCcwCs1CsnoWkpZZSFoWMDKvYpQsTi0uzk03MtDLTc8t0UstykwuLs7P0ytO 3cQIDO6DW34b7WA8ucf+EKM0B4uSOO911pogIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwr gwPCr+s5Xvp76mHprHJX0RftCkwZ9XV/DsdI75Zwmv8nK/jnlwUlUdtiUi23G4rEzmAw9k/h Dc1U0ZB5uf7ar/ehW6IuXFmhoDV778vme73Pbdt91x978y8n2kLV1Vny6JrL4jMnTU0VPJLq /Wx7eYxLrHJNjsf2ildTxapWFZ5R1/8ieUyJpTgj0VCLuag4EQCE6EwePAIAAA==
Cc: "" <>
Subject: Re: [rtcweb] CNAMEs and multiple peer connections
X-Mailman-Version: 2.1.15
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: Mon, 10 Mar 2014 15:19:44 -0000

On 2014-03-05 17:07, Martin Thomson wrote:
> On 5 March 2014 14:30, Justin Uberti <> wrote:
>> I am inclined to make CNAMEs per-PeerConnection (i.e. enforce scenario #2
>> behavior) for 1.0, as it has a smaller downside.
> I think that I am OK with this.  It might still be possible to
> synchronize in the first scenario, but it would require that the
> playback protect itself against drift, because CNAME wouldn't be
> providing a positive indication that synchronization is safe.

Please slow down here,

Can you please think through the linkage issue a bit first before
changing this property. I know that it might appear simple to mandate
different CNAMES on a Per PC basis, but I do think it has downsides.

One has to do with loop detection between the PCs, i.e. determine if one
receives one self's MSTs. The next one is that it will prevent someone
to easily determine if the MST in two different PCs are actually sharing
the same synchronization context. As the default really needs to not
synchronize RTP media with different SSRCs, having the JS app direct the
browser to please consider some set of CNAMEs as being equal will be a
problematic one, and require API surface.

I want to understand what issue with linkages that we have here before
determining what to do. So, different application contexts, i.e.
different browser TABs on an end-point will have different CNAMEs, thus
different applications will not allow linking between them. The linkage
we have is between PCs originating in the same JS application instance.
In cases where a set of end-points participate in a conference, they
will see only one CNAME from this endpoint.

I guess the linkage issue appears when one application have the endpoint
participate in two or more conferences either simultaneous or in
sequence (assuming that CNAME will be persistent as long as some PC
exists or during the JS application lifetime). In that case an external
endpoint participating in more than one of these conferences can see the
same CNAME appears in both conferences. And thus link any input
provided, if the applications doesn't otherwise reveal the user identity
etc. anyway.

I have a hard time determine the impact of this linkage issue, as it
will depend on the application context, and also the CNAMEs persistence
over time within a JS APP context.


Magnus Westerlund

Services, Media and Network features, Ericsson Research EAB/TXM
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: