Using TURN server with Janus

[Sharath Kumar]

Hello,

We plan to install Janus on a private server in our data-center. It will be behind  firewalls/NAT. STUN may not work correctly for all users. I was planning to use the open-source TURN server. I noticed that in Janus.cfg there is an option to provide the URL of the stun-server via ;stun_server= "FQDN of stun server". However, for TURN I believe we also need to pass credentials. i.e name/password as part of the url. Can someone show me how to add that information ? or if this is supported ? I apologize if this has been asked before but I couldn't find any information specifically on this.

thanks

Sharath

[Lorenzo Miniero]

You mean you'll need Janus to actually request relay candidates for himself? If you just need your users to use TURN, you don't need to change anything there, you'll need to provide a TURN server as part of the web application info. To force Janus to use a TURN server as well you can currently only specify the turn server, I don't think we added credentials yet as it's a very recent addition.

L.

[Gatecrasher777]

You can specify a turn server at the point where you create sessions in your application: 

var janus = new Janus(

        {

                server: 'http://yourserver:8088/janus',

iceServers = [{url: 'turn:domain:3478?transport=udp',

credential: 'turnpassword',

username: 'turnuser'

}];

                success: function() {

                        // Done! attach to plugin XYZ

                },

                error: function(cause) {

                        // Error, can't go on...

                },

                destroyed: function() {

                        // I should get rid of this

                }

        });

[Sharath Kumar]

Thanks but I really wanted to know if Janus can operate behind a strict symmetric nat and as Lorenzo clarified, it does not support TURN relay candidates as of yet. Anyway, this will be the use case if Janus is deployed *on* premise in a corporate enviroment with symmetric NAT. In our cloud environment I can probably ensure that I can open up ports and really turn off some strict NAT functions. 

Sharath

[Lorenzo Miniero]

To clarify, we started working in that direction and you can already have relay candidates being added by Janus. I seem to recall we had added the credentials management, but you'll have to look at the latest version of the main configuration sample as I don't have the code in front of me. That said, I don't think it works in its current stage, but feedback would help us getting that done properly.

Lorenzo

[Sharath Kumar]

Okay sure. I will let you know when we try this configuration.

Sharath

[Davide Bertola]

I am using janus on amazon ec2. The ec2 machine has all traffic enabled in/out and it has a public ip. I launched janus specifying the public ip with 

./janus -p 8088 -i eth0 -e 52.16.67.18

Then i installed a turn server called coturn (on the same machine). I launch it like this

/usr/bin/turnserver -u pino:pino --realm pino -X [public ip]  -vvvv  -z

On the client i provide the following icecandidates

{"url": "turn:[public_ip]:3478", username:"pino", credential:"pino"}

I do not provide stun because i am fine with all the traffic passing through the server. However it does not work. Should i see the server public ip in the candidates processed by the cliant "onicecandidate" ? Should they be of "relay" type ? What am i missing ?

Thank you!

Il giorno giovedì 19 febbraio 2015 16:40:30 UTC+1, Sharath Kumar ha scritto:

[Lorenzo Miniero]

The -e flag and Amazon are apparently not a good combo, from some feedback we got. Since an EC2 instance basically sits behind a NAT (even if it's a 1-1 NAT), you need to disable the -e option and specify a STUN server instead.

L.

[Davide Bertola]

Ok then what happens if the stun server itself is behind the very same 1-1 NAT  (ec2) ? 

Also, have you omitted TURN intentionally ?

Il giorno giovedì 19 febbraio 2015 16:40:30 UTC+1, Sharath Kumar ha scritto:

[Lorenzo Miniero]

STUN and TURN servers cannot be in a private network, as their main purpose is to provide info or means for connectivity to users behind a NAT. Always add both a STUN and a TURN in a WebRTC web page: TURN alone will just get relay candidates which will be inefficient if unneeded.

L.

[Gatecrasher777]

Lorenzo, I am using coturn in my project, which I'm guessing mostly acts as a STUN server, since Janus is running on a public IP. In all cases that I have seen, clients present host (useless), server reflexive (preferred) and relay candidates (inefficient) to Janus against Janus's public host candidate. 

Theoretically, are there situations where TURN relay candidates would be used?  Maybe in cases where there is a local NAT in conjunction with restrictive firewall, vpn, corporate proxy or anonymous proxy? Or, since the set-up is peer-2-gateway-2-peer am I unlikely to ever see TURN get utilized?  By having a TURN server enabled, am I introducing any inefficiency?  Or is the overhead of gathering unused relay candidates trivial given that the project aims to maximize ICE negotiation success, rather than the speed of negotiating?

I guess what I am really asking is: Is there an operational upside to implementing one's own STUN/TURN server versus just using the default public STUN server from Google?

[Lorenzo Miniero]

As you said, the purpose is to maximize the chances of successfully completing the ICE process in any possible scenario. In normal condition, the additional relay candidates would not be involved as more efficient candidate pairs would be chosen first.

L.

[Nicholas Wylie]

In our workplace there is a very restrictive firewall between local and public. I wanted to host Janus on the internal network, and allow access by external users. The solution ended up being to setup a local TURN server with exceptions through the firewall.

Ideally peers on the local network would able to access a STUN server external to the network, then the TURN server would be irrelevant. Most firewalls appear to be stateful and work fine with nothing but a STUN server. It's probably only the rare and awkward situations where TURN is required.