Re: [rtcweb] Sending of zero-length messages over data channels

["Makaraju, Maridi Raju (Raju)" <[e-mail]>]

> > In the existing data channel protocol, it's not possible to send zero-
> length messages, because SCTP prohibits it.
> >
> > While this may seem to be an academic point, it does represent a
> divergence from WebSockets, and this difference could be meaningful to
> applications who use empty messages for keepalives. Or maybe the Yo app.
> >
> > Since we can't send a zero-length SCTP message, I propose we add a
> PPID_EMPTY value or something similar to indicate a message with empty
> content.
> > [Raju] There is a genuine need for this and the proposal is good.
> > However, I am thinking of an alternate proposal to achieve the same but in
> a generic way.
> > Define a PPID_OOB (out of band) or something similar.
> > Apps can use this to send a message of non-zero length. For the "Yo" kind
> of app or empty stream-level heartbeat purpose, app can send a 1 byte length
> message, which other end's app ignores.
> What do you want to check with the heartbeat purpose? If you can talk to the
> peer?
> That doesn't need to be done for every data channel, but only once for all
> of them.
> As far as I understand, this is done by ICE...
<Raju2> 
Yes, heartbeats to the peer will be taken care by SCTP heartbeats and/or DTLS heartbeats and/or ICE.
But, that does not guarantee data channel level liveliness.
Generic heartbeats are just one of the use cases for PPID_OOB proposal. Other use cases for this include... app can send low-frequency OOB data to the peer within the same data channel instead of creating a new one. This way the OOB will not interfere with syntax+semantics of the main app protocol used in that data channel.
</Raju2>

BR
Raju