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

On Wed, Apr 13, 2016 at 7:12 AM, Harald Alvestrand <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.

-Ekr



>
>
> --
> Surveillance is pervasive. Go Dark.
>
>