Use specific ports for webRTC

Question

When creating a peer to peer audio connection using webRTC, the STUN server we use will return the public IP if a user is behind a router. Now in the ICE objects, I can see that the rport is always something between 50000 and up.

Is there a way to use a specific port so that the user does not have to open all those ports?

Harpsichord

Not when you use one of the browser implementations. However, if you write with the native API, I believe you can restrict ports there. – Semitics

Are you sure the port is defined by the browser and NOT by the STUN server? – Harpsichord

The ICE candidate gatherer utilizes a specific port range and only uses ports in that range(or it is just ANY port). – Semitics

Answer 1

Is there a way to use a specific port so that the user does not have to open all those ports?

I think you have a misunderstanding. The whole point of STUN and ICE (including its WebRTC derivative) exists to avoid anyone having to open a port on their NAT. Instead, STUN and ICE dynamically open the port.

Here's how it works (in a really brief description).

1. Client opens a socket on a random port (e.g. 50001)

2. Contacts STUN server using that socket to discover the external IP:port mapping for this socket. (e.g. 192.168.1.2:50001 maps to 1.2.3.4:50001). Ports don't necessarily have to match between internal and external addresses, but they usually do, so I'll keep with that for this example.

3. Through an external mechanism (SIP, XMPP, Jingle, cups with strings), the candidate address list of both nodes are exchanged. This includes all known internal and external addresses collected (e.g. 192.168.1.2:50001 and 1.2.3.4:50001).

4. Using the same socket opened in step 1, both sides send (STUN) messages (UDP packets) directly between each other. The first pair of messages may be blocked by the router/firewall. But because one side initiated an outbound packet to the remote address, subsequent packets from that address are allowed back in. This is called the "hole punching step". Hence, the port is dynamically open without the router needing any specific configuration.

Hope this helps.

Cherimoya

I see. But unless I open the ports on my router manually, webRTC will not work me. It's a standard FritzBox router million others use, I don't think that I have fancy settings. If I don't open the ports myself, STUN will not work (I see the internal and external addresses for the ICE candidates, but communication does not engage) and it falls back to TURN (which then works). If ports are open, STUN works, no TURN needed. If you have any idea as to why this is - I would be very thankful. – Harpsichord

If connections fail when only a STUN server is provided, but succeed when TURN is present, it's likely because your router/ISP is behaving as a "symmetric NAT" (aka address dependent mapping). Which is a technical way of saying that the port mapping behavior is unpredictable. When you open the ports on your NAT to direct to your PC/device, the port mapping becomes consistent. – Cherimoya

Go run stunclient --mode full stun.stunprotocol.org using the code here to validate your NAT behavior. – Cherimoya

What is the cups-with-strings control mechanism?... Doh! – Longinus

Something to note here is the difference between inbound outbound ports. The ports should be open outbound, which is how step 1 works. If outbound ports are blocked, it won't work, and hole punching can't work. – Eleph

Instead, STUN and ICE dynamically open the port. But how can they just open a port if the Network blocks it? – Sikora

This explanation indicates that a P2P connection between peers should be possible even when one peer is behind Full-cone NAT and another peer is behind Symmetric NAT. However, that doesn't appear to be the case. I don't understand why. – Shamrock

Answer 2

You can't programatically unless you are using webrtc API in your own application. The browser will pick specific local ports from a range locally; and then it will inform you about them in the SDP and ICE candidate information.

STUN server only helps discover whether a client is behind a NAT/firewall; and then ICE uses this information in establishing peer-to-peer connection.

I have heard somewhere there might be a way to control that port range via Chrome policy templates(used by enterprises to restrict Chrome settings) - http://www.chromium.org/administrators/policy-templates. It might worth looking into...

Collazo