TURN Server Integration with Janus Gateway - Performance Issue

[Kannan Murali]

Hi:

To support WebRTC clients to our existing conferencing solution, we are using Janus Gateway. For security reasons, we have placed the 

TURN server behind the NAT server and mapped to an external/public IP address - Janus Gateway also placed behind the NAT server.

The TURN server configuration is passed to the WebRTC clients and are used by the Janus Gateway.

Performance Test #1:

================

With the libnice library patch/fix for the global lock issue, we were able to successfully complete the performance test for the 800 Peer connections 

with the following CPU specifications for the Janus Gateway:

1. I CPU X 1 Core = 1 Core with 8GB RAM

2. 1 CPU X 2 Cores = 2 Cores with 8 GB RAM

3. 2 CPU X 2 Cores = 4 Cores with 8 GB RAM.

Note:  95% of the WebRTC clients (with our conferencing application we have 8 Peer Connection per WebRTC client - 4 OPUS audio and 4 H264 video) 

are generated using our automated test tool which is placed in our internal network.

Performance Test #2:

================

However, when we generate those 95% of the WebRTC clients from the Internet (from AWS) we are seeing performance issues with the Appshare 

(H264 Video) feature. We have tried the following CPU specification for the Janus Gateway:

1. 1 CPU X 1 Core = 1 Core with 8GB RAM.

    We didn't see the appshare showing up in the WebRTC clients - only blank screen. 

2. 2 CPU X 2 Cores = 4 Cores with 8 GB RAM

    With this hardware specification, audio seems to be working, but the we were able to see the appshare in the WebRTC client window, however, we saw 

    frequent freeze and catch up which may not be an acceptable solution for Appshare/Video.

We are seeing the UDP packets drops in the Janus Gateway.

Note: We saw similar symptoms (udp packets drops in the Janus Gateway) that we experienced for the performance test #1 specified above, but with 

the libnice library global lock issue. Once the libnice library global lock issue is fixed the media (Audio/Video/Appshare) were working fine.

Anyone tried similar TURN server topology and have experienced any issue(or similar issue), let's know.

[Mirko Brankovic]

hi,

Thanks for sharing info, this is quite useful.

I just don't understand why you use Turn server for security reasons. It is not a Firewall or Fraud alerter, all the UDP/TCP that you open on Janus you have to open on Stun/Turn also, so it becomes transparent/forwarding unit only.

Thanks,

Mirko

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janus+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Regards,

Mirko

[Lorenzo Miniero]

Il giorno giovedì 1 giugno 2017 10:03:25 UTC+2, Mirko Brankovic ha scritto:

hi,

Thanks for sharing info, this is quite useful.

I just don't understand why you use Turn server for security reasons. It is not a Firewall or Fraud alerter, all the UDP/TCP that you open on Janus you have to open on Stun/Turn also, so it becomes transparent/forwarding unit only.

Well, with a TURN server you can open a very limited number of ports to the outside, even just one, so that all users would end up using the same. The UDP ports you'd open to talk to Janus may only be opened internally, e.g., in some sort of LAN, and all ports Janus would use would be hidden from the outside world.

L.

[Mirko Brankovic]

oh ok, i see the point ... thanks :)

[Alessandro Amirante]

Hi Kannan,

not sure I get this straight: are you saying that you experienced packet loss when your WebRTC clients were outside the AWS network (i.e., from the Internet), while you had no packet loss when testing from within the AWS network (i.e., from the same LAN as the Janus server)?

If so, this seems to me like a networking issue with AWS, and you may want to check wether your instance has the "Enhanced Networking" feature enabled. AFAIK, it's not enabled by default.

Anyway, if you don't have losses when clients and server are on the same LAN, I think Janus has nothing to do with this issue.

A.

[Kannan Murali]

Alessandro:

Sorry, I missed to point this out in the my original post. 95% of the WebRTC clients are generated by the automated test tool. Rest of the 3% of the 

WebRTC clients are live clients to watch the media traffic and the 2% of the clients are our traditional clients to generate media traffic.

With the both of the test cases, this 5% of the clients didn't change - they are launched from our corporate network in both cases. We see the media 

quality issue from the live WebRTC clients with Test #2.

If the issue is with AWS network, then we should see the issue only in the auto generated WebRTC clients only from AWS. But we are experiencing 

the issue with the live WebRTC clients that we are launching from our corporate network.

And when I say udp packets drops, we saw this in the Janus Gateway using the "gawk '$NF != 0' /proc/net/udp" command.

-KMurali

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.