[rtcweb] Data Channel control messages

[Paul Kyzivat <[e-mail]>]

There is a thread going on public-webrtc: WebRTC and backpressure (how 
to stop reading?)

That has gotten to the point where there is an rtcweb issue:

On 3/29/14 1:41 AM, Randell Jesup wrote:

>> No. You could continue to map  the channel messages byte-by-byte
>> on SCTP messages. But you would introduce some control message
>> (also in SCTP DATA chunks) which you would send reliably and
>> put in whatever information is needed. For me this looks pretty simple...
>
> Agreed; we have considerable latitude to define additional control
> messages in DATA chunks, if we decide this is useful.
> If we're careful, it may even be backwards compatible (ignored if not
> supported) without have to negotiate or probe for support.  But we'd
> need to know exactly *why* we'd consider changing things at this late
> date, and for what practical gain, given it would perhaps negatively
> impact the duck-typing between WebSockets and DataChannels and cause
> more delay and slow adoption.

PPID 50, defined in draft-ietf-rtcweb-data-protocol, certainly has the 
potential to be extended with additional control messages. (It has a one 
byte message type field with only two values defined.) That seems the 
obvious place where such messages could be defined.

Even if the control messages aren't to be defined now, it would be good 
to set the stage. For one thing, those control messages ought to be 
usable even for data channels that are established by means other than 
DCEP. Right now PPID 50 is only for DCEP. Also, as Randell implies 
above, it might be a good idea to define the extensibility mechanism - 
e.g., that messages bearing unknown message types be ignored, or that 
they get a specific response indicating that they are not supported.

	Thanks,
	Paul