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

On Tue, Nov 26, 2013 at 1:50 PM, Harald Alvestrand <harald@alvestrand.no>wrote:

>  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.
>

I think there are benefits in using fmtp as a more general mechanism for
indicating attributes for the SCTP association (so that we don't have to
rehash this the next time we need to signal some parameter), but I would be
fine with a=max-size as well.

>
>
>
>  Regards,
>
>  Christer
>  *From:* Justin Uberti <juberti@google.com>
> *Sent:* ‎Tuesday‎, ‎November‎ ‎26‎, ‎2013 ‎7‎:‎03‎ ‎PM
> *To:* 'Harald Alvestrand' <harald@alvestrand.no>
> *Cc:* 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>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>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.
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
> --
> Surveillance is pervasive. Go Dark.
>
>