STUN and TURN with Janus (CDN like)

[Sassy Natan]

Hi All,

After creating a Massive deployment of Janus WebRTC Gateway, I was wondering about using TURN in a CDN method like.

I have three basic questions:

1. in janus.cfg there is a nat_1_1_mapping and also stun_server, stun_port. I assume that if I use the stun_server on the Janus side, I don't need to configure the nat_1_1 option. 

If however I enable it, I should disable the stun_server as using them both doesn't make any sense? Is this is right?

2. In the janus.cfg is says: In case STUN is not enough and ; this is needed (it shouldn't), you can also configure Janus to use a ; TURN server; please notice that this does NOT refer to TURN usage in

; browsers, but in the gathering of relay candidates by Janus itself"  I'm guessing that once you enable TRUN in the configuration file,  Janus will be sending the data to the the configure TURN server, and client would get the data from the TURN server. The documentation also point that "you can make use of the TURN REST API to get info on one or more TURN services dynamically" but what does it mean? Does it meas that Janus will work with one or more TURN server simultaneously ? and if so , when a client get a list of optional TURN sever and connect to one of them how Janus will know which TRUN to connect to for the specific client? 

3. is the session (within Janus and the TURN Server) is permanent? or come to life when a client is trying to connect? So if let's say I have 5 TURN server, is that means Janus will send the data to all 5 different TURN server?   

The all idea behind my question is as follow: 

1. A Web Based client is connecting to the WebRTC Gateway via WebSocket

2. The Web Client is located in China

3. The WebRTC gateway is located in California. 

4. The Janus system is configure to use a TURN Server located in the middle (let's say London) 

5. The Web Client get a list of TURN server which have only one server configure (the london one)

6. The Web Client establish a connection with the TURN server in London.

But let's say if the web client get a list of TURN servers (located in London, China, Japan etc..) and with some javascript magic we decided which TRUN sever the client will use (in our example the China one as it is the closest RTT) how  the janus server will know to work with this specific TURN server (the China one)?

My idea is to created some sort of TURN CDN like, either by implement some javascript in the client side, or by using a DNS geo/ AnyCast address to point to the closest TURN edge server of the client.

Thank you 

Sassy 

 

 

[Lorenzo Miniero]

Il giorno giovedì 2 agosto 2018 15:41:42 UTC+2, Sassy Natan ha scritto:

Hi All,

After creating a Massive deployment of Janus WebRTC Gateway, I was wondering about using TURN in a CDN method like.

I have three basic questions:

1. in janus.cfg there is a nat_1_1_mapping and also stun_server, stun_port. I assume that if I use the stun_server on the Janus side, I don't need to configure the nat_1_1 option. 

If however I enable it, I should disable the stun_server as using them both doesn't make any sense? Is this is right?

Correct. Of course, nat_1_1 only works in environments like AWS, where private and public port are always the same.

 

2. In the janus.cfg is says: In case STUN is not enough and ; this is needed (it shouldn't), you can also configure Janus to use a ; TURN server; please notice that this does NOT refer to TURN usage in

; browsers, but in the gathering of relay candidates by Janus itself"  I'm guessing that once you enable TRUN in the configuration file,  Janus will be sending the data to the the configure TURN server, and client would get the data from the TURN server. The documentation also point that "you can make use of the TURN REST API to get info on one or more TURN services dynamically" but what does it mean? Does it meas that Janus will work with one or more TURN server simultaneously ? and if so , when a client get a list of optional TURN sever and connect to one of them how Janus will know which TRUN to connect to for the specific client? 

No, it means that for every PeerConnection Janus will contact the TURN REST API to ask which server (as in 1 server) and credentials it should use for that PC. Whether the API returns the same server or different servers for different PCs is up to the implementations of the API. This is typically only needed when you HAVE to use TURN (which again is very suboptimal), and you don't like the idea of all PCs using the same static credentials you'd configure in janus.cfg instead.

3. is the session (within Janus and the TURN Server) is permanent? or come to life when a client is trying to connect? So if let's say I have 5 TURN server, is that means Janus will send the data to all 5 different TURN server?   

Sorry, I didn't understand the question.

 

The all idea behind my question is as follow: 

1. A Web Based client is connecting to the WebRTC Gateway via WebSocket

2. The Web Client is located in China

3. The WebRTC gateway is located in California. 

4. The Janus system is configure to use a TURN Server located in the middle (let's say London) 

5. The Web Client get a list of TURN server which have only one server configure (the london one)

6. The Web Client establish a connection with the TURN server in London.

But let's say if the web client get a list of TURN servers (located in London, China, Japan etc..) and with some javascript magic we decided which TRUN sever the client will use (in our example the China one as it is the closest RTT) how  the janus server will know to work with this specific TURN server (the China one)?

My idea is to created some sort of TURN CDN like, either by implement some javascript in the client side, or by using a DNS geo/ AnyCast address to point to the closest TURN edge server of the client.

I don't see why in this scenario you'd want Janus to use TURN as well. In 99% of the cases it's not needed, and as explained it would heavily affect performance. Give users the option to use TURN, and leave Janus alone: if users will end up using TURN, Janus will talk to the TURN server automatically.

Lorenzo

 

Thank you 

Sassy 

 

 

[Sassy Natan]

On Thursday, August 2, 2018 at 8:32:39 PM UTC+3, Lorenzo Miniero wrote:

Il giorno giovedì 2 agosto 2018 15:41:42 UTC+2, Sassy Natan ha scritto:

Hi All,

After creating a Massive deployment of Janus WebRTC Gateway, I was wondering about using TURN in a CDN method like.

I have three basic questions:

1. in janus.cfg there is a nat_1_1_mapping and also stun_server, stun_port. I assume that if I use the stun_server on the Janus side, I don't need to configure the nat_1_1 option. 

If however I enable it, I should disable the stun_server as using them both doesn't make any sense? Is this is right?

Correct. Of course, nat_1_1 only works in environments like AWS, where private and public port are always the same.

 Thank you! this make sense

 

2. In the janus.cfg is says: In case STUN is not enough and ; this is needed (it shouldn't), you can also configure Janus to use a ; TURN server; please notice that this does NOT refer to TURN usage in

; browsers, but in the gathering of relay candidates by Janus itself"  I'm guessing that once you enable TRUN in the configuration file,  Janus will be sending the data to the the configure TURN server, and client would get the data from the TURN server. The documentation also point that "you can make use of the TURN REST API to get info on one or more TURN services dynamically" but what does it mean? Does it meas that Janus will work with one or more TURN server simultaneously ? and if so , when a client get a list of optional TURN sever and connect to one of them how Janus will know which TRUN to connect to for the specific client? 

No, it means that for every PeerConnection Janus will contact the TURN REST API to ask which server (as in 1 server) and credentials it should use for that PC. Whether the API returns the same server or different servers for different PCs is up to the implementations of the API. This is typically only needed when you HAVE to use TURN (which again is very suboptimal), and you don't like the idea of all PCs using the same static credentials you'd configure in janus.cfg instead.

Understand, So that means that once the client is using TURN, the janus server will first contact the TRUN REST API, get a server and credentials from it, and them provide the info the client? (if so How? Does the credentials goes under the Websocket session, or HTTP/S)?

If not - How does the client get the credentials?

3. is the session (within Janus and the TURN Server) is permanent? or come to life when a client is trying to connect? So if let's say I have 5 TURN server, is that means Janus will send the data to all 5 different TURN server?   

Sorry, I didn't understand the question.

Ignore it, stupid one!

 

 

The all idea behind my question is as follow: 

1. A Web Based client is connecting to the WebRTC Gateway via WebSocket

2. The Web Client is located in China

3. The WebRTC gateway is located in California. 

4. The Janus system is configure to use a TURN Server located in the middle (let's say London) 

5. The Web Client get a list of TURN server which have only one server configure (the london one)

6. The Web Client establish a connection with the TURN server in London.

But let's say if the web client get a list of TURN servers (located in London, China, Japan etc..) and with some javascript magic we decided which TRUN sever the client will use (in our example the China one as it is the closest RTT) how  the janus server will know to work with this specific TURN server (the China one)?

My idea is to created some sort of TURN CDN like, either by implement some javascript in the client side, or by using a DNS geo/ AnyCast address to point to the closest TURN edge server of the client.

I don't see why in this scenario you'd want Janus to use TURN as well. In 99% of the cases it's not needed, and as explained it would heavily affect performance. Give users the option to use TURN, and leave Janus alone: if users will end up using TURN, Janus will talk to the TURN server automatically.

Well, it might sound stupid, and I understand about the affects on performance and cost when using STUN, in real life scenarios we often see the following issues:

1. Users from China get connect to the remote webrtc gateway located in California.

2. It is quite often to find a very poor network speed within the client located in China to the Server located in California.

3. As I'm using the streaming plugin option of janus, the media data need to travel all the way from California to China.

3. Assume I put a TURN server in the middle, somewhere in China, where this TURN server has A) a very good network connectivity to the server located in California, and B) a  very good network connectivity to the client located in China, this will improve availability of the stream, where at the moment suffer from very bad performance and quality. 

4. True that you could point out why not just putting additional WebRTCGateway in China, instead of the TURN server? Well it might be good solution, but then I will need to stream out all my video stream (around 80 streams) to this remote server (24 hours, 7 days a week, 365 days a year) even if there is no consumer that acquire any streams. At the moment the media stream is located on the same LAN where the webrtc gateway is located (California), so I don't spend money on wasted traffic.

5. This is why I call this a TRUN CDN Like.

Thank You Again, and have a nice weeked.

 

Lorenzo

 

Thank you 

Sassy 

 

 

[Sassy Natan]

X

Well, it might sound stupid, and I understand about the affects on performance and cost when using TURN(NOT STUN), in real life scenarios we often see the following issues:

1. Users from China get connect to the remote webrtc gateway located in California.

2. It is quite often to find a very poor network speed within the client located in China to the Server located in California.

3. As I'm using the streaming plugin option of janus, the media data need to travel all the way from California to China.

3. Assume I put a TURN server in the middle, somewhere in China, where this TURN server has A) a very good network connectivity to the server located in California, and B) a  very good network connectivity to the client located in China, this will improve availability of the stream, where at the moment suffer from very bad performance and quality. 

4. True that you could point out why not just putting additional WebRTCGateway in China, instead of the TURN server? Well it might be good solution, but then I will need to stream out all my video stream (around 80 streams) to this remote server (24 hours, 7 days a week, 365 days a year) even if there is no consumer that acquire any streams. At the moment the media stream is located on the same LAN where the webrtc gateway is located (California), so I don't spend money on wasted traffic.

5. This is why I call this a TRUN CDN Like.

Thank You Again, and have a nice weeked.

 

 

Lorenzo

 

Thank you 

Sassy 

 

 

[Geige]

1. Users from China get connect to the remote webrtc gateway located in California.
2. It is quite often to find a very poor network speed within the client located in China to the Server located in California.
3. As I'm using the streaming plugin option of janus, the media data need to travel all the way from California to China.
3. Assume I put a TURN server in the middle, somewhere in China, where this TURN server has A) a very good network connectivity to the server located in California, and B) a  very good network connectivity to the client located in China, this will improve availability of the stream, where at the moment suffer from very bad performance and quality. 
4. True that you could point out why not just putting additional WebRTCGateway in China, instead of the TURN server? Well it might be good solution, but then I will need to stream out all my video stream (around 80 streams) to this remote server (24 hours, 7 days a week, 365 days a year) even if there is no consumer that acquire any streams. At the moment the media stream is located on the same LAN where the webrtc gateway is located (California), so I don't spend money on wasted traffic.
5. This is why I call this a TRUN CDN Like.

You can do all of this without a TURN server for Janus. You only need the turn on the client side. Just set up a turn sever (this has nothing to do with Janus), and force the client to use the turn in whatever scenario you want by setting the iceTransportPolicy to relay. Janus will simply act like any other webrtc peer and use the turn server.

You don't need to do point number 4. You can connect to the california servers without a TURN server for Janus.

Just realized this is pretty much what Lorenzo said, but hopefully this is still helpful.

[Sassy Natan]

Thank You

On Friday, August 3, 2018 at 8:34:41 PM UTC+3, Geige wrote:

1. Users from China get connect to the remote webrtc gateway located in California.
2. It is quite often to find a very poor network speed within the client located in China to the Server located in California.
3. As I'm using the streaming plugin option of janus, the media data need to travel all the way from California to China.
3. Assume I put a TURN server in the middle, somewhere in China, where this TURN server has A) a very good network connectivity to the server located in California, and B) a  very good network connectivity to the client located in China, this will improve availability of the stream, where at the moment suffer from very bad performance and quality. 
4. True that you could point out why not just putting additional WebRTCGateway in China, instead of the TURN server? Well it might be good solution, but then I will need to stream out all my video stream (around 80 streams) to this remote server (24 hours, 7 days a week, 365 days a year) even if there is no consumer that acquire any streams. At the moment the media stream is located on the same LAN where the webrtc gateway is located (California), so I don't spend money on wasted traffic.
5. This is why I call this a TRUN CDN Like.

You can do all of this without a TURN server for Janus. You only need the turn on the client side. Just set up a turn sever (this has nothing to do with Janus), and force the client to use the turn in whatever scenario you want by setting the iceTransportPolicy to relay. Janus will simply act like any other webrtc peer and use the turn server.

You don't need to do point number 4. You can connect to the california servers without a TURN server for Janus.

Just realized this is pretty much what Lorenzo said, but hopefully this is still helpful.

Thank You,

So what you are saying is once I configure the web client to use the TURN, the client will connect to the TRUN and the TURN will connect to Janus, Janus will replay back to the TURN, and TURN will replay back to the client?

If so, what is the logic for configure TURN with janus.cfg? Is it only in the case of putting the Janus behind a firewall? in a local LAN? or when u want to minimize the number of open ports in the FW?

Two last question I have in mind is

1. How do i make the client auth to the TRUN server?  Do I need to provide some static auth password in the javascript?

2. If Janus will use TRUN, is that means that when a client (A) connect to TRUN (T1), this TURN (T1) will connect to TURN (T2), where Janus (J) is connect to the TURN(T2) Server? Something like: A->T1<->T2<-J

Sassy 

[Geige]

So what you are saying is once I configure the web client to use the TURN, the client will connect to the TRUN and the TURN will connect to Janus, Janus will replay back to the TURN, and TURN will replay back to the client?

Yes. 

If so, what is the logic for configure TURN with janus.cfg? Is it only in the case of putting the Janus behind a firewall? in a local LAN? or when u want to minimize the number of open ports in the FW?

None, it just acts like any other webrtc client. Janus will obviously need to be able to communicate with the TURN. Anything involving a firewall or limiting ports can be done outside of the Janus code. You would only need to start messing with configuration stuff if your firewall was so strict that Janus needed its own TURN, which does not sound like the case for you. It sounds like you just want to optimize the network connection between Janus and the TURN and make sure that clients connect to the TURN -- none of that is really related to the Janus config.

1. How do i make the client auth to the TRUN server?  Do I need to provide some static auth password in the javascript?

There are various ways to do authentication. A static auth password is one of them. You can also use time limited credentials. You can check this as a reference for time-limited stuff, but I wouldn't use it as is https://github.com/geigev/docker-turn

2. If Janus will use TRUN, is that means that when a client (A) connect to TRUN (T1), this TURN (T1) will connect to TURN (T2), where Janus (J) is connect to the TURN(T2) Server? Something like: A->T1<->T2<-J

This situation is not unique to Janus. It would be the same thing as any two clients behind strict firewalls that both required TURNs, which I believe works as you described.

Think I described all of that accurately -- if not, I'm sure someone else can correct me.

--Cheers 

[Sassy Natan]

Sorry, But I still have fighting to understand this better.

Here is a small summary:

1. Client X is getting a list of TURN servers (via static js files in some web server).

2.  The iceTransportPolicy is set to relay on the client X

3. The client X connect to one of the TURN and provide a user and password for valid authentication. the picked TURN server (T) will be the one which is located in China due the fact the user is coming from China.

Note: The list of TURN servers to be used by the client, as well as the user/password the client needs to provide for authenticate with the TRUN server is not related to Janus server. 

4. Once the client X connect to the picked TURN server (T), the TURN server (T) will connect to the JANUS server (J) as any valid webrtc client, and will act like a MAN in the middle for transferring the media data withing the client X and the Janus Server (J)

5. TURN is obviously publicly address, the client is behind a NAT, and the Janus is also publicly addressable. 

6. The client X will connect the TURN and can work as expect even in cased where the client is behind a firewalls that block UDP ports or use Symmetric NAT.

Note: When Janus is publicly available, client behind a Symmetric NAT can still work even without a TURN due to latching. However if Janus is also behind a NAT, client will not be able to connect without TURN.

7. One question I have here is that what if a new client Y will use the same TURN server (T), and will ask for the same stream that is already being use by Client X? I guess the TURN server will establish a new WebRTC to Janus Server J, even that basically the TURN server is already consuming the same stream?

8. Second, what about the case where Janus server (J) itself is configure to use TURN? Where it is assume that Janus itself is behind a NAT, or even protected by a firewall, where it blocks UDP port. Configure janus.cfg to use turn_server, turn_port, turn_type, turn_user, turn_pwd then will make the janus server (J) itself to function in any network scenario such as this (UDP Block, NAT Symmetric), but will be limited to work with only the specific TRUN server which is was configure under the the janus.cfg. But Lorenzo point out you can "contact the TURN REST API to ask which server and credentials it should use for that PC". By saying PC Lorenzo means the janus sever? or something else? I'm not sure if he referring here to the clients (like client X or Y)? 

Also if the TURN REST API return different TURN  server to be used, is that means the janus sever can work with multi TURN servers? It is unclear as here Lorenzo saying it is unsupported.

Last thing: if I used configure the janus server to use TURN, is that mean that the client need to connect TURN server as Janus is connect to? or it is not necessary? So client can connect to any TURN server, janus can connect to any TURN server, and the magic is happening withing the two TURN servers. If they both accidentally (client and janus severs) point to the same TURN server, you might improve delay, predominance and  saved a network bandwidth but in terms of connectivity it has no impact.

See some more info here:

https://groups.google.com/forum/#!searchin/meetecho-janus/turn$20TCP%7Csort:date/meetecho-janus/DokSG5vReqk/8iVjvqmsAQAJ

Thank You all! Such an amazing community we have here! 

[Lorenzo Miniero]

Yes, clearly if Janus is behind a NAT as well he should act as a regular WebRTC peer, which might mean need STUN, or in worse cases, even TURN for itself. But that's the point: you should NEVER need Janus to be behind such an annoying NAT (unless Janus is on a box sitting at your home, for instance), as otherwise you'll increase the risk of suboptimal performance.

If this is for a public service, just don't put Janus behind a NAT and you you'll be fine.

Lorenzo

[Sassy Natan]

Lorenzo, Thank you for the quick replay!

But if you could help me here to by Yes/NO answer it will be great as I understand what you wrote but still have some question opens.

See in the red:

On Saturday, August 4, 2018 at 6:23:27 PM UTC+3, Lorenzo Miniero wrote:

Yes, clearly if Janus is behind a NAT as well he should act as a regular WebRTC peer, which might mean need STUN, or in worse cases, even TURN for itself. But that's the point: you should NEVER need Janus to be behind such an annoying NAT (unless Janus is on a box sitting at your home, for instance), as otherwise you'll increase the risk of suboptimal performance.

If this is for a public service, just don't put Janus behind a NAT and you you'll be fine.

Lorenzo

Il giorno sabato 4 agosto 2018 17:04:18 UTC+2, Sassy Natan ha scritto:

Sorry, But I still have fighting to understand this better.

Here is a small summary:

1. Client X is getting a list of TURN servers (via static js files in some web server).

2.  The iceTransportPolicy is set to relay on the client X

3. The client X connect to one of the TURN and provide a user and password for valid authentication. the picked TURN server (T) will be the one which is located in China due the fact the user is coming from China.

Note: The list of TURN servers to be used by the client, as well as the user/password the client needs to provide for authenticate with the TRUN server is not related to Janus server. 

4. Once the client X connect to the picked TURN server (T), the TURN server (T) will connect to the JANUS server (J) as any valid webrtc client, and will act like a MAN in the middle for transferring the media data withing the client X and the Janus Server (J)

5. TURN is obviously publicly address, the client is behind a NAT, and the Janus is also publicly addressable. 

6. The client X will connect the TURN and can work as expect even in cased where the client is behind a firewalls that block UDP ports or use Symmetric NAT.

Note: When Janus is publicly available, client behind a Symmetric NAT can still work even without a TURN due to latching. However if Janus is also behind a NAT, client will not be able to connect without TURN.

True? 

7. One question I have here is that what if a new client Y will use the same TURN server (T), and will ask for the same stream that is already being use by Client X? I guess the TURN server will establish a new WebRTC to Janus Server J, even that basically the TURN server is already consuming the same stream?

True? I guess this need to be configure in the application itself. 

8. Second, what about the case where Janus server (J) itself is configure to use TURN? Where it is assume that Janus itself is behind a NAT, or even protected by a firewall, where it blocks UDP port. Configure janus.cfg to use turn_server, turn_port, turn_type, turn_user, turn_pwd then will make the janus server (J) itself to function in any network scenario such as this (UDP Block, NAT Symmetric), but will be limited to work with only the specific TRUN server which is was configure under the the janus.cfg. But Lorenzo point out you can "contact the TURN REST API to ask which server and credentials it should use for that PC". By saying PC Lorenzo means the janus sever? or something else? I'm not sure if he referring here to the clients (like client X or Y)? 

So what PC means? Janus itself? 

Also if the TURN REST API return different TURN  server to be used, is that means the janus sever can work with multi TURN servers? It is unclear as here Lorenzo saying it is unsupported.

So wtih API janus can use multi TURN servers? 

Last thing: if I used configure the janus server to use TURN, is that mean that the client need to connect TURN server as Janus is connect to? or it is not necessary? So client can connect to any TURN server, janus can connect to any TURN server, and the magic is happening withing the two TURN servers. If they both accidentally (client and janus severs) point to the same TURN server, you might improve delay, predominance and  saved a network bandwidth but in terms of connectivity it has no impact.

True? 

See some more info here:

https://groups.google.com/forum/#!searchin/meetecho-janus/turn$20TCP%7Csort:date/meetecho-janus/DokSG5vReqk/8iVjvqmsAQAJ

Thanks you very much!!!!! 

[Lorenzo Miniero]

I already answered. It depends no the NAT Janus is behind. You may need STUN, you may need TURN. Just make sure you won't need either for Janus.

I think Geige did a great work at explaining how this all works, even better than I could do, so if this is still unclear to you I think you'd better look for some courses or documents/tutorials explaining how the ICE process works. The update to the ICE RFC is a good read for that, even if a bit heavy: https://tools.ietf.org/html/draft-ietf-ice-rfc5245bis-20

Lorenzo

[Phúc Lê Minh]

Hi all, are janus-gateway support response code 300 alternate-server of turn server?

[Phúc Lê Minh]

for anyone, asking my question. Janus gateway using libnice v0.1.16 (or above). alternate-server already supported at v.0.1.15