Re: [rtcweb] #25: Section 5.1 Conferencing Extensions

[Colin Perkins <[e-mail]>]

On 25 Aug 2013, at 23:54, rtcweb issue tracker <[e-mail]> wrote:
> #25: Section 5.1 Conferencing Extensions
> 
> These
>    central servers can be implemented in a number of ways as discussed
>    in Appendix A, and in the memo on RTP Topologies
>    [I-D.westerlund-avtcore-rtp-topologies-update].
> 
> [BA] Out-of-date reference; should be to draft-ietf-avtcore-rtp-
> topologies-update.

Will fix.

>    o  The use of video switching MCUs makes the use of RTCP for
>       congestion control and quality of service reports problematic(see
>       Section 3.7 of [I-D.westerlund-avtcore-rtp-topologies-update]).
> 
> [BA] In the new document, this is now Section 3.6.2.

Will fix.

>    o  RTP Transport Translators (Topo-Translator) are not of immediate
>       interest to WebRTC, although the main difference compared topoint
>       to point is the possibility of seeing multiple different
>       transport paths in any RTCP feedback.
> 
> [BA] "not of immediate interest" might be interpreted as not satisfying the requirement that "these topologies require no special RTP-layer support in the end-point if the RTP features mandated in this memo are implemented". If a browser can handle an undeclared SSRC then wouldn't an RTP translator also satisfy the requirement?  For example, Section 11 states: "The API also needs to be capable of handling when new SSRCs are received but not previously signalled by signalling in some fashion."

I see no reason why a transport translator couldn't be used in the WebRTC context, so I propose to remove this bullet.

>    These
>    extensions are not necessary for interoperability; an RTP endpoint
>    that does not implement these extensions will work correctly, but
>    might offer poor performance.
> 
> [BA] I'd argue that not implementing the extensions will also affect aspects such as congestion control, which one might argue is necessary to "work correctly".

I suggest that TMMBR sets an envelope within which the congestion control should operate, but shouldn't be required for congestion control to work. The others might be useful in conjunction with a congestion control algorithm, to suggest how a new rate is to be achieved, but also aren't required.


-- 
Colin Perkins
http://csperkins.org/