W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2016

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

From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 17 Apr 2016 16:12:17 -0700
Message-ID: <CABcZeBOXzZTFAoKf+YN7VxOGNVr1Cd3TY_uWsKjzRkf3_xC5Xg@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Wed, Apr 13, 2016 at 7:12 AM, Harald Alvestrand <harald@alvestrand.no>

> 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.


> --
> Surveillance is pervasive. Go Dark.
Received on Sunday, 17 April 2016 23:13:24 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:48 UTC