Re: [rtcweb] Amount of streams supported for data channels

[Taylor Brandstetter <[e-mail]>]

>
> FWIW, I don't believe any browser would count as an implementation with
> limited resources.
>

If so, it could say "browsers MUST attempt to negotiate 65535 streams, but
be prepared for negotiating fewer, e.g. when communicating with a
non-WebRTC endpoint with limited resources"?

Or could just add an explanation for the SHOULD; I don't have strong
opinions about this.

On Thu, Apr 12, 2018 at 4:22 PM, Lennart Grahl <[e-mail]>
wrote:

> On 11.04.2018 23:24, Michael Tuexen wrote:
> >> On 11. Apr 2018, at 22:29, Taylor Brandstetter <[e-mail]>
> wrote:
> >>
> >> I listened to the recording, and this was the main point being
> discussed, but the conclusion seemed to be "efficient implementations
> shouldn't use much (or any) memory for unused streams; we shouldn't make
> sacrifices in the protocol just to reduce implementation complexity."
> > You can implement it in a way to not use much memory for unused streams.
> However, you need some memory
> > for stream you use. That is why I referred to the number of streams used
> in parallel.
>
> So, implementations with limited resources may still choose to negotiate
> less than that to prevent running into exhausting their resources. That
> makes sense to me, so I would withdraw the request to make it a MUST.
> Could this explanation be added as a comment to the draft, so it's clear
> why it's not a MUST?
>
> FWIW, I don't believe any browser would count as an implementation with
> limited resources. But I get that there are other implementations
> outside of the browser and it may make sense there to limit the amount
> of streams. And since we can interoperate with them, we need to handle
> it some way or another in the W3C WebRTC spec.
>
> Taylor, any objections?
>
> Cheers
> Lennart
>