Re: [MMUSIC] Should we put the SCTP max message size in the SDP?

On 11/26/2013 01:12 AM, Justin Uberti wrote:
> I agree with Eric's suggestions, including '0' as a special case.
>
> Regarding naming, I kind of prefer "max-", as there is ample precedent 
> for this, e.g. maxptime, maxplaybackrate in 
> http://tools.ietf.org/html/draft-spittka-payload-rtp-opus-03. In fact, 
> for optimal consistency I would argue for |maxmsgsize|.
>
> Regarding how the parameter is specified, I beg you not to use 
> positional arguments, and use fmtp named arguments instead, e.g.
> a=sctpmap:5000 webrtc-datachannel
> a=fmtp:5000 maxmsgsize=65536

Does a=fmtp bind to arbitrary identifiers? I thought it only bound to 
payload types...

>
>
> On Mon, Nov 25, 2013 at 8:13 AM, Peter Thatcher <pthatcher@google.com 
> <mailto:pthatcher@google.com>> wrote:
>
>     Your proposal all sounds good to me.  I don't feel strongly one
>     way or the other about "max-" vs. "supported-".
>
>
>     On Sun, Nov 24, 2013 at 8:15 AM, Eric Rescorla <ekr@rtfm.com
>     <mailto:ekr@rtfm.com>> wrote:
>
>         For concreteness, here's what I suggest.
>
>         - An SDP attribute which indicates the maximum message size that
>           the endpoint is willing to accept. The other side should
>         assume that
>           any larger message will be rejected, though there is no
>         requirement
>           that it do so (just as there is no requirement to behave in any
>           particular way if an unadvertised RTP PT is received).
>
>         - If the attribute is not present, the assumption is that
>         there is some
>           sensible (small) default that matches the behavior of existing
>           browsers. 64k?
>
>         - An attribute value of '0' means I will do my best with
>         whatever you
>           send me, subject to memory capacity, etc.
>
>         - Proposed name: 'max-message-size'
>
>         -Ekr
>
>
>
>         On Sat, Nov 23, 2013 at 2:54 PM, Martin Thomson
>         <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>>
>         wrote:
>
>             On 23 November 2013 13:32, Eric Rescorla <ekr@rtfm.com
>             <mailto:ekr@rtfm.com>> wrote:
>             > 3. The semantics should be that each side just gets to
>             inform the other
>             > side of their value, not that it's negotiated.
>
>             This is especially important.  "negotiation" here makes
>             zero sense.
>
>
>
>