Re: [rtcweb] draft-ietf-rtcweb-jsep-08
Justin Uberti <juberti@google.com> Wed, 05 November 2014 05:06 UTC
Return-Path: <juberti@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D36B1A87BB for <rtcweb@ietfa.amsl.com>; Tue, 4 Nov 2014 21:06:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.972
X-Spam-Level:
X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.594, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NXI0UIUy1LNv for <rtcweb@ietfa.amsl.com>; Tue, 4 Nov 2014 21:06:56 -0800 (PST)
Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 156811A1BCC for <rtcweb@ietf.org>; Tue, 4 Nov 2014 21:06:55 -0800 (PST)
Received: by mail-ob0-f180.google.com with SMTP id wp4so2387obc.25 for <rtcweb@ietf.org>; Tue, 04 Nov 2014 21:06:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bW+AzG7MIkLbbZcqmi5TIGA7gBORlr1oZsYgyGy6HHc=; b=MtJcs3Qx3cESKBFCGnHw7eHvBmhaj3hrLVyfZZVfx9NGDv+IoOZ9QL6y3WwuOE0TeN TzPix+t7MbpvHTMgUUIVeUO2V+kMFpaTysLAxeirnFhOLteOvg8RToLlu3ICwJPExr7f EwU7Sla47sEphhZruPCCiDUuS0OuA35fIgyLRFstyTLQ18J7gc1L7tLzhPJD2DPUyLbE SoJE5UhioUqNTOcYF2m9D3Vu7lbELPWRx1XV26RBsvhVOqTDKK6VcDWF2VCznUa4jkeJ piR1sRKzhimjmZYe/BWusXmw2W2l5auBfnr8c/t7aFCl05PduKGHOUy36GLffbJjFovc HL6w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=bW+AzG7MIkLbbZcqmi5TIGA7gBORlr1oZsYgyGy6HHc=; b=Sky14RrNGnwPWxE5D1wXiv/WGMLklMeVMcgQ0IjOUExwzVV8dvx0z+VxA/IowmQeQp R9mANNnRNnzZv+4GIOsIU3ij7QsgBjYF1zyuAFumv7rcxsf73kX5GWvnPxWoL2afcGsW //pz/pqijvvZ7A7H9pMfI3WjjlYJPHDNlwvx+4J5Ft5A5fKwnIjvPKYV7qx4BMS8B0My 4+V6nueGLX+Cd32wnFTiuRry7ByIUQRK+aj821ItdYy8eBTodxrLLjA2wH0/wuG3vNe5 GglFoZsKKyT+kosPzcVnAZy0POpuzbsWFn3iiuDhKMifuTZKyC2RHZypYE/2eOsBtTEz zT0g==
X-Gm-Message-State: ALoCoQkKBN6rPz1oO+QTktph51r/8Oad7oLSxopHj3vgdAXTysyn9Tix1cf0QhSEXIMiZCJHRvOJ
X-Received: by 10.60.74.169 with SMTP id u9mr6177800oev.50.1415164014801; Tue, 04 Nov 2014 21:06:54 -0800 (PST)
MIME-Version: 1.0
Received: by 10.182.248.170 with HTTP; Tue, 4 Nov 2014 21:06:34 -0800 (PST)
In-Reply-To: <54598B3E.3040207@alum.mit.edu>
References: <54594A9B.9090703@alum.mit.edu> <CAOJ7v-3zgw1BByRm+AY74_AfD1DbiTKoR2YJ_7ojotY5D8XjHw@mail.gmail.com> <54598B3E.3040207@alum.mit.edu>
From: Justin Uberti <juberti@google.com>
Date: Tue, 04 Nov 2014 21:06:34 -0800
Message-ID: <CAOJ7v-1hvo8-Eio+gON0spAWs6JRmP3nZ6gMUKm07XnM_0nkyQ@mail.gmail.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
Content-Type: multipart/alternative; boundary="001a1135ef1c66e3370507158c90"
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eEkqYjF6XRmZvAp9tQVCmdVhEgA
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-08
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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, 05 Nov 2014 05:07:00 -0000
That's good feedback. I'll file an issue to improve this text. On Tue, Nov 4, 2014 at 6:28 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote: > On 11/4/14 7:58 PM, Justin Uberti wrote: > >> >> >> On Tue, Nov 4, 2014 at 1:52 PM, Paul Kyzivat <pkyzivat@alum.mit.edu >> <mailto:pkyzivat@alum.mit.edu>> wrote: >> >> I have a few related comments on jsep-08: >> >> Section 4.1.1 defines the BUNDLE policy values. It certainly appears >> that when you are using the default "balanced" policy there will be >> *separate* bundle groups for audio and video, and that the SCTP >> m-line will not be bundled. >> >> >> This is not correct. Rather, the m= lines for these groups will not be >> marked as a=bundle-only. >> > > Well, it is your draft, so you should know what you intended for it to > say. But I didn't get that from the words: > > balanced: The application will BUNDLE all media streams *of the same > type* together. That is, if there are multiple audio and multiple > video MediaStreamTracks attached to a PeerConnection, all but the > first audio and video tracks will be marked as bundle-only, and > candidates will only be gathered for N media streams, where N is > the number of distinct media types. When talking to a non-BUNDLE- > aware endpoint, only the non-bundle-only streams will be > negotiated. This policy balances desire to multiplex with the > need to ensure basic audio and video still works in legacy cases. > Data channels will be in a separate bundle group. > > max-bundle: The application will BUNDLE *all of its media streams, > including data channels, on a single transport*. All streams other > than the first will be marked as bundle-only. This policy aims to > minimize candidate gathering and maximize multiplexing, at the > cost of less compatibility with legacy endpoints. > > The presence of *all media streams of the same type* and *all of its media > streams* suggests that those are key distinctions in those two definitions. > If that wasn't the intent, then I suggest revising the above words to be > more in line with your intent. Perhaps: > > balanced: The application will BUNDLE all media streams > together. If there are multiple MediaStreamTracks attached to a > PeerConnection, candidates will be gathered for the first of > each distinct media type, and the others will be marked as > bundle-only. When talking to a non-BUNDLE-aware endpoint, only > the non-bundle-only streams will be negotiated. This policy > balances desire to multiplex with the need to ensure basic audio > and video still works in legacy cases. Data channels will be in a > separate bundle group. > > Thanks, > Paul >
- [rtcweb] draft-ietf-rtcweb-jsep-08 Paul Kyzivat
- Re: [rtcweb] draft-ietf-rtcweb-jsep-08 Justin Uberti
- Re: [rtcweb] draft-ietf-rtcweb-jsep-08 Paul Kyzivat
- Re: [rtcweb] draft-ietf-rtcweb-jsep-08 Justin Uberti