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

On 11/26/2013 10:02 PM, Christer Holmberg wrote:
> Hi,
>
> RFC 4975 (MSRP) defines a max-recv attribute (value given in octets).
> Eventhough defined for MSRP, the semantics in general seem to match,
> so maybe we could take a look at that?

max-size? (I looked for "max" in RFC 4975, and that was the one I found).

>
> I think we should try to avoid, if possible, defining different
> attributes, indicating the same thing, based on the protocol.

That makes sense to me.

It is also defined as a separate a= attribute, not folded into a=fmtp or
the a=sctpmap line. This removes some flexibility (can't have different
values for different a=sctpmap lines), but it seems to me likely that
much of the time, this value will be the same for all a=sctpmap lines
anyway, being given more by stack implementation methodologies than by
higher-level protocol usages.

>
> Regards,
>
> Christer
> *From:* Justin Uberti <mailto:juberti@google.com>
> *Sent:* ‎Tuesday‎, ‎November‎ ‎26‎, ‎2013 ‎7‎:‎03‎ ‎PM
> *To:* 'Harald Alvestrand' <mailto:harald@alvestrand.no>
> *Cc:* public-webrtc@w3.org <mailto:public-webrtc@w3.org>
>
> RFC 4566 doesn't seem to prohibit it, but there could be other
> precedent that I am missing.
>
>   a=fmtp:<format> <format specific parameters>
>
>          This attribute allows parameters that are specific to a
>          particular format to be conveyed in a way that SDP does not
>          have to understand them.  The format must be one of the formats
>          specified for the media.  Format-specific parameters may be any
>          set of parameters required to be conveyed by SDP and given
>          unchanged to the media tool that will use this format.  At most
>          one instance of this attribute is allowed for each format.
>
>          It is a media-level attribute, and it is not dependent on
>          charset.
>
>
> On Tue, Nov 26, 2013 at 1:03 AM, Harald Alvestrand
> <harald@alvestrand.no <mailto:harald@alvestrand.no>> wrote:
>
>     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.
>
>
>
>
>
>


-- 
Surveillance is pervasive. Go Dark.