Been goofing off, busted NAT; happy Easter eggs

[szatox]

VOIP has been a little bit of a boomerang topic for me, I wanted to get it to work, got disappointed, abandoned it, then wanted to make it work again, yada yada....
Anyway, I finally decided to figure out how difficult making a voip phone really is. Did some digging to find out what stuff already exists that I can abuse the hell out of and here we are: I made a very clunky demo.

#1: Media stream
Turns out ffmpeg can do almost anything.
Audio capture, video capture, transcoding, streaming, and finally playback.
a) Encoding video to mpeg4 with either native encoder or libxvid is fast. The playback is almost instantaneous. The native encoder can even use multiple cores, which makes rpi4 fast enough to keep a conversation going. Pretty cool, I did not expect that.
b) UDP transfer is unidirectional. The sender doesn't care whether anyone listens or not. Receiver is able to identify the stream and start playing it at any time. It can gracefully handle some packet loss (Artifacts appear, but it keeps going).
c) Audio delay. Ugh.... This is the "almost" part. I couldn't get the audio out anywhere near as fast as video.
I found AAC-LD and AAC-ELD modes for low latency (rumor says this is what Facetime uses), but ffmpeg won't let me mix them into the stream. Tried various containers, and grepped ffmpeg's source code for hints, I just can't find any output format which would accept AAC-LD. Mp2 and opus in low latency mode don't quite cut it either. Whatever I do, the sound is delayed by like 1.5-2 seconds relative to the input signal, and even the video. I wonder if there is any way to reduce the audio latency to match mpeg4. Right now it is... Well, it surely is usable, but definitely not ideal.

A hint for curious individuals who want to try it:
ffmpeg -f alsa -i default -input_format mjpeg -i /dev/video0 -vcodec mpeg4 -b:v 300k -acodec libfdk_aac -b:a 96k -f mpegts udp://localhost:5678?pkt_size=1024
ffplay -flags low_delay -framedrop udp://localhost:5678 -alwaysontop -fflags nobuffer # requires ffmpeg installed with USE=sdl

#2 Sending data over the internet
Surprise, surprise (no, not really): There are NATs everywhere.
I had a look at RFC describing SIP and STUN, and holly shit, I'm not implementing that. In particular, my jaw dropped when I read about sessions in STUN protocol. Seriously, why does it even need sessions in the first place, I just want to quickly glance at the mirror!?
I guess I'll do it myself then. The thing below is very very basic and equally vulnerable to a low skill DoS against Erlang runtime, but it does successfully poke holes in NATs. As long as both peers can see the server running stun, they should be able to find each other and setup p2p UDP tunnel.

If anyone happened to be very bored, "erlc" compiles the code, "erl -s natbuster init" starts the client on port 12345, "erl -s stun init" starts the poor man's SIP hub on port 9999 (must be visible to both clients). ffmpeg must send its captured udp stream to local client's udp socket (12345), and the data stream received from peer will be available to ffplay on udp port 5678
natbuster:call(peer's callsign) requests a direct UDP tunnel to the other client.