Subject: [rtcweb] Review of draft-ietf-rtcweb-rtp-usage

From: Jim Spring <[email-masked]>
Date: Thu, 8 May 2014 07:49:28 -0700

4.5.  RTP and RTCP Multiplexing

       ....

   Note that the use of RTP and RTCP multiplexed onto a single
   transport-layer flow ensures that there is occasional traffic sent on
   that port, even if there is no active media traffic.  This can be
   useful to keep NAT bindings alive, and is the recommend method for
   application level keep-alives of RTP sessions [RFC6263].

[JS] In the case of MUX, this may be the recommended method per
RFC6263 for keeping NAT bindings alive, but for WebRTC, we have also
talked about using STUN connectivity checks
[draft-ietf-rtcweb-stun-consent-freshness].  It seems a bit odd having
multiple methods specified.  If we adopt
draft-ietf-rtcweb-stun-consent-freshness, can the above be removed or
a section added to note the new draft.

4.7.  Symmetric RTP/RTCP

[JS] General question / comment - most other sections of the document
make a distinction when a WebRTC talks to another WebRTC client and
when talking to a legacy one.  This section does not, are there
concerns where a legacy client will not support Symmetric RTP/RTCP per
RFC4961?

4.8.  Choice of RTP Synchronisation Source (SSRC)

   Implementations are REQUIRED to support signalled RTP synchronisation
   source (SSRC) identifiers, using the "a=ssrc:" SDP attribute defined
   in Section 4.1 and Section 5 of [RFC5576].

[JS] This section appears to mandate SDP for signaling, other sections use
SDP as an example for signaling. Recommend reworking this to not require
specifics about SDP.

7.1.  Boundary Conditions and Circuit Breakers

   In the absence of a concrete congestion control algorithm, all WebRTC
   implementations MUST implement the RTP circuit breaker algorithm that
   is described in [I-D.ietf-avtcore-rtp-circuit-breakers].

[JS] At IETF 89, my understanding was that there were concerns around the
use of circuit breakers and the impact on call quality even in cases of
very minimal packet loss. Missing history/context, are circuit breakers a
"MUST"?

10.  Signalling Considerations

   RTP Profile:  The name of the RTP profile to be used in session.  The
      RTP/AVP [RFC3551] and RTP/AVPF [RFC4585] profiles can interoperate
      on basic level, as can their secure variants RTP/SAVP [RFC3711]
      and RTP/SAVPF [RFC5124].  The secure variants of the profiles do
      not directly interoperate with the non-secure variants, due to the
      presence of additional header fields for authentication in SRTP
      packets and cryptographic transformation of the payload.  WebRTC
      requires the use of the RTP/SAVPF profile, and this MUST be
      signalled if SDP is used.  Interworking functions might transform
      this into the RTP/SAVP profile for a legacy use case, by
      indicating to the WebRTC end-point that the RTP/SAVPF is used, and
      limiting the usage of the "a=rtcp-fb:" attribute to indicate a
      trr-int value of 4 seconds.

[JS] Another example assuming SDP for signaling. RFC5124 calls out other
possible signaling options as well.

11.  WebRTC API Considerations

[JS] General note - this section as well as Section 12 had sections where
the grammar seemed off a bit. Sometimes whole paragraphs come across as a
bit awkward. Due to time constraints, I will call out the ones that
immediately stood out. I'm happy to help with some text rewrite, but not
until later this week/early next week due to time.

Figure 1 on Page 31 and Figure 2 on Page 32 should be centered.

Specific corrections:

   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.

[JS]

   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 *doesn't force an* end-point to change synchronisation
   base and CNAME in the middle of *the* delivery of any *ongoing* packet
   streams, which would cause media disruption; all MediaStreamTracks
   and their associated SSRCs originating from the same end-point *need*
   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.

-----

      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.

 [JS]

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

-----

   Different CNAMEs normally need to be used for different
   RTCPeerConnection instances, as specified in Section 4.9.  Having two
   communication sessions with the same CNAME could enable tracking of a
   user or device across different services (see Section 4.4.1 of
   [I-D.ietf-rtcweb-security] for details).  A web application can
   request that the CNAMEs used in different RTCPeerConnection within a
   same-orign context to be the same, this allow for synchronization of
   the endpoint's RTP packet streams across the different
   RTCPeerConnections.

   [JS]

   Different CNAMEs normally need to be used for different
   RTCPeerConnection instances, as specified in Section 4.9.  Having two
   communication sessions with the same CNAME could enable tracking of a
   user or device across different services (see Section 4.4.1 of
   [I-D.ietf-rtcweb-security] for details).  A web application can
   request that the CNAMEs used in different RTCPeerConnection
*objects (within a*

*   same-orign context) be* the same, this allow for synchronization of
   the endpoint's RTP packet streams across the different
   RTCPeerConnections.

 -----

      Note: The motivation for supporting reception of multiple CNAMEs
      are to allow for forward compatibility with any future changes....

   [JS]

      Note: The motivation for supporting reception of multiple CNAMEs
      *is* to allow for forward compatibility with any future changes....

-----

      To separate media with different purposes:  An end-point might want
      to send RTP packet streams that have different purposes on
      different RTP sessions, to make it easy for the peer device to
      distinguish them.  For example, some centralised multiparty
      conferencing systems display the active speaker in high
      resolution, but show low resolution "thumbnails" of other
      participants.  Such systems might configure the end-points to send
      simulcast high- and low-resolution versions of their video using
      separate RTP sessions, to simplify the operation of the RTP
      middlebox.  In the WebRTC context this is currently possible to
      accomplished by establishing multiple WebRTC MediaStreamTracks
      that have the same media source in one (or more)
      RTCPeerConnection.

  [JS]

      To separate media with different purposes:  An end-point might want
      to send RTP packet streams that have different purposes on
      different RTP sessions, to make it easy for the peer device to
      distinguish them.  For example, some centralised multiparty
      conferencing systems display the active speaker in high
      resolution, but show low resolution "thumbnails" of other
      participants.  Such systems might configure the end-points to send
      simulcast high- and low-resolution versions of their video using
      separate RTP sessions, to simplify the operation of the RTP
      middlebox.  *In the WebRTC context this is currently possible
      by establishing *multiple WebRTC MediaStreamTracks
      that have the same media source in one (or more)
      RTCPeerConnection.

-----

      Experience with the Mbone tools (experimental RTP-
      based multicast conferencing tools from the late 1990s) has showed
      that RTCP reception quality reports for third parties can usefully
      be presented to the users in a way that helps them understand
      asymmetric network problems, and the approach of using separate
      RTP sessions prevents this.

[JS]

      Experience with the Mbone tools (experimental RTP-
      based multicast conferencing tools from the late 1990s) has showed
      that RTCP reception quality reports for third parties can*
      be presented to users* in a way that helps them understand
      asymmetric network problems, and the approach of using separate
      RTP sessions prevents this.

   -----

      There are various methods of implementation for the middlebox.  If
      implemented as a standard RTP mixer or translator, a single RTP
      session will extend across the middlebox and encompass all the
      end-points in one multi-party session.  Other types of middlebox
      might use separate RTP sessions between each end-point and the
      middlebox.  A common aspect is that these RTP middleboxes can use
      a number of tools to control the media encoding provided by a
      WebRTC end-point.  This includes functions like requesting
      breaking the encoding chain and have the encoder produce a so
      called Intra frame.  Another is limiting the bit-rate of a given
      stream to better suit the mixer view of the multiple down-streams.
      Others are controlling the most suitable frame-rate, picture
      resolution, the trade-off between frame-rate and spatial quality.
      The middlebox gets the significant responsibility to correctly
      perform congestion control, source identification, manage
      synchronisation while providing the application with suitable
      media optimizations.  The middlebox is also has to be a trusted
      node when it comes to security, since it manipulates either the
      RTP header or the media itself (or both) received from one end-
      point, before sending it on towards the end-point(s), thus they
      need to be able to decrypt and then encrypt it before sending it
      out.

[JS]

      There are various methods of implementation for the middlebox.  If
      implemented as a standard RTP mixer or translator, a single RTP
      session will extend across the middlebox and encompass all the
      end-points in one multi-party session.  Other types of *middleboxes*
      might use separate RTP sessions between each end-point and the
      middlebox.  A common aspect is that these RTP middleboxes can use
      a number of tools to control the media encoding provided by a
      WebRTC end-point.  This includes functions like requesting *the
      breaking of the* encoding chain and have the encoder produce a so
      called Intra frame.  Another is limiting the bit-rate of a given
      stream to better suit the mixer view of the multiple down-streams.
      Others are controlling the most suitable frame-rate, picture
      resolution, the trade-off between frame-rate and spatial quality.
      The middlebox *has* the responsibility to correctly
      perform congestion control, source identification, manage
      synchronisation while providing the application with suitable
      media optimizations.  The middlebox also has to be a trusted
      node when it comes to security, since it manipulates either the
      RTP header or the media itself (or both) received from one end-
      point, before sending it on towards the *other *end-point(s), thus they
      need to be able to decrypt and then *re-encrypt the stream*
before sending it
      out.

-----

      For cryptographic verification of the source
      SRTP would require additional security mechanisms, for example
      TESLA for SRTP [RFC4383], that are not part of the base WebRTC
      standards.

[JS NOTES] - This is the first I've seen mention of TESLA and RFC4383 in
regard
to WebRTC security. My gut tells me rather than referencing a particular doc
here, there should be a relevant section of
[draft-ietf-rtcweb-security-arch] sited.

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 9 May 2014 13:21:50 +0200

Hi Jim,

Thanks for your review. I will try to comment on the the issues you
raise and we will look at the paragraphs which you find the
language/grammar a bit strange.

On 2014-05-08 16:49, Jim Spring wrote:
> transport-layer flow ensures that there is occasional traffic sent
> on that port, even if there is no active media traffic.  This can be 
> [draft-ietf-rtcweb-stun-consent-freshness].  It seems a bit odd
> having multiple methods specified.  If we adopt

This text is informative about one of the motivation and properties of
RTP / RTCP multiplexing. The RTCP keep-alive is an automatic effect you
get, one that you can't turn off. I don't see any issues here. Yes,
using consent will further verify and perform keep-alive of the network
path but they are not in any type of conflict.

So the note is unnecessary in the context of a full RTCWEB
implementation. For interop with other systems maybe less so.

> concerns where a legacy client will not support Symmetric RTP/RTCP
> per RFC4961?

The reason is that Symmetric RTP/RTCP has been the dominating
configuration for RTP/RTCP for a decade. You don't work in an NATed
environment unless you do this. Thus, extremely few legacy system is
expected to use symmetric RTP/RTCP.

> Implementations are REQUIRED to support signalled RTP
> synchronisation source (SSRC) identifiers, using the "a=ssrc:" SDP
> attribute defined in Section 4.1 and Section 5 of [RFC5576].
> 
> [JS] This section appears to mandate SDP for signaling, other
> sections use SDP as an example for signaling. Recommend reworking
> this to not require specifics about SDP.

Yes, we will address this. See also Bernard's comments.

> In the absence of a concrete congestion control algorithm, all
> WebRTC implementations MUST implement the RTP circuit breaker
> algorithm that is described in
> [I-D.ietf-avtcore-rtp-circuit-breakers].
> 
> [JS] At IETF 89, my understanding was that there were concerns
> around the use of circuit breakers and the impact on call quality
> even in cases of very minimal packet loss. Missing history/context,
> are circuit breakers a "MUST"?

Circuit breakers has been mandated since the circuit breaker work was
started. The whole intention with circuit breaker was to provide
something simple to implement, but robust that prevents that WebRTC
endpoints (, other RTP applications also) to be a contributing source to
persistent congestion.

Where was the discussion that you refer to above?

> RTP Profile:  The name of the RTP profile to be used in session.
> The RTP/AVP [RFC3551] and RTP/AVPF [RFC4585] profiles can
> interoperate on basic level, as can their secure variants RTP/SAVP
> [RFC3711] and RTP/SAVPF [RFC5124].  The secure variants of the
> profiles do not directly interoperate with the non-secure variants,
> due to the presence of additional header fields for authentication in
> SRTP packets and cryptographic transformation of the payload.
> WebRTC requires the use of the RTP/SAVPF profile, and this MUST be 
> this into the RTP/SAVP profile for a legacy use case, by indicating
> to the WebRTC end-point that the RTP/SAVPF is used, and limiting the
> usage of the "a=rtcp-fb:" attribute to indicate a trr-int value of 4
> seconds.
> 
> [JS] Another example assuming SDP for signaling. RFC5124 calls out
> other possible signaling options as well.

Will address.

> [JS] General note - this section as well as Section 12 had sections 
> where the grammar seemed off a bit. Sometimes whole paragraphs come 
> across as a bit awkward. Due to time constraints, I will call out
> the ones that immediately stood out. I'm happy to help with some
> text rewrite, but not until later this week/early next week due to
> time.

We will look into these, and we happily receive suggestions. But to
avoid double work, please check with us authors directly if we already
have done something. We intended to produce an update of the document
next week prior the interim meeting.

Cheers

Magnus

> all cases, and *doesn't force an* end-point to change
> synchronisation base and CNAME in the middle of *the* delivery of any
> *ongoing* packet streams, which would cause media disruption; all
> MediaStreamTracks and their associated SSRCs originating from the
> same end-point *need* 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.
> 
> -----
> 
> 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.
> 
> [JS]
> 
> that forwards traffic from multiple end-points to only use a single
> CNAME.
> 
> -----
> 
> RTCPeerConnection instances, as specified in Section 4.9.  Having
> two communication sessions with the same CNAME could enable tracking
> of a user or device across different services (see Section 4.4.1 of 
> RTCPeerConnection instances, as specified in Section 4.9.  Having
> two communication sessions with the same CNAME could enable tracking
> of a user or device across different services (see Section 4.4.1 of 
> request that the CNAMEs used in different RTCPeerConnection *objects
> (within a*
> 
> *   same-orign context) be* the same, this allow for synchronization
> of the endpoint's RTP packet streams across the different 
> RTCPeerConnections.
> 
> -----
> 
> Note: The motivation for supporting reception of multiple CNAMEs are
> to allow for forward compatibility with any future changes....
> 
> [JS]
> 
> Note: The motivation for supporting reception of multiple CNAMEs *is*
> to allow for forward compatibility with any future changes....
> 
> 
> -----
> 
> to send RTP packet streams that have different purposes on different
> RTP sessions, to make it easy for the peer device to distinguish
> them.  For example, some centralised multiparty conferencing systems
> display the active speaker in high resolution, but show low
> resolution "thumbnails" of other participants.  Such systems might
> configure the end-points to send simulcast high- and low-resolution
> versions of their video using separate RTP sessions, to simplify the
> operation of the RTP middlebox.  In the WebRTC context this is
> currently possible to accomplished by establishing multiple WebRTC
> MediaStreamTracks that have the same media source in one (or more) 
> RTCPeerConnection.
> 
> [JS]
> 
> to send RTP packet streams that have different purposes on different
> RTP sessions, to make it easy for the peer device to distinguish
> them.  For example, some centralised multiparty conferencing systems
> display the active speaker in high resolution, but show low
> resolution "thumbnails" of other participants.  Such systems might
> configure the end-points to send simulcast high- and low-resolution
> versions of their video using separate RTP sessions, to simplify the
> operation of the RTP middlebox.  *In the WebRTC context this is
> currently possible by establishing *multiple WebRTC
> MediaStreamTracks that have the same media source in one (or more) 
> RTCPeerConnection.
> 
> 
> -----
> 
> Experience with the Mbone tools (experimental RTP- based multicast
> conferencing tools from the late 1990s) has showed that RTCP
> reception quality reports for third parties can usefully be presented
> to the users in a way that helps them understand asymmetric network
> problems, and the approach of using separate RTP sessions prevents
> this.
> 
> [JS]
> 
> Experience with the Mbone tools (experimental RTP- based multicast
> conferencing tools from the late 1990s) has showed that RTCP
> reception quality reports for third parties can* be presented to
> users* in a way that helps them understand asymmetric network
> problems, and the approach of using separate RTP sessions prevents
> this.
> 
> 
> -----
> 
> 
> middlebox.  A common aspect is that these RTP middleboxes can use a
> number of tools to control the media encoding provided by a WebRTC
> end-point.  This includes functions like requesting breaking the
> encoding chain and have the encoder produce a so called Intra frame.
> Another is limiting the bit-rate of a given stream to better suit the
> mixer view of the multiple down-streams. Others are controlling the
> most suitable frame-rate, picture resolution, the trade-off between
> frame-rate and spatial quality. The middlebox gets the significant
> responsibility to correctly perform congestion control, source
> identification, manage synchronisation while providing the
> application with suitable media optimizations.  The middlebox is also
> has to be a trusted node when it comes to security, since it
> manipulates either the RTP header or the media itself (or both)
> received from one end- point, before sending it on towards the
> end-point(s), thus they need to be able to decrypt and then encrypt
> it before sending it out.
> 
> [JS]
> 
> middlebox.  A common aspect is that these RTP middleboxes can use a
> number of tools to control the media encoding provided by a WebRTC
> end-point.  This includes functions like requesting *the breaking of
> the* encoding chain and have the encoder produce a so called Intra
> frame.  Another is limiting the bit-rate of a given stream to better
> suit the mixer view of the multiple down-streams. Others are
> controlling the most suitable frame-rate, picture resolution, the
> trade-off between frame-rate and spatial quality. The middlebox *has*
> the responsibility to correctly perform congestion control, source
> identification, manage synchronisation while providing the
> application with suitable media optimizations.  The middlebox also
> has to be a trusted node when it comes to security, since it
> manipulates either the RTP header or the media itself (or both)
> received from one end- point, before sending it on towards the *other
> *end-point(s), thus they need to be able to decrypt and then
> *re-encrypt the stream* before sending it out.
> 
> -----
> 
> For cryptographic verification of the source SRTP would require
> additional security mechanisms, for example TESLA for SRTP [RFC4383],
> that are not part of the base WebRTC standards.
> 
> [JS NOTES] - This is the first I've seen mention of TESLA and RFC4383
> in regard to WebRTC security. My gut tells me rather than referencing
> a particular doc
> 
> _______________________________________________ rtcweb mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
> 

-- 

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: [email-masked]
----------------------------------------------------------------------