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

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

From: Eric Rescorla <ekr@rtfm.com>
Date: Sat, 23 Nov 2013 13:32:51 -0800
Message-ID: <CABcZeBMMnhnMyY0x6pHC=SKdg-YHDeCya7Tbsah8nnnHjSK0VQ@mail.gmail.com>
To: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Cc: Salvatore Loreto <salvatore.loreto@ericsson.com>, Peter Thatcher <pthatcher@google.com>, Justin Uberti <juberti@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, "mmusic@ietf.org" <mmusic@ietf.org>
On Sat, Nov 23, 2013 at 7:19 AM, Michael Tuexen <
Michael.Tuexen@lurchi.franken.de> wrote:

> On Nov 23, 2013, at 3:51 PM, Salvatore Loreto <
> salvatore.loreto@ericsson.com> wrote:
> >
> > (adding mmusic mailing list, sorry for cross posting but if we want to
> progress the draft
> > within IETF we have to discuss it in the mmusic mailing list)
> >
> > the http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-05
> > still allow to specify the number of streams, even if it is optional
> >
> > if we want to add also max-message-size attribute, also as on optional
> one
> > what about something like this?
> >
> > a=sctpmap:5000 webrtc-datachannel [streams] [max-message-size]
> ... and what is the semantic if max-message-size is not provided? The
> endpoint
> is willing to accept arbitrary large messages?
> I also suggest to rename max-message-size to supported-message-size.
> The semantics is that the end-point is willing to accept messages up to
> supported-message-size. It does not make a statement about messages larger
> than the limit. Calling it max-message-size suggests to me, that messages
> larger than the limit can't be handled...

1. I'm cool with the idea of negotiating this in the SDP.
2. I actually think it would be better to have a max message size, since
otherwise we're back in the indeterminate behavior case.
3. The semantics should be that each side just gets to inform the other
side of their value, not that it's negotiated.

Received on Saturday, 23 November 2013 21:33:59 UTC

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