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
>