IETF Logo Mail Archive

Re: [rtcweb] To multiplex or not!

Bernard Aboba <bernard_aboba@hotmail.com> Wed, 20 July 2011 15:53 UTC

Return-Path: <bernard_aboba@hotmail.com>
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 A93A321F89C1 for <rtcweb@ietfa.amsl.com>; Wed, 20 Jul 2011 08:53:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.544
X-Spam-Level:
X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBGjklWHrcjn for <rtcweb@ietfa.amsl.com>; Wed, 20 Jul 2011 08:53:20 -0700 (PDT)
Received: from blu0-omc3-s1.blu0.hotmail.com (blu0-omc3-s1.blu0.hotmail.com [65.55.116.76]) by ietfa.amsl.com (Postfix) with ESMTP id B46F021F86B9 for <rtcweb@ietf.org>; Wed, 20 Jul 2011 08:53:20 -0700 (PDT)
Received: from BLU152-W34 ([65.55.116.74]) by blu0-omc3-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Jul 2011 08:53:20 -0700
Message-ID: <BLU152-W3416696FA1695E5F03C0D2934C0@phx.gbl>
Content-Type: multipart/alternative; boundary="_0e6491f5-f097-4c25-a02d-2326213cd974_"
X-Originating-IP: [98.203.198.61]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: john.elwell@siemens-enterprise.com, Magnus Westerlund <magnus.westerlund@ericsson.com>, rtcweb@ietf.org
Date: Wed, 20 Jul 2011 08:53:19 -0700
Importance: Normal
In-Reply-To: <A444A0F8084434499206E78C106220CA08F1C9EC9F@MCHP058A.global-ad.net>
References: <4E259484.20509@ericsson.com>, <A444A0F8084434499206E78C106220CA08F1C9EC9F@MCHP058A.global-ad.net>
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Jul 2011 15:53:20.0260 (UTC) FILETIME=[25D5C440:01CC46F5]
Subject: Re: [rtcweb] To multiplex or not!
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Wed, 20 Jul 2011 15:53:21 -0000


> > c) SHOULD be multiplexed into a single transport flow, but the RTCWEB
> > peer MUST be able to send them as individual flows.
> [JRE] As soon as we start talking about what an RTCWEB peer MUST support, the question arises whether this applies to the browser, the script or both. For example, a browser might implement each PeerConnection object over separate transports, but if the script chooses to use a single PeerConnection object for both audio and video it might not be interoperable with a peer that doesn't support multiplexing.
> 
> So whilst I agree that picking something along the lines of c) might be possible, we would need to define more precisely what we mean before coming to such an agreement.

[BA] .MUST support sending as individual flows makes sense to me, but making normative statements about multiplexing onto a single transport doesn't.   If both sides support multiplexing into a single transport flow, then it can be negotiated and used.

v2.23.0 | Report a Bug | By Email