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

That was my reaction as well.

One issue that would arise if we rejected the extra media descriptions is
that if that's not what the application wanted, there's no easy way to
prevent it. If we decide to reject the extra media descriptions, we'd
probably also want to make the bundle policy settable by setConfiguration,
so an application could temporarily make it more permissive.

On the other hand, if we decide to accept the media descriptions, but the
application *wanted* them rejected, it would be pretty simple for the
application to reject them using the RtpTransceiver API.

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.
>
> --
> Surveillance is pervasive. Go Dark.
>
>