- From: Peter Thatcher <pthatcher@google.com>
- Date: Fri, 22 Nov 2013 15:16:34 -0800
- To: Justin Uberti <juberti@google.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <CAJrXDUEEb8yohTXZR5vOM8nu11sP5KOkOy+iaj1_x+N9MXU94A@mail.gmail.com>
Yes, we agreed to forego putting streams in the SDP. I'm sure I got the syntax of the SDP wrong. Yours looks better. 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:17:42 UTC