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

Colin Perkins <> Mon, 26 August 2013 15:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1746611E81A2 for <>; Mon, 26 Aug 2013 08:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dj-L6i7ppyJ5 for <>; Mon, 26 Aug 2013 08:30:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B47DF11E8193 for <>; Mon, 26 Aug 2013 08:30:55 -0700 (PDT)
Received: from [] (port=54788 by with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <>) id 1VDykj-0000Iq-SI; Mon, 26 Aug 2013 16:30:51 +0100
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Mon, 26 Aug 2013 16:30:50 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: rtcweb issue tracker <>
X-Mailer: Apple Mail (2.1508)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Subject: Re: [rtcweb] #25: Section 5.1 Conferencing Extensions
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Aug 2013 15:31:01 -0000

On 25 Aug 2013, at 23:54, rtcweb issue tracker <> 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