Elixir server for WebRTC data channels (or other UDP-like channels)

I’m working on a media server that accept UDP using Elixir.

The route that accept the connection is here:
https://github.com/shavit/Diana/blob/master/lib/video_chat/incoming_stream.ex#L16

You are probably looking for this line:
{:ok, _socket} = :gen_udp.open(3001, [:binary, {:active, true}])

Test it:

echo "---> Streaming video ${MEDIA_FILE} at ${FRAMERATE} to the server"
ffmpeg \
  -i $MEDIA_FILE \
  -c:a aac -ar 44100 -ab 128k -ac 2 -strict -2 -c:v libx264 -vb 500k \
  -r $FRAMERATE -s 640x480 -ss 00.000 -f avi \
  udp://127.0.0.1:3001

AFAIK there’s nothing in the phoenix channels that require it to be backed by TCP. It’s only at the transport level (handled by the Phoenix.Socket.Transport behaviour), where the semantics are established. It’s true that both of the built-in transport implementations - websockets and longpoll - are tcp-based. But it’s not impossible to have a custom transport backed by raw udp, WebRTC or other solutions that do not have retry semantics.

I’m not sure if using Phoenix for accepting UDP makes sense. Phoenix endpoint is powered by Cowboy, so TCP is always underneath. UDP is connectionless, so even if it can somehow be integrated directly into endpoint, I think it would be a needless complication.

If the system needs to handle UDP next to TCP traffic, I’d just start a separate process powered by gen_udp. I think it can even listen on the same port as the endpoint, as the networking protocols are different.

I was thinking the same, this probably should not be part of the Phoenix pipeline. And @michalmuskala I do not think I need any of the Phoenix channel connection handling mechanisms either. I don’ t need nor want connection established/dropped events, since there’s really no connection involved. All I want is to send and receive messages, as quickly as possible to reduce the latency.

I think I’ll start off by inspecting how WebRTC DataChannel works when two browsers are connected. Wireshark should do the job I think. I imagine this being pretty thin layer over UDP, but let’s see.

I was trying to check if someone did such thing already possibly in Erlang so I don’t have to do all the hard work

@hubertlepicki While it might be possible to do this with phoenix, it might not be the best idea - I forgot to add that to my response So I fully agree with you here.

@sasajuric I don’t think the channel has to be started by the cowboy. The transport implementation controls this entirely.

I’m not familiar enough with the details to offer much help, but I wanted to make sure you were aware of this conference talk which seems relevant

So why using WebRTC and not UDP which is much simpler and faster? Handshake will slow down the connection.

Oh, I wasn’t aware that there is some other way to use UDP directly from browser… I know you can do it using browser extension, but I do not think I can normally from web pages… Can I do it somehow?

I didn’t saw that you were looking for a browser solution. I was broadcasting using native apps.

Yes, there is the native (WebRTC) getUserMedia with limited browser support, and also ActionScript that requires Flash player installed.

You’re actually right that a socket can be driven separately, I’ve even blogged about it here. So I guess that Phoenix sockets could be driven through gen_udp. Some uncertainty remains, for example how does the lack of guarantees on message arrival and ordering affect socket/channels semantics, but the idea seems interesting.