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

Well, in the example above, if A generates the subsequent offer, W isn't
rejected. But if B generates the subsequent offer (using policy alternative
1), it *is* rejected.

One conclusion is "then don't use policy alternative 1". But this also
applies to the initial offer/answer. If A offers X and Y, both are
negotiated. If B offers them, only X is negotiated.

On Wed, May 11, 2016 at 12:42 PM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> On 05/11/2016 07:17 PM, Taylor Brandstetter wrote:
>
> 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.
>
>
> I must admit that I still want an answer to my previous question:
>
> What is the scenario where negotiation of additional media sections can
> fail in one direction and succeed in the other (and that's not what the
> initiator of the negotiation wanted)?
>
> I just don't see it.
>
>
>
> So on that note, here's a pull request:
> <https://github.com/rtcweb-wg/jsep/pull/279>
> 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>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.
>>
>>
>
>
> --
> Surveillance is pervasive. Go Dark.
>
>