Re: Question about desired max-bundle behavior with remote offers.

I guess it's not that the endpoints can't communicate at all. But I admit
it feels wrong that negotiation of additional media sections can fail in
one direction and succeed in the other.

Also, I can see the argument for rejecting non-bundled media descriptions
just so we can be consistent with rejecting non-RTCP-muxed descriptions.

So on that note, here's a pull request:
https://github.com/rtcweb-wg/jsep/pull/279

On Mon, Apr 25, 2016 at 1:07 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> Den 18. april 2016 01:12, skrev Eric Rescorla:
> >
> >
> > On Wed, Apr 13, 2016 at 7:12 AM, Harald Alvestrand <harald@alvestrand.no
> > <mailto:harald@alvestrand.no>> wrote:
> >
> >     On 04/13/2016 01:26 AM, Taylor Brandstetter wrote:
> >>     My initial assumption was that the only purpose of the
> >>     "max-bundle" policy was to create "bundle-only" media descriptions
> >>     in an offer.
> >>
> >>     But a question came up recently: What happens if you receive a
> >>     non-BUNDLE offer when the max-bundle policy is configured?
> >>
> >>     Should the PeerConnection:
> >>
> >>      1. Allow this, and negotiate multiple transports?
> >>      2. Reject (port 0) all but one of the media descriptions?
> >>
> >>     An application developer may be surprised if they configure
> >>     max-bundle, but end up non-bundled. But conversely, they may be
> >>     surprised if media descriptions are rejected for no reason other
> >>     than the bundle policy.
> >>
> >     My immediate reaction (on the general principle that "negotation to
> >     less functionality should always work") is that the developer's
> >     setting for max-bundle policy affects offers created by the local PC
> >     only; if the implementation is at all able to accept the remote
> >     side's offer, it should accept it.
> >
> >     I think we still require all implementations to support multiple
> >     transports.
> >
> >
> > I think we should reject this for the same reason that we reject non-mux
> > offers when mux=require. It avoids situations where two endpoints can
> > initially communicate but then cannot if a subsequent negotiation
> > happens in the other direction.
>
> Can you give an example of a negotiation where this would happen?
>
> If we accept the premise that renegotiation can't change the
> "bundle-only" property of existing m-lines, I don't see how we can get
> into trouble.
> That is:
>
> (A doesn't bundle, B has policy max-bundle)
>
> A: Offer X, Y
> B: Answer X, Y (no bundle)
>
> Policy alternative 1, B tries to bundle what it can:
>
> B: Offer X, Y, Z, W; Z and W are bundled, W is marked bundle-only
> A: Answer X, Y, Z; rejects W, since it was marked bundle-only
>
> Communication continues on X, Y and Z
>
> Policy alternative 2, B understands that bundle-only won't succeed
>
> B: Offer, X, Y, Z, W - doesn't bundle, or bundles Z and W with no
> bundle-only
> A: Answer X, Y, Z, W - no bundle
>
> Communication continues on X, Y, Z, W
>
> I don't see the failure scenario that rejecting the initial offer would
> help us avoid.
>
>