Re: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage

Magnus Westerlund <magnus.westerlund@ericsson.com> Mon, 07 April 2014 10:58 UTC

Return-Path: <magnus.westerlund@ericsson.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 E42761A03C3 for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 03:58:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 eahBYYCjNFJc for <rtcweb@ietfa.amsl.com>; Mon, 7 Apr 2014 03:58:06 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEC61A03B7 for <rtcweb@ietf.org>; Mon, 7 Apr 2014 03:58:06 -0700 (PDT)
X-AuditID: c1b4fb38-b7f518e000000889-15-534284b7da97
Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 51.7A.02185.7B482435; Mon, 7 Apr 2014 12:58:00 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.92) with Microsoft SMTP Server id 14.3.174.1; Mon, 7 Apr 2014 12:57:59 +0200
Message-ID: <534284B7.7010103@ericsson.com>
Date: Mon, 7 Apr 2014 12:57:59 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: Martin Thomson <martin.thomson@gmail.com>, Colin Perkins <csp@csperkins.org>
References: <533E76AC.7030003@ericsson.com> <CABkgnnVD09V80OkXY=ZKicYhjBMR8XZMFYCXrMmHMkVWE7mwVw@mail.gmail.com> <005B30AC-F891-481E-A25A-D3705713F1D3@csperkins.org> <CABkgnnUSpeL8fv=7gRmM+QSYvFgd16r_2cP6J066DL+dkydrCg@mail.gmail.com>
In-Reply-To: <CABkgnnUSpeL8fv=7gRmM+QSYvFgd16r_2cP6J066DL+dkydrCg@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUyM+Jvje6OFqdgg/2rWS2WvzzBaHHtzD9G i7X/2tkdmD2m3b/P5rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZaz79p+14LxsxZNdi5gb GK+KdzFyckgImEic33GRCcIWk7hwbz1bFyMXh5DAUUaJHbvfMUM4yxglWtesZAGp4hXQltjz +zwjiM0ioCJx6P1tMJtNwELi5o9GNhBbVCBYYumcxVD1ghInZz4Bsjk4RASCJPr7ikHCzALq EncWn2MHsYUFfCRuXf7HCrHrFaPEjRVzwBKcAoESu+d/YgTplRAQl+hpDILo1ZRo3f6bHcKW l2jeOpsZxBYCOq2hqYN1AqPQLCSbZyFpmYWkZQEj8ypGjuLU4qTcdCODTYzAAD645bfFDsbL f20OMUpzsCiJ83586xwkJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgZFNekWIUGJ6zMsjtvzS +7oPO1V67T+xaYlczLtHimkzYiW3rezXPHd5/ZGG60+1Ni9PWG0o1zLlj8LWjR8Kp9rOsdJU dDmcuazy6qSvRRNtyj943H92g1lS8cTELTd/Gca+XXBs/+LOPPZA79kbo88160xbcc9m9a/A J5JiISqOTz7ubasJcVmoxFKckWioxVxUnAgAPDw7PS4CAAA=
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/GDciSQrzmDWBOJH0g8OMTJmsD6E
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage
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, 07 Apr 2014 10:58:11 -0000

On 2014-04-04 19:37, Martin Thomson wrote:
> On 4 April 2014 09:34, Colin Perkins <csp@csperkins.org> wrote:
>> I’m perhaps misunderstanding something, or we may not have phrased the text clearly, but what you say you want generally matches my understanding of what the draft provides. Can you expand on what parts of the text you think are problematic?
> 
> The first paragraph of Section 11 seems directly contrary to what I outlined.
> 
> I don't know how you interpret this, but I read the following text as
> saying the complete opposite of my suggestion to allow setting of
> CNAME:
> 
>       There are no known reasons for WebRTC end-points that aren't RTP
>       middleboxes or servers to configure a persistent identifiers,
>       these considerations are limited to RTP middleboxes.  Thus, such
>       configuration options SHOULD NOT be present in most WebRTC end-
>       point implementations to prevent misconfiguration or malicious
>       configuration that allows tracking or linking of a user.
> 
> Now that I've gone back and re-read again, I think that this text is
> possibly confused, and certainly confusing, with respect to use of the
> various contexts in play.
> 
>  * The text uses RTP end-point, which I infer corresponds to the
> (local) end of the ICE component in use (i.e., the selected transport
> 5-tuple).  An RTP end-point is required to have a unique CNAME, but
> that's not consistent with unbundled (SDP negotiated) sessions (i.e.,
> what corresponds to a single unbundled RTCPeerConnection), which I
> assume will want to use a consistent CNAME if at all possible.
> 
>  * We also have guidance regarding RTCPeerConnection.
> 
>  * And there is also guidance regarding the browser session,
> presumably scoped to a given origin [RFC6454].
> 
>  * I'll list RTP session for completeness, though I don't think it's a
> useful context to use in any case.
> 
> I think that the advice could be much clearer, once all the context is
> properly established:
> 
>   1. MUST use the same CNAME for an RTP end-point, unless different
> SSRCs are on a different time base (i.e., the uncommon case)
> 
>   2. MUST use different CNAME for different RTCPeerConnection
> instances, following RFC 7022, unless the using application explicitly
> provides a CNAME.

This is the intent of the text provided. So, I guess it is further work
on how things are formulated that are needed, not the intended content.
In fact regarding the first we have been stricter than that, the reason
is to avoid the synchronization issues that arises from creating
MediaStreams from MediaStreamTracks with different time-bases. That
issue would disappear if MediaStream are abandoned in the API, and then
I would prefer your notice of exception when handling multiple timebases
locally.

> 
> The latter point covers the origin case adequately.  Servers and
> middleboxes can be given a blanket exemption if you like, allowing for
> the fact that they should be doing all the normal and proper RTP
> things.

I think a important aspect from a middlebox why multiple CNAMEs is to be
expected and not necessariyl follow the default rules, is that they may
not be controlled as normal WebRTC endpoint, i.e. no normal JS API.

Cheers

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: magnus.westerlund@ericsson.com
----------------------------------------------------------------------