IETF Logo Mail Archive

[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/>

v2.30.2 | Report a Bug | By Email | System Status