Not necessarily. The end user’s web browser (i.e. Firefox, Chrome, Chromium etc.) features a technology called ICE which tries to pave a way between Ana and Bob (the call participant’s end points)
It always tries the direct way first - so if Ana and Bob are on the same LAN - the signal goes directly.
If that fails - and this will if for instance Ana or Bob or both are behind NAT routers - then it tries STUN: calling the STUN server to find out which IP public addresses are involved and then try to punch a whole into the NAT router (i.e. establish an incoming path at the far side router)
In most cases this will work. Modern routers include technologies such as UPnP to facilitate this.
But there are nasty cases - like “symmetric NAT”. In this case both routers refuse to establish an incoming route to the endpoint unless the request comes from the same IP address. Only in this case TURN comes into place to route the signal data via a public IP.
This is easy to find out: on the machine your TURN server is running, start a tcpdump -i eth0 (or whatever is the public interface) - then issue a call and observe the packets. You can even see where they come from and where the go to. Fun when you’re on mobile or a corporate / hotel / congress network - sometimes the routing goes criss cross. When you don’t have root access on yout TURN machine, try bwm or bwm-ng to see the bandwith used.
- both endpoints behind popular SOHO routers (Deutsche Telekom and Fritzbox) -> No turn
- one endpoint on mobile: (in this case O2 Germany - they all have carrier grade NAT) - may or may not need TURN
- both endpoints on mobile: definitely TURN
- I haven’t been able to test IPv6 (it simply doesn’t route ist via this protocol)
- neither could I test popular German cable providers which also come with carrier NAT - but offer a public IPv6 address
Perhaps someone else can test this - in other countries as well.