Return-Path: 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 ; 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 ; 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 ; Tue, 4 Nov 2014 21:06:55 -0800 (PST) Received: by mail-ob0-f180.google.com with SMTP id wp4so2387obc.25 for ; 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> <54598B3E.3040207@alum.mit.edu> From: Justin Uberti Date: Tue, 4 Nov 2014 21:06:34 -0800 Message-ID: To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a1135ef1c66e3370507158c90 Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/eEkqYjF6XRmZvAp9tQVCmdVhEgA Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Nov 2014 05:07:00 -0000 --001a1135ef1c66e3370507158c90 Content-Type: text/plain; charset=UTF-8 That's good feedback. I'll file an issue to improve this text. On Tue, Nov 4, 2014 at 6:28 PM, Paul Kyzivat wrote: > On 11/4/14 7:58 PM, Justin Uberti wrote: > >> >> >> On Tue, Nov 4, 2014 at 1:52 PM, Paul Kyzivat > > 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 > --001a1135ef1c66e3370507158c90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That's good feedback. I'll file an issue to improv= e 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:pkyzi= vat@alum.mit.edu>> wrote:

=C2=A0 =C2=A0 I have a few related comments on jsep-08:

=C2=A0 =C2=A0 Section 4.1.1 defines the BUNDLE policy values. It certainly = appears
=C2=A0 =C2=A0 that when you are using the default "balanced" poli= cy there will be
=C2=A0 =C2=A0 *separate* bundle groups for audio and video, and that the SC= TP
=C2=A0 =C2=A0 m-line will not be bundled.


This is not correct. Rather, the m=3D lines for these groups will not be marked as a=3Dbundle-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:

=C2=A0 =C2=A0balanced:=C2=A0 The application will BUNDLE all media streams = *of the same
=C2=A0 =C2=A0 =C2=A0 type* together.=C2=A0 That is, if there are multiple a= udio and multiple
=C2=A0 =C2=A0 =C2=A0 video MediaStreamTracks attached to a PeerConnection, = all but the
=C2=A0 =C2=A0 =C2=A0 first audio and video tracks will be marked as bundle-= only, and
=C2=A0 =C2=A0 =C2=A0 candidates will only be gathered for N media streams, = where N is
=C2=A0 =C2=A0 =C2=A0 the number of distinct media types.=C2=A0 When talking= to a non-BUNDLE-
=C2=A0 =C2=A0 =C2=A0 aware endpoint, only the non-bundle-only streams will = be
=C2=A0 =C2=A0 =C2=A0 negotiated.=C2=A0 This policy balances desire to multi= plex with the
=C2=A0 =C2=A0 =C2=A0 need to ensure basic audio and video still works in le= gacy cases.
=C2=A0 =C2=A0 =C2=A0 Data channels will be in a separate bundle group.

=C2=A0 =C2=A0max-bundle:=C2=A0 The application will BUNDLE *all of its medi= a streams,
=C2=A0 =C2=A0 =C2=A0 including data channels, on a single transport*. All s= treams other
=C2=A0 =C2=A0 =C2=A0 than the first will be marked as bundle-only.=C2=A0 Th= is policy aims to
=C2=A0 =C2=A0 =C2=A0 minimize candidate gathering and maximize multiplexing= , at the
=C2=A0 =C2=A0 =C2=A0 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:

=C2=A0 =C2=A0balanced:=C2=A0 The application will BUNDLE all media streams<= br> =C2=A0 =C2=A0 =C2=A0 together. If there are multiple MediaStreamTracks atta= ched to a
=C2=A0 =C2=A0 =C2=A0 PeerConnection, candidates will be gathered for the fi= rst of
=C2=A0 =C2=A0 =C2=A0 each distinct media type, and the others will be marke= d as
=C2=A0 =C2=A0 =C2=A0 bundle-only. When talking to a non-BUNDLE-aware endpoi= nt, only
=C2=A0 =C2=A0 =C2=A0 the non-bundle-only streams will be negotiated.=C2=A0 = This policy
=C2=A0 =C2=A0 =C2=A0 balances desire to multiplex with the need to ensure b= asic audio
=C2=A0 =C2=A0 =C2=A0 and video still works in legacy cases. Data channels w= ill be in a
=C2=A0 =C2=A0 =C2=A0 separate bundle group.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul

--001a1135ef1c66e3370507158c90--