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

[Magnus Westerlund <[e-mail]>]

Hi Martin and WG,

Colin has helped clarify the text. Thus, I wanted to provide an updated
version of the text to see if this resolves your concerns properly.


Section 4.1 (Part)

   o  Support for multiple synchronisation contexts.  Participants that
      send multiple simultaneous RTP packet streams SHOULD do so as part
      of a single synchronisation context, using a single RTCP CNAME for
      all streams and allowing receivers to play the streams out in a
      synchronised manner.  For compatibility with potential future
      versions of this specification, or for interoperability with non-
      WebRTC devices through a gateway, receivers MUST support multiple
      synchronisation contexts, indicated by the use of multiple RTCP
      CNAMEs in an RTP session.  This specification requires the usage
      of a single CNAME when sending RTP Packet Streams in some
      circumstances, see Section 4.9.

4.9.  Generation of the RTCP Canonical Name (CNAME)

   The RTCP Canonical Name (CNAME) provides a persistent transport-level
   identifier for an RTP end-point.  While the Synchronisation Source
   (SSRC) identifier for an RTP end-point can change if a collision is
   detected, or when the RTP application is restarted, its RTCP CNAME is
   meant to stay unchanged for the duration of a RTCPeerConnection
   [W3C.WD-webrtc-20130910], so that RTP end-points can be uniquely
   identified and associated with their RTP packet streams within a set
   of related RTP sessions.

   Each RTP end-point MUST have at least one RTCP CNAME, and that RTCP
   CNAME MUST be unique within the RTCPeerConnection.  RTCP CNAMEs
   identify a particular synchronisation context, i.e., all SSRCs
   associated with a single RTCP CNAME share a common reference clock.
   If an end-point has SSRCs that are associated with several
   unsynchronised reference clocks, and hence different synchronisation
   contexts, it will need to use multiple RTCP CNAMEs, one for each
   synchronisation context.

   Taking the discussion in Section 11 into account, a WebRTC end-point
   MUST NOT use more than one RTCP CNAME in the RTP sessions belonging
   to single RTCPeerConnection (that is, an RTCPeerConnection forms a
   synchronisation context).  RTP middleboxes MAY generate RTP packet
   streams associated with more than one RTCP CNAME, to allow them to
   avoid having to resynchronize media from multiple different end-
   points part of a multi-party RTP session.

   The RTP specification [RFC3550] includes guidelines for choosing a
   unique RTP CNAME, but these are not sufficient in the presence of NAT
   devices.  In addition, long-term persistent identifiers can be
   problematic from a privacy viewpoint (Section 13).  Accordingly, a
   WebRTC endpoint MUST generate a new, unique, short-term persistent
   RTCP CNAME for each RTCPeerConnection, following [RFC7022].

   An WebRTC end-point MUST support reception of any CNAME that matches
   the syntax limitations specified by the RTP specification [RFC3550]
   and cannot assume that any CNAME will be chosen according to the form
   suggested above.


Section 11 (Part)

   The same MediaStreamTrack can also be included in multiple
   MediaStreams, thus multiple sets of MediaStreams can implicitly need
   to use the same synchronisation base.  To ensure that this works in
   all cases, and don't forces a end-point to change synchronisation
   base and CNAME in the middle of a ongoing delivery of any packet
   streams, which would cause media disruption; all MediaStreamTracks
   and their associated SSRCs originating from the same end-point needs
   to be sent using the same CNAME within one RTCPeerConnection.  This
   is motivating the strong recommendation in Section 4.9 to only use a
   single CNAME.

      Note: It is important that the same CNAME is not used in different
      communication session contexts or origins, as that could enable
      tracking of a user and its device usage of different services.
      See Section 4.4.1 of Security Considerations for WebRTC
      [I-D.ietf-rtcweb-security] for further discussion.

      The requirement on using the same CNAME for all SSRCs that
      originates from the same end-point, does not require middleboxes
      that forwards traffic from multiple end-points to only use a
      single CNAME.

   The above will currently force a WebRTC end-point that receives an
   MediaStreamTrack on one RTCPeerConnection and adds it as an outgoing
   on any RTCPeerConnection to perform resynchronisation of the stream.
   This, as the sending party needs to change the CNAME, which implies
   that it has to use a locally available system clock as timebase for
   the synchronisation.  Thus, the relative relation between the
   timebase of the incoming stream and the system sending out needs to
   defined.  This relation also needs monitoring for clock drift and
   likely adjustments of the synchronisation.  The sending entity is
   also responsible for congestion control for its the sent streams.  In
   cases of packet loss the loss of incoming data also needs to be
   handled.  This leads to the observation that the method that is least
   likely to cause issues or interruptions in the outgoing source packet
   stream is a model of full decoding, including repair etc followed by
   encoding of the media again into the outgoing packet stream.
   Optimisations of this method is clearly possible and implementation
   specific.

   A WebRTC end-point MUST support receiving multiple MediaStreamTracks,
   where each of different MediaStreamTracks (and their sets of
   associated packet streams) uses different CNAMEs.  However,
   MediaStreamTracks that are received with different CNAMEs have no
   defined synchronisation.

      Note: The motivation for supporting reception of multiple CNAMEs
      are to allow for forward compatibility with any future changes
      that enables more efficient stream handling when end-points relay/
      forward streams.  It also ensures that end-points can interoperate
      with certain types of multi-stream middleboxes or end-points that
      are not WebRTC.


Section 13 (Part)

   RTCP packets convey a Canonical Name (CNAME) identifier that is used
   to associate RTP packet streams that need to be synchronised across
   related RTP sessions.  Inappropriate choice of CNAME values can be a
   privacy concern, since long-term persistent CNAME identifiers can be
   used to track users across multiple WebRTC calls.  Section 4.9 of
   this memo provides guidelines for generation of untraceable CNAME
   values that alleviate this risk.

-- 

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