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

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
>
> On Mon, Apr 25, 2016 at 1:07 AM, Harald Alvestrand
> <harald@alvestrand.no <mailto: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>
>     > <mailto: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.
>
>


-- 
Surveillance is pervasive. Go Dark.