- From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
- Date: Sun, 24 Nov 2013 17:47:03 +0100
- To: Eric Rescorla <ekr@rtfm.com>
- Cc: Martin Thomson <martin.thomson@gmail.com>, "mmusic@ietf.org" <mmusic@ietf.org>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Peter Thatcher <pthatcher@google.com>
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. 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. 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:47:29 UTC