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 On Mon, Nov 25, 2013 at 8:13 AM, Peter Thatcher <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> 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 >> > wrote: >> >>> On 23 November 2013 13:32, Eric Rescorla <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. >>> >> >> >
Received on Tuesday, 26 November 2013 00:13:51 UTC