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. 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. -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 16:52:43 UTC