W3C home > Mailing lists > Public > public-webrtc@w3.org > November 2013

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

From: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Wed, 27 Nov 2013 07:13:24 +0000
To: Justin Uberti <juberti@google.com>, Harald Alvestrand <harald@alvestrand.no>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C55D2BC@ESESSMB209.ericsson.se>
Hi,

max-size is what I meant :)

Regards,

Christer

From: Justin Uberti [mailto:juberti@google.com]
Sent: 27. marraskuuta 2013 2:19
To: Harald Alvestrand
Cc: public-webrtc@w3.org
Subject: 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<mailto: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<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.

Received on Wednesday, 27 November 2013 07:13:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:36 UTC