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

[Magnus Westerlund <[e-mail]>]

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:
> 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.

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.

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

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.

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

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

> 
> 
> 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"?

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?

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

Will address.

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

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

> 
> 
> 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.
> 
> 
> 
> _______________________________________________ rtcweb mailing list 
> [e-mail] https://www.ietf.org/mailman/listinfo/rtcweb
> 


-- 

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