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

[Bernard Aboba <[e-mail]>]

Comments below.

On Aug 26, 2013, at 23:18, "Magnus Westerlund" <[e-mail]> wrote:
>> Section 5.1 says: 
>> 
>>   These extensions are not necessary for interoperability; an RTP endpoint
>>   that does not implement these extensions will work correctly, but
>>   might offer poor performance. 
> 
> TMMBR has at least usage in two different scenarios for RTCWEB. The
> first is the upstream flow control for conferences being implemented
> with a central node acting as RTP mixer, and thus breaking congestion
> control loops between itself and each participant, thus requiring a flow
> control mechanism for a upstream media source. Implementing sender side
> congestion control TMMBR is required to make the upstream flow control
> function. This is documented in Section 5.1.6
> 
> The second usage is allowing proprietary receiver based congestion
> control to have a method of effecting the media sender. If you don't
> have receiver based congestion control, then you don't use it. But your
> peer may have and send your implementation TMMBR requests. See section 7.
> 
> From a system interoperability point of view I personally see each of
> these making TMMBR required. Combining the two reasons makes it even
> stronger reason to have TMMBR as required functionality. Thus I think
> there are good reasons fulfilling the requirements RFC 2119 lays out to
> mandate TMMBR.

[BA] So why not say something along those lines? The statement in Section 5.1 doesn't seem to apply to TMMBR.