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

[Magnus Westerlund <[e-mail]>]

On 2014-04-04 19:37, Martin Thomson wrote:
> On 4 April 2014 09:34, Colin Perkins <[e-mail]> 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  [phone]
Färögatan 6                 | Mobile [phone]
SE-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------