Re: [rtcweb] CNAMEs and multiple peer connections

Martin Thomson <martin.thomson@gmail.com> Thu, 13 March 2014 16:53 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 3C3011A0A27 for <rtcweb@ietfa.amsl.com>; Thu, 13 Mar 2014 09:53:55 -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 FtpTIdMwmxVA for <rtcweb@ietfa.amsl.com>; Thu, 13 Mar 2014 09:53:53 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 71F511A09CE for <rtcweb@ietf.org>; Thu, 13 Mar 2014 09:53:53 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id cc10so4207849wib.14 for <rtcweb@ietf.org>; Thu, 13 Mar 2014 09:53:46 -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=LMNyOfm10gDRUmhcPV0LoNgeCbsarP5PnQ2SfzQ0fGM=; b=KZfz6iRISjSEmDE5EWm473IiCSF01grD6Nq47rDk3nNE3QJSwzS+UBGH/f7mdqATsF RJv5OdDtmiDdLOcaRR45won2EoV4CGmq3rAoPsPBAJ3HEy48qTTjkAR7HaSe2Aux4z+K bk/5/jEi2xg503STfnsCuzwUe7UCC68sq8B12vmXBw5NcpxQQtbeBmi6D9/MtCH/d040 UobZw0c38PyCdDRkEWOuKh7kS9iXhqzq/hO3XI5Rfc9eluMo0nuWe1lyUkrFmXWkcEf/ eVJYt3hmTSPZ95g+QpVCy3nR8+RGja1xnev7PiomNw75HEhn6vI5eC1VvqQ/T43qfhR2 Oc2w==
MIME-Version: 1.0
X-Received: by 10.194.236.9 with SMTP id uq9mr2551507wjc.31.1394729626535; Thu, 13 Mar 2014 09:53:46 -0700 (PDT)
Received: by 10.227.10.196 with HTTP; Thu, 13 Mar 2014 09:53:46 -0700 (PDT)
In-Reply-To: <53201AEF.6090501@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> <CABkgnnVscHB6_weLkxHunQxLue7g-WvBwO-P_CW6eEU_JYqVuw@mail.gmail.com> <53201AEF.6090501@ericsson.com>
Date: Thu, 13 Mar 2014 09:53:46 -0700
Message-ID: <CABkgnnX16mOUOCmQ3wgQ2AV8o5WNXpCjVi-Rhr+ASWQ2LPzA-w@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/Zt26DKIOIWe_LPlxR5X2zZ7xpXg
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: Thu, 13 Mar 2014 16:53:55 -0000

On 12 March 2014 01:29, Magnus Westerlund
<magnus.westerlund@ericsson.com> wrote:
> I like to point out that the agreement and what is documented in
> rtp-usage is that WebRTC endpoint will have to make forwarded streams
> appear as locally originated. However, this as currently written does
> not apply to RTP middleboxes that interconnects multiple PeerConnections
> to form a multi-party session. This is deliberate to ensure that RTP
> topologies like RTP mixer and SFM do work on the RTP/RTCP level.

I'm still not clear on whether a middlebox interoperating with a
WebRTC endpoint is obligated to respect these rules or not.  I had
assumed that WebRTC is such a bully that they would be forced to.

> I am especially interested to know how you will "easy to apply manually"
> the synchronization. Can you please describe that. Because, that either
> requires an API call to tell the media framework, please consider the
> following CNAMES as equivalent, or some other method of telling the
> media framework that these different MST are actually originating from a
> common clock base.
In WebRTC, this would be:

var audio = pc1.getRemoteStreams()[0].getAudioTracks()[0];
var video = pc2.getRemoteStreams()[0].getVideoTracks()[0];
var synchronizedStream = new MediaStream(audio, video);

We'd have to say that this implies a statement about the clock base of
the tracks being the same.  ... and that this statement could be
wrong.

As far as it goes, I'm sure that other systems could build a similar
function, but none of those are standardized.

> I protested about this, not to lower the users privacy, but over the
> concern that this was raised without providing a case where it was
> obvious that the user's privacy was impacted. Martin, you said that you
> would think about it, and the next statement was lets change it, without
> providing any motivation why the concern was significant.

I'm sorry about that, I thought about it, but didn't want to waste
everyone's time (mine included) with an essay on the subject.