Re: [rtcweb] CNAMEs and multiple peer connections

Martin Thomson <martin.thomson@gmail.com> Mon, 10 March 2014 15:49 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6FF1A043E for <rtcweb@ietfa.amsl.com>; Mon, 10 Mar 2014 08:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yw_fBCy9Mne2 for <rtcweb@ietfa.amsl.com>; Mon, 10 Mar 2014 08:49:14 -0700 (PDT)
Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id E823E1A04B0 for <rtcweb@ietf.org>; Mon, 10 Mar 2014 08:49:10 -0700 (PDT)
Received: by mail-wg0-f52.google.com with SMTP id k14so8837822wgh.23 for <rtcweb@ietf.org>; Mon, 10 Mar 2014 08:49:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MTpS9Ix6fmuRmmmEC2vPKO+eQoKCYW1CM2M25lwo+As=; b=d42Zrt4Lvb+BZxe5MOYPVNE/u7n4DVOEfBmSXBY9xax8Bb19YeZitj/bdqWuGFpzab EHiyMg77KWGiDnO5ogbGSH0MciYGPuts5KeLcNzCccKmjCTTpStHPORQMB7zud8YeTCV MjlWeWMBHQC14fXYM0Ya6+NLeB/9LqdVGvmXAh2iBPfQ10GY8NB+FMgohUOdzLg5Af+T aSTAQdColmhFUyGKXOCBd8IzZBDzYhRunZ55fB+wR+c8KdduapulLWKjOn1HD73teSsu nY1Gk3aV9hPjnrRIIPb3jSMjjYjkP3aRha3D1c4xObEexTC3Bkse4BkciqlCP9cH/8pW EjtA==
MIME-Version: 1.0
X-Received: by 10.194.192.132 with SMTP id hg4mr6557988wjc.28.1394466544789; Mon, 10 Mar 2014 08:49:04 -0700 (PDT)
Received: by 10.227.10.196 with HTTP; Mon, 10 Mar 2014 08:49:04 -0700 (PDT)
In-Reply-To: <531DD807.9090602@ericsson.com>
References: <CABkgnnWGQ7GtKd33iF-RNbkeAyqKYshaPDDB=sAh5o-izKichQ@mail.gmail.com> <53171C20.3020001@ericsson.com> <CABkgnnWWoCLKga7RDEmS1kDOuBPaiKaJ+_yj6-yPRSV8LVc=2A@mail.gmail.com> <CAOJ7v-1J=F-MNnBS96gt3_BXyoQB6jTCoHp0MTEBC-nWrF-BhA@mail.gmail.com> <CABkgnnWQbtKYTuvUyMiCaEijv3KVydR8sxGXZep08B4EQXArxA@mail.gmail.com> <531DD807.9090602@ericsson.com>
Date: Mon, 10 Mar 2014 16:49:04 +0100
Message-ID: <CABkgnnVscHB6_weLkxHunQxLue7g-WvBwO-P_CW6eEU_JYqVuw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/-ccLUvX9CiMhWxkdxRRtyR_FJPc
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] CNAMEs and multiple peer connections
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Mar 2014 15:49:16 -0000

On 10 March 2014 16:19, Magnus Westerlund
<magnus.westerlund@ericsson.com> wrote:
> Can you please think through the linkage issue a bit first before
> changing this property.

We already came to the conclusion that if media was being forwarded by
a peer, then that is new media originated by that peer, not the same
media.  Thus, if looping occurs, it is at the application layer.  We
definitely already agreed that RTP forwarding is not a function that a
browser will support.

Obviously, if we add that feature, CNAMEs will be just one of the
manifold issues that will arise and we will have to reconsider.
Compromising the privacy of users doesn't seem like a good trade-off
against some minor advantages in terms of loop detection (unlikely)
and synchronization (easy to apply manually).