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

Martin Thomson <> Fri, 04 April 2014 17:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 022AD1A0239 for <>; Fri, 4 Apr 2014 10:37:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ywrdMT8-zijQ for <>; Fri, 4 Apr 2014 10:37:26 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::235]) by (Postfix) with ESMTP id 819C01A0224 for <>; Fri, 4 Apr 2014 10:37:12 -0700 (PDT)
Received: by with SMTP id q58so3791052wes.12 for <>; Fri, 04 Apr 2014 10:37:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Wv/eoS8rLqXZcQi78Cxk7rYyk6GFwhvgg6BAoxOQtvI=; b=YKWqNA+fll8vYY1CywnKMZf8nD41egzLfBLzw7JJ8hJEd2SLZLcWgCHr5YeUxOF2f9 nsMrZnaDmZSA4iMDOa5EFDfXA5lkMmiDv3x4Vp6Jtg41xBueXUHst4WvAD4PjYJ26a0r ZHZstlh4Xcb5/GxUBsKn4BNmVPNIO/q/Pc/Kly2XYdD8S7TCMm0Wt4d3+iFzTvxIrfXH wLKXRdBTXkEIZ3vm+LWdyrhmHjy44+Vhhxl8FSqmvKk/GC3xdGEtHDGK7wvD7MnzH+wM r3Fbhzh2SauAQ2rvghD0D0dc33wDBomzeuSka9pjFJNy9C+mMQQFgowtE7LOI2u5tjPc oRFg==
MIME-Version: 1.0
X-Received: by with SMTP id cz7mr7736233wjb.78.1396633027465; Fri, 04 Apr 2014 10:37:07 -0700 (PDT)
Received: by with HTTP; Fri, 4 Apr 2014 10:37:07 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Fri, 04 Apr 2014 10:37:07 -0700
Message-ID: <>
From: Martin Thomson <>
To: Colin Perkins <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [rtcweb] Text proposal for CNAME in draft-ietf-rtcweb-rtp-usage
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, 04 Apr 2014 17:37:35 -0000

On 4 April 2014 09:34, Colin Perkins <> 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

      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.

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