Subject: [rtcweb] draft-ietf-rtcweb-jsep-08

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Nov 2014 16:52:27 -0500

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.

However section 5.2.1 says:

    Once all m= sections have been generated, a session-level "a=group"
    attribute MUST be added as specified in [RFC5888].  This attribute
    MUST have semantics "BUNDLE", and MUST include the mid identifiers of
    each m= section.  The effect of this is that the browser offers all
    m= sections as one BUNDLE group.  However, whether the m= sections
    are bundle-only or not depends on the BUNDLE policy.

This doesn't deal with bundle policy - this rule seems to apply only to 
max-compat policy.

Section 7.1 says that both Alice and Bob are using the "balanced" 
policy, which should lead to separate bundles for audio and video, but 
the example shows a single bundle - consistent with a "max-bundle" 
policy. There are no examples that show more than one bundle group.

	Thanks,
	Paul

---

From: Justin Uberti <[email-masked]>
Date: Tue, 4 Nov 2014 16:58:20 -0800

On Tue, Nov 4, 2014 at 1:52 PM, Paul Kyzivat <[email-masked]> wrote:

> 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.

> Section 7.1 says that both Alice and Bob are using the "balanced" policy,
> which should lead to separate bundles for audio and video, but the example
> shows a single bundle - consistent with a "max-bundle" policy. There are no
> examples that show more than one bundle group.
>
>
Right. JSEP endpoints always try to BUNDLE (and rtcp-mux). Legacy endpoints
can of course reject this.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Nov 2014 21:28:14 -0500

On 11/4/14 7:58 PM, Justin Uberti wrote:
>
>
> On Tue, Nov 4, 2014 at 1:52 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     *separate* bundle groups for audio and video, and that the SCTP
>     m-line will not be bundled.
>
>

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

---

From: Justin Uberti <[email-masked]>
Date: Tue, 4 Nov 2014 21:06:34 -0800

That's good feedback. I'll file an issue to improve this text.

On Tue, Nov 4, 2014 at 6:28 PM, Paul Kyzivat <[email-masked]> wrote:

> 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:
>