Re: [rtcweb] CNAMEs and multiple peer connections

Magnus Westerlund <> Fri, 14 March 2014 08:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1F2DA1A00AD for <>; Fri, 14 Mar 2014 01:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.851
X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S-kynFy8EvZZ for <>; Fri, 14 Mar 2014 01:35:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 45BBA1A00A6 for <>; Fri, 14 Mar 2014 01:35:02 -0700 (PDT)
X-AuditID: c1b4fb25-b7f038e000005d01-ec-5322bf2e7d73
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id C1.5B.23809.E2FB2235; Fri, 14 Mar 2014 09:34:55 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Fri, 14 Mar 2014 09:34:54 +0100
Message-ID: <>
Date: Fri, 14 Mar 2014 09:34:54 +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 <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvja7+fqVgg5cJFlunCllcO/OP0WLt v3Z2B2aPnbPusnss2FTqsWTJT6YA5igum5TUnMyy1CJ9uwSujPnLzjMXdCtWTJoyib2B8alU FyMnh4SAiUTfthksELaYxIV769m6GLk4hAQOMUrsW7KVGcJZziix/PRHVpAqXgFtia5nO5hA bBYBVYn9f06DxdkELCRu/mhkA7FFBYIldh74zQhRLyhxcuYTsA0iAroSi84+YAexmQW8JT4t grCFBawknhw+wAKxrJNF4sn6RrAGToFAiet/nwLZHEDniUv0NAZB9GpKtG7/DTVHXqJ562xm EFsI6LaGpg7WCYxCs5CsnoWkZRaSlgWMzKsY2XMTM3PSy402MQJD9+CW36o7GO+cEznEKM3B oiTO++Gtc5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxj3X9oebbGB/VspgwPir5OWk1IM9 qxy2sta4B7YEcF+pitwcNMFlbWLsSa0Fr3WcLpdsf9XJdyDDIntLZezMKb373x3SjvyfePhj c1FHAtOTgr1yik3H7p+XDdCa8d991dIjV75ub+58cpOhhf2jmm+IxId5jcIrZ3hnlLsv2Bwh 82lOmSmzvBJLcUaioRZzUXEiADzKE+krAgAA
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: Fri, 14 Mar 2014 08:35:05 -0000

On 2014-03-13 17:53, Martin Thomson wrote:
> On 12 March 2014 01:29, Magnus Westerlund
> <> 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.

Well, I know Colin and I did put in quite some thought to make the
WebRTC RTP usage rules such that you can use the common RTP middleboxes
as long as you have the right front-end, i.e. DTLS-SRTP and signalling

>> 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.

I think this looks dangerous. If you default the assumption that
different CNAMEs of the MST you add are actually sharing clock base,
then a lot of basic programs that may group MST from different PCs into
one MS for convenience are going to cause serious issue in the media
frameworks, when they attempt to synchronize things.

> 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.

Having considered this a bit more, I do think the risk to privacy out
weighs the other concerns, as long as the API and its handling can be
sorted out, I don't think the above is sufficient to get good

My understanding is that the risk to privacy exist when one have one JS
application enabling communication in different contexts during the same
application session. In cases where there might be participants in the
different contexts that could link the same end-point and thus human
user to different participant IDs (that otherwise are anonymous). Thus
revealing privacy concerns. As it would take the application designer to
take this risk into consideration to avoid it, I feel safer if the
application designer would need to take active measurements to perform

I will wait an see if there are other inputs on this within the next
week. If nothing arises I will propose a text change to the rtp-usage to
address this.


Magnus Westerlund
(As individual)

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: