[rtcweb] #25: Section 5.1 Conferencing Extensions
"rtcweb issue tracker" <trac+rtcweb@trac.tools.ietf.org> Sun, 25 August 2013 22:54 UTC
Return-Path: <trac+rtcweb@trac.tools.ietf.org>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8029811E8104 for <rtcweb@ietfa.amsl.com>; Sun, 25 Aug 2013 15:54:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yOeaiSzBorT2 for <rtcweb@ietfa.amsl.com>; Sun, 25 Aug 2013 15:54:03 -0700 (PDT)
Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D268211E8103 for <rtcweb@ietf.org>; Sun, 25 Aug 2013 15:54:02 -0700 (PDT)
Received: from localhost ([127.0.0.1]:33638 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from <trac+rtcweb@trac.tools.ietf.org>) id 1VDjC4-0007gS-8n; Mon, 26 Aug 2013 00:54:00 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: rtcweb issue tracker <trac+rtcweb@trac.tools.ietf.org>
X-Trac-Version: 0.12.3
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.3, by Edgewall Software
To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com
X-Trac-Project: rtcweb
Date: Sun, 25 Aug 2013 22:54:00 -0000
X-URL: http://tools.ietf.org/rtcweb/
X-Trac-Ticket-URL: http://tools.ietf.org/wg/rtcweb/trac/ticket/25
Message-ID: <066.c4782f9f452cb0c5049d3712dcfdcda1@trac.tools.ietf.org>
X-Trac-Ticket-ID: 25
X-SA-Exim-Connect-IP: 127.0.0.1
X-SA-Exim-Rcpt-To: draft-ietf-rtcweb-rtp-usage@tools.ietf.org, bernard_aboba@hotmail.com, rtcweb@ietf.org
X-SA-Exim-Mail-From: trac+rtcweb@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false
Resent-To: csp@csperkins.org, jorg.ott@aalto.fi, magnus.westerlund@ericsson.com
Resent-Message-Id: <20130825225402.D268211E8103@ietfa.amsl.com>
Resent-Date: Sun, 25 Aug 2013 15:54:02 -0700
Resent-From: trac+rtcweb@trac.tools.ietf.org
Cc: rtcweb@ietf.org
Subject: [rtcweb] #25: Section 5.1 Conferencing Extensions
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 25 Aug 2013 22:54:03 -0000
#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. 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. 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." 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". -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-rtcweb-rtp- bernard_aboba@hotmail.com | usage@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: milestone1 Component: rtp-usage | Version: 1.0 Severity: Active WG Document | Keywords: -------------------------------------+------------------------------------- Ticket URL: <http://tools.ietf.org/wg/rtcweb/trac/ticket/25> rtcweb <http://tools.ietf.org/rtcweb/>
- [rtcweb] #25: Section 5.1 Conferencing Extensions rtcweb issue tracker
- Re: [rtcweb] #25: Section 5.1 Conferencing Extens… Colin Perkins
- Re: [rtcweb] #25: Section 5.1 Conferencing Extens… Bernard Aboba
- Re: [rtcweb] #25: Section 5.1 Conferencing Extens… Magnus Westerlund
- Re: [rtcweb] #25: Section 5.1 Conferencing Extens… Bernard Aboba
- Re: [rtcweb] #25: Section 5.1 Conferencing Extens… Colin Perkins
- Re: [rtcweb] #25: Section 5.1 Conferencing Extens… Bernard Aboba
- Re: [rtcweb] #25: Section 5.1 Conferencing Extens… rtcweb issue tracker