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

On Nov 23, 2013, at 10:32 PM, Eric Rescorla <ekr@rtfm.com> wrote:

> 
> 
> 
> 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.
The semantic Peter suggested was:
You can handle messages up to the limit provided in the SDP. What happens
with larger messages is unspecified.
For this semantic I suggest the name supported-message-size.

If, which is not suggested by Peter as far as I understand, the semantic is
You can handle messages up to the limit provided in the SDP. If you send
a larger message, I can't handle it.
For this semantic max-message-size would be appropriate.

No matter which semantic you choose, as a peer I would not send a message
larger than the limit since in the first case I don't know if it can be
handled, in the second case I'm sure.
> 3. The semantics should be that each side just gets to inform the other
> side of their value, not that it's negotiated.
Sure.

Best regards
Michael
> 
> -Ekr
> 
> 

Received on Saturday, 23 November 2013 22:53:25 UTC