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: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Date: Sun, 24 Nov 2013 17:47:03 +0100
Cc: Martin Thomson <martin.thomson@gmail.com>, "mmusic@ietf.org" <mmusic@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Peter Thatcher <pthatcher@google.com>
Message-Id: <F4AEEBC0-49ED-4DB6-84B1-E4542D9E3049@lurchi.franken.de>
To: Eric Rescorla <ekr@rtfm.com>
On Nov 24, 2013, at 5:15 PM, 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'
I agree with the semantic, but I think 'supported-message-size' describes
better what you describe above. It is not the maximum, since it is not specified
what happens with larger messages. Don't get me wrong: I like you semantic,
just find the name a bit misleading.

Why not remove your second point? If the sender wants to limit the size,
it will signal it in SDP, if it has no limit, it doesn't signal it.

Best regards
> -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 Sunday, 24 November 2013 16:47:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:51 UTC