Better efficiency for Server Sent Events (via datachannel)

[steely-glint]

Server Sent Events are wasteful in a pure webRTC architecture.
The events originate in the media server, then have to be passed internally to the correct HTTP server within the cluster(probably requiring some sort of permanent connection between the two and reducing mobility of both).
The client then has to hold open a long poll (burning more ports and load balancer resources) in order to receive them after some unquantifiable delay.

All this when we have the WebRTC data channel right there. For Zero extra resource we can (optionally) send the events over a datachannel straight from the media server to the client at low latency.

The client code is almost unchanged as the SSE API looks a lot like a datachannel message (Both presumably modelled on websockets).

see PR #18 for possible wording.

[murillo128]

I am not against the option of using datachannel for event handling, while I think it would need more work on how to negotiate them on the SDP and how to multiplex multiple message events over the same datachannel.

Also, not sure if I would like to delay the final version of the whep spec until we had agreed on a propossal for this or work on it as an extension to the spec.

[steely-glint]

Yes, sorry to bring this up so late. I did try and come up with a minimally invasive PR.

What else do you feel is needed in the SDP negotiation ? I think that since no other WHEP feature uses the data channel it is possibly enough to have both sides agree on m=application etc. Then the client doesn't have to open a data channel it can still use old style SSE if it wants.

I'm not sure I see the need for multiple data channels, the different events seem unambiguous on the wire to me, a simple pollyfill would do the trick I think.

[murillo128]

I have already left some comments on the PR, but I think there are some question:

• How do we negotiate the dc createion, inband, outband or in sdp via (https://datatracker.ietf.org/doc/html/rfc8864)?
• how do we allow the player to choose which events to receive?
• do we need to define reliability/ordered properties of the dc?
• how do we multiplex all the events in dc messages?

[steely-glint]

I've added some replies in the PR, but as far as the dc creation is concerned it should be in-band using DCEP and opened by the client - (I'll add this when/if I update the PR) - This allows a browser client to choose what it wants to do in javascript. (I don't believe this is true for SDP or out of band Data channels).

[murillo128]

@steely-glint I haven't got time to look at this this week, would you mind presenting it at the next IETF meeting?

[steely-glint]

Next week ? or the one after that ?