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

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

From: Harald Alvestrand <harald@alvestrand.no>
Date: Mon, 25 Apr 2016 10:07:59 +0200
To: Eric Rescorla <ekr@rtfm.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <571DD05F.9090809@alvestrand.no>
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>> 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
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.
Received on Monday, 25 April 2016 08:08:32 UTC

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