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

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

From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
Date: Sat, 23 Nov 2013 00:31:55 +0100
Cc: Justin Uberti <juberti@google.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-Id: <747D18C0-5479-4DE5-9E83-A73CC3E22E0A@lurchi.franken.de>
To: Peter Thatcher <pthatcher@google.com>
On Nov 23, 2013, at 12:16 AM, Peter Thatcher <pthatcher@google.com> wrote:

> Yes, we agreed to forego putting streams in the SDP.  I'm sure I got the syntax of the SDP wrong.  Yours looks better.  
and the semantic is: I'm willing to accept SCTP user messages of at least 1000000 bytes, right?

It makes sense to put it into the SDP...

Best regards
Michael
> 
> 
> On Fri, Nov 22, 2013 at 2:51 PM, Justin Uberti <juberti@google.com> wrote:
> I like the idea, but I'm not sure the syntax in http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp-04 can express this.
> 
> The current a=sctpmap is
> 
> a=sctpmap:5000 webrtc-datachannel [streams]
> 
> although IIRC we agreed to forego the whole streams negotiation thing.
> 
> So we would need something like a=fmtp:5000 max-message-size=1000000.
> 
> 
> On Fri, Nov 22, 2013 at 2:28 PM, Peter Thatcher <pthatcher@google.com> wrote:
> This is probably going to sound strange coming from me, but I think it might be a better idea to put the SCTP max message size in the SDP.
> 
> I'm still OK with having an in-band message (as we discussed during TPAC) to swap the SCTP max message between endpoints, but I was thinking about it a little more and realized that it does involve some extra edge cases and a bit of possible latency.  It would be nice if we could do a handshake earlier on.... and then I realized we can because we can just put it in the SDP where we already do a handshake well ahead of time.
> 
> Something like:
> 
> a=sctpmap:5000 max-message-size 1000000
> 
> 
> Obviously I'm not a big fan of stuffing lots of stuff into SDP, but I think this is very minimal and is a more simple solution.
> 
> 
> 
> 
> What do you think?  
> 
> 
Received on Friday, 22 November 2013 23:32:21 UTC

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