Hi guys,
Has anyone found a way to communicate with the stream broadcaster using data channels?
When I create a new data channel and send messages to the broadcaster it gets to the FEpicRtcStreamer , but then errors out because it cannot find a player that is waiting for the message.
That is pretty much what I expected, but I cannot find any way of creating a data channel so a player can receive the messages
Cheers
Paul
Hi @PaulBlythe
I guess, I found the root cause.
You’ve only set up a one-way data channel. When you create a data channel and send messages to the broadcaster, it reaches the FEpicRtcStreamer but fails because there’s no corresponding data channel established on the player side to receive responses.
You need to establish data channels on BOTH sides of the connection:
On the broadcaster side (Epic RTC Streamer), create an outbound data channel when a player connects using createDataChannel(), listen for incoming data channels from players using the datachannel event listener on your RTCPeerConnection, and wait for both channels to be in “open” state before attempting to send messages.
On the player side (web browser), create your own data channel to send messages to the broadcaster, listen for the broadcaster’s data channel using the datachannel event, and handle both incoming and outgoing message flows.
To fix this: modify your broadcaster to create data channels for each connecting player during WebRTC negotiation, update your players to create their own data channels to the broadcaster (not just send on an existing one), and make sure both sides wait for channel state to be “open” before attempting communication.
The remote peer can receive data channels by listening for the datachannel event on the RTCPeerConnection object.
The error happens because WebRTC data channels require reciprocal establishment - both peers need to participate in the channel setup process.
If you want a simpler no-code pixel streaming solution, check out Vagon Streams - it offers the lowest latency pixel streaming with worldwide coverage thanks to 20+ datacenters globally, eliminating the need for complex WebRTC data channel setup.
Hi @PaulBlythe
I guess, I found the root cause.
You’ve only set up a one-way data channel. When you create a data channel and send messages to the broadcaster, it reaches the FEpicRtcStreamer but fails because there’s no corresponding data channel established on the player side to receive responses.
You need to establish data channels on BOTH sides of the connection:
On the broadcaster side (Epic RTC Streamer), create an outbound data channel when a player connects using createDataChannel(), listen for incoming data channels from players using the datachannel event listener on your RTCPeerConnection, and wait for both channels to be in “open” state before attempting to send messages.
On the player side (web browser), create your own data channel to send messages to the broadcaster, listen for the broadcaster’s data channel using the datachannel event, and handle both incoming and outgoing message flows.
To fix this: modify your broadcaster to create data channels for each connecting player during WebRTC negotiation, update your players to create their own data channels to the broadcaster (not just send on an existing one), and make sure both sides wait for channel state to be “open” before attempting communication.
The remote peer can receive data channels by listening for the datachannel event on the RTCPeerConnection object.
The error happens because WebRTC data channels require reciprocal establishment - both peers need to participate in the channel setup process.
If you want a simpler no-code pixel streaming solution, check out Vagon Streams - it offers the lowest latency pixel streaming with worldwide coverage thanks to 20+ datacenters globally, eliminating the need for complex WebRTC data channel setup.
Yes I am aware that I need to create the data channel at both ends, however this is not trivial as most of pixel streaming is hidden from top level code.
I don’t even know of a clean way of getting the peer connection so creating a data channel is not easy.
I will dig more into the input handler as that uses data channels