TURN as a UDP/TCP Traffic Gateway (without NAT)

[Lab Hdvc]

Hi all,

I need to verify my understanding about a turn configuration for a particular scenario.

The scenario is similar to the one shown at page 5 of the additional documentation "TurnNetworks.pdf". I've also attached the picture of the network schema to this discussion.

If I understand well this is the case where the turn server is facing on one side the private internal company network and on another interface the big Internet. This case is similar to the one of my lab where in addition:

- A firewall is configured on the turn machine but without NAT and routing on public interface.

- Hosts doesn't have Internet access at all.

A webrtc gateway (doubango) is connected to the company network (and also to a SIP legacy network) but as any other hosts can't communicate with the Internet. The SIPoWS signaling protocol from the webrtc clients can reach the webrtc gateway through a reverse-proxy that use a separate connection to the big Internet.

How can I configure the TURN server to relay media from outside to inside (and viceversa)?

I figured out that these were the main points:

1. Use of long term authentication (required by webrtc)

2. Use of database on turn for storing users credentials (I will use flat file to begin).

3. Configure properly listener and relayed address.

So at first I have inserted some entries in turnuserdf.conf.default using turnadmin utility.

Then I run my turn installation with the following command (the IPs in use are referred to the TurnNetworks example)

turnserver -a -b /usr/local/etc/turnuserdb.conf.default -f -L 65.165.176.15 -L 172.17.17.107 -E 172.17.17.107 -r mydomain.com -v

The media streams are exchanged correctly between the webrtc clients on the big Internet and the SIP legacy endpoints (or other webrtc clients) on the 

company network.

I'm wondering if this is the correct solution to my enviroment. In addition is not really clear to me what is the difference between listener and relayed ip address.

I'm new to this technology so please share your opinion on this.

Thanks.

[Oleg Moskalenko]

Hi Lab

you can draw the packet flow path(s) in your network, and then you will be able to tell whether this is the right solution.

The "gateway" functionality of the TURN server is facilitated by the fact that:

1) TURN server can have multiple listeners (option -L, listener IPs), in the same or different networks.

2) TURN server can have multiple relay IPs (option -E) - but they all have to be in the same network.

3) If no relay IP is configured, then the TURN server will use the client-side listener IP for the relay endpoint allocation.

4) If the relay IP(s) are explicitly configured, then the TURN server chooses a relay IP among them (in the round-robin manner) for the relay endpoint allocation.

Those are simple rules, and you can use them to determine whether the TURN server provides the right connectivity solution in your case.

You have to remember that the TURN server idea and functionality are very very simple, I'd say trivial, and there is no magic or special processing involved. The implementation may be complex, but from the high-level network design point of view the TURN is a primitive basic thing and you can figure out everything yourself.

The TURN server option list that you provided looks correct, to me.

Regards,
Oleg

--
You received this message because you are subscribed to the Google Groups "TURN Server (Open-Source project)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to turn-server-project-rfc57...@googlegroups.com.
To post to this group, send email to turn-server-project...@googlegroups.com.
Visit this group at http://groups.google.com/group/turn-server-project-rfc5766-turn-server.
For more options, visit https://groups.google.com/d/optout.