RTP streaming/tunneling over Internet

[Sean DuBois]

On Thu, Feb 24, 2022 at 04:18:28PM -0500, Chris Hallinan via gstreamer-devel wrote:
> Hi Team,
>
> I built an application for Apple/MAC to control a radio remotely.  I chose
> gstreamer as the audio streaming infrastructure.  It works great with low
> latency, etc.  Now, however, I'd like to get it working where I can be
> remote (ie outside of my private home network.).  The "server side"
> (connected to the radio on my private network) uses rtpL16pay through
> rtpjitterbuffer to the remote client using rtpL17depay similarly.
> Basically it just spits out UDP RTP packets on port 5000 to whatever remote
> host I choose.
>
>            gstreamer    Typ. Home      Public  Private      gstreamer
> [radio] -- [Server] -- [NAT Router] -- [I'net] -- [NAT] -- [Client PC]
>
> However, to the best of my knowledge, this is not routable over the public
> Internet through my NAT router.  The basic problem is that I'd need to
> configure port forwarding on the remote side for this to work, and when
> you're sitting in a hotel somewhere, that option doesn't exist.
>
> I'm figuring I'd need to connect in from a remote location to a "server"
> element on my private lan (using port forwarding) and then somehow tunnel
> the RTP audio back to me through some type of RTP-compatible tunnel.
>
> Does anyone know of a solution to this?  I'm pretty handy - pointed in the
> right direction, I can figure things out, but I'm not sure what direction
> to go.
>
> Any advice would be appreciated.
>
> Thanks!
>
> Chris
> 73 de K1AY

Hey Chris!

You have a couple different ways you could solve this, totally depends
on what you feel most comfortable with.

* STUN + TURN

You can use a STUN server to create a NAT Mapping. Each side sends a
STUN Binding Request to a STUN server, and gets the IP+Port from the
response. Both sides share their IP+Port and attempt to communicate. In
most cases that will work.

In some cases the hotel network won't allow NAT Traversal at all. Then
you use a TURN server. You will need to run it on host not behind a NAT.
This TURN server just acts as a proxy and will route+accept RTP packets
for you.

* WebRTC

WebRTC uses RTP to Send+Receive Media. It implements everything
described above for you. It also has mandatory encryption. Worth
evaluating if the additional complexity slows you down OR just solves
the problem.

* VPN

You could use something like https://wiretrustee.com/ and handle it all
a layer below.