Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

[Martin Thomson <[e-mail]>]

On 29 April 2013 14:56, Randell Jesup <[e-mail]> wrote:
> The number of streams in the SDP is the initial number of streams (with a
> suggested default of 16).  That's entirely an optimization to avoid the
> application needing to immediately need to renegotiate a larger number, or
> to have a large number of never-used channels if the default was set way too
> high.
>
> If streams are needed past the number currently allocated, an increase will
> be requested and the createDataChannel queued.  (Note: this applies to
> pre-negotiated channels using streams past the currently allocated number as
> well).

Actually, I'm not sure where this has been discussed, but there is an
assumption of SDP use that doesn't fit my model for SDP.

That is, when I use SDP, I describe what I can do, i.e., my limits.
That establishes an operating envelope within which I can change
behavior.  When I negotiate 16 streams, I had assumed that this would
be a limit and that I might negotiate fewer than that initially and be
open to attempts to open more.  That is, up to but not exceeding 16.
If this is something that doesn't make sense to negotiate in SDP, then
let's not do that.

As another issue, have we ever discussed the SCTP profile that we are
expected to implement?  Are we expected to have and use every SCTP
feature ever defined or just a specific subset?  Where is the right
place to capture that?  Does this have ramifications for SDP, or shall
we let the SCTP extension mechanisms handle the feature negotiation?