Use open ports

[makew0rld]

Summary

It'd be nice if I could give the library a known external address, like a public IP and UDP port, and then have that be part of the SDP / ICE candidates.

Motivation

My main interest in WebRTC is in NAT traversal, using it as a generic P2P transport. It's also nice that it can work in the browser. But outside of the browser there are some existing techniques for NAT traversal like UPnP and NAT-PMP. These standards allow for opening a port on the router. There already existing Go libraries for this, like huin/goupnp and jackpal/go-nat-pmp. I don't think Pion should integrate these libs, but it'd be nice if on a desktop I could call them, get an address, and then give it to Pion to try and use when establishing the WebRTC connection. This will make for faster connection setup, and can create direct connections in places where STUN doesn't work.

Describe alternatives you've considered

Not sure of anything that can do this. Maybe it's already available in the library and I just don't know about it. Maybe just by adding an SDP line before sending it? If that's possible I'd appreciate if someone could share some code.

[Sean-Der]

Hey @makeworld-the-better-one

This does exist today! Check out SetNAT1To1IPs. When you do implement you should write a blog post! I have never seen any numbers, but I am personally curious about the success rate of STUN vs nat-pmp.

[makew0rld]

@Sean-Der Thanks for the link! Glad it's supported. And yes, I'm curious as well. Could you clarify some further questions?

Do the IPs provided contain ports? They'd need to for this use case.

It looks I either choose ICECandidateTypeHost and lose out on mDNS / LAN stuff, or I choose ICECandidateTypeSrflx and lose out on using a public STUN server. For my implementation I'd choose the latter, but it'd be nice to be able to still fall back to STUN if the uPnP didn't work. Is that possible?

[Sean-Der]

Oh you are right, that is IP only. So we have another future ice-mux. It was designed for you to listen on a single port and then share it among PeerConnections.

You can use that so you get explicit port choice AND SetNAT1To1IPs because you know your NAT Mapping details.

[makew0rld]

So would I listen on the local port or the exposed port? They're not the same when doing UPnP. And would that block me from using mDNS? Ideally this would still work within the LAN.

It'd be nice to have a simpler way to do this, if WebRTC specs can support it. Am I wrong in thinking it would just be another line in the SDP?

Thanks for discussing.

[Sean-Der]

You will listen on w/e port you pass to the SettingEngine. It will be a local port, but then the 'exposed port' just sends traffic to it? I need to look at the libraries you linked to understand more sorry.

mDNS should still work! You are just passing a pre-allocated port instead of Pion listening on :0 for you.

The WebRTC spec unfortunately doesn't support this today. You are just allowed to give a list of STUN+TURN servers, but you are giving no control beyond that. I am happy to add more hooks to the SettingEngine. It is a collection of Pion specific/non-standard behavior.

[makew0rld]

It will be a local port, but then the 'exposed port' just sends traffic to it?

Correct. I was asking because I'm not sure if that listening port gets sent outside the NAT somewhere, Like if I use SetNAT1To1IPs and ice-mux, how do peers know what port to use? The actual port listened on should be the local port, but only the exposed port should be sent to anyone outside the NAT.

mDNS should still work!

Good to know, thanks.

The WebRTC spec unfortunately doesn't support this today. You are just allowed to give a list of STUN+TURN servers, but you are giving no control beyond that.

Too bad, thanks though.

[stv0g]

I've started implementation of this feature in a new pion/portmap package.