Re: [rtcweb] CNAMEs and multiple peer connections

Magnus Westerlund <> Mon, 10 March 2014 14:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E24AB1A0437 for <>; Mon, 10 Mar 2014 07:42:29 -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 Rc8eH-a--pLx for <>; Mon, 10 Mar 2014 07:42:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7267C1A0434 for <>; Mon, 10 Mar 2014 07:42:27 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f5d8e000002a7b-47-531dcf4d7b69
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 54.11.10875.D4FCD135; Mon, 10 Mar 2014 15:42:21 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id 14.2.347.0; Mon, 10 Mar 2014 15:42:11 +0100
Message-ID: <>
Date: Mon, 10 Mar 2014 15:42:12 +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 <>, Dan Wing <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBLMWRmVeSWpSXmKPExsUyM+Jvja7vedlgg/vbZC0uXnvIZHHtzD9G i7X/2tkdmD2m/N7I6rFz1l12jyVLfjIFMEdx2aSk5mSWpRbp2yVwZcyYOp+9YK9QxdW77g2M X/m6GDk4JARMJDovxXUxcgKZYhIX7q1n62Lk4hASOMQo8eViAytIQkhgOaPE1qdCIDavgLZE Y+dxsDiLgKrE308TmEFsNgELiZs/GtlAbFGBYImdB34zQtQLSpyc+YQFxBYR8JT4sGMHmM0s oC5xZ/E5dhBbWMBK4snhAywQi48xSixZ+RdsAadAoMStFxNYIQ4Vl+hpDILo1ZOYcrWFEcKW l2jeOpsZ4k5tiYamDtYJjEKzkKyehaRlFpKWBYzMqxjZcxMzc9LLDTcxAkP34JbfujsYT50T OcQozcGiJM774a1zkJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQZGdf2rhzYu3PRjv9CdN1+P thm2T5jdyeCrYhF/ruTD8vlneu6WHNrRLuw7sWbDdtNTExqqD8gtVVzFOt27ZtlvntJINcs+ q+8Lauwb/Po8t2y6wn+wt0BiWaJOitStbNFXUZJRz+bzX96S2/nY357N98LGD9c0Xxmd/S9d ueb9bRZ/n8KV0yxmKLEUZyQaajEXFScCAFiLdswrAgAA
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: Mon, 10 Mar 2014 14:42:30 -0000

On 2014-03-08 07:48, Martin Thomson wrote:
> On 7 March 2014 20:14, Dan Wing <> wrote:
>> About half a year ago, AVTCORE published an updated recommendation
>> for CNAME as RFC7022.  Is its guidance insufficient?
> Necessary, but not sufficient.  Unfortunately, the definition of a 
> "session", while sufficient for the description in 7022, is not
> quite precise enough for this use case.  The implication there is
> that it means "RTP session", which is both not at the right level of 
> granularity, and not directly actionable.

So, within a PeerConnection one have one or more RTP sessions, depending
on how one configures it. That RTP session MAY be interconnected with
other PeerConnection's RTP sessions by a middlebox.

As long as this is different end-points PCs there is little issues. The
interesting case here is if one end-point connects multiple PCs to the
same middlebox and starts seeing its own traffic due to the middlebox
not being built for this usage and the JS programmer thinks this is okay
to do.

The end-point can always detect this, as it knows all its used CNAMEs,
and can note that they are looped back to itself if this check is
implemented. If one have the same CNAME is both PC's RTP session
instances the RTP stack is more likely to detect this without code
changes as a loop.

The only reason I can see for having multiple PCs being connected to the
same middlebox would be if that makes the setup of QoS simpler, but I
think MST individual RTP sessions within the context of one PC is more
straight forward to ensure that one have unique 5-tuples per media stream.

> I also note this little gem:
> A longer-term persistent RTCP CNAME is sometimes useful to
> facilitate third-party monitoring, consistent with [RFC3550].

Yes, but that is clearly not suitable for WebRTC.


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: