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

[Magnus Westerlund <[e-mail]>]

WG,
(As author)

Based on the discussion we authors have drafted a proposal for changing
the CNAME creation usage to be created unique between PeerConnections.
Our draft text is the below one. Please review. If we receive no
feedback we will include this in the next version of the draft that we
hope to be able to produce next week.

Section 4.1:

   o  Support for multiple synchronisation contexts.  Participants that
      send multiple simultaneous RTP packet streams 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.  Receivers MUST support reception of multiple
      RTCP CNAMEs in an RTP session, and hence multiple synchronisation
      contexts, to support RTP middleboxes, and future evolution needing
      multiple CNAMEs in an endpoint.  See also Section 4.9.


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, so that RTP end-points can be uniquely
   identified and associated with their RTP packet streams within a set
   of related RTP sessions.  For proper functionality, each RTP end-
   point needs to have at least one unique RTCP CNAME value.  From an
   RTP perspective an end-point can have multiple CNAMEs, as the CNAME
   also identifies a particular synchronisation context, i.e. all SSRC
   associated with a CNAME share a common reference clock, and if an
   end-point have SSRCs associated with different reference clocks it
   will need to use multiple CNAMEs.  This ought not be common, and if
   possible reference clocks ought to be mapped to each other and one
   chosen to be used with RTP and RTCP.  Taking the discussion in
   Section 11 into account a regular WebRTC end-point MUST NOT use more
   than a single CNAME in the RTP sessions belonging to single
   RTCPeerConnection.  RTP middleboxes MAY send RTP packet streams
   identified by more than one 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,
   support for generating a short-term persistent RTCP CNAMEs following
   [RFC7022] is REQUIRED to be implemented and RECOMMENDED to be used.
   Unless a persistent CNAME is explicitly configured, a unique CNAME(s)
   MUST be generated for each synchronization context an end-point has
   within each RTCPeerConnection, i.e. normally one across all the RTP
   sessions within the scope of the RTCPeerConnection.

      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.

   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:

   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.

-- 

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