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 22:48:44 +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: <D06D75AC-0DB2-4DE0-8671-EBA7786C3CBD@lurchi.franken.de>
To: Eric Rescorla <ekr@rtfm.com>
On Nov 24, 2013, at 5:51 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> 
> 
> 
> On Sun, Nov 24, 2013 at 8:47 AM, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:
> 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.
> 
> I would be fine with your proposed name.
OK.
> 
> 
> 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.
> 
> Ordinarily I would agree with you, but there are extant implementations
> which don't signal so I'm thinking of minimizing failures with them.
Obviously, currently no implementation currently uses this. I just want
future implementation to provide a limit and to implement application
level reassembly for valid message size and protection against too large messages.

Maybe we can use appropriate wording to try to enforce that. Than I'm happy.

Best regards
Michael
> 
> -Ekr
> 
> Best regards
> Michael
> >
> > -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 21:49:09 UTC

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