Corporate users cant view our Live stream

[Peter Miller]

We have been successfully broadcasting a 360 Live stream for many months.  We can view the live stream on any Browser or Device after loading our HTTPS:// URL.

Most users ( individuals, small companies, etc. ) can use our HTTPS Link to view our 360 live stream with no problem.

We have now encountered  2 corporate clients ( Global corporations) that cannot view our live stream.  Non-corporate users can view the same stream with no problem at the same time, but both corporate clients  cannot.  Even using personal laptops at the same location allows viewing of the stream.  The Blocked users simply see a black viewer in place of the live stream.  The corporate users can get to our https site.

How are these corporate IT groups blocking the stream?  could it be a setting in the Group Policy that is blocking Live Streaming or could it be a firewall setting?  We want to be able to recommend a solution if possible, but we have no idea how they are blocking it to begin with.

[Joseph Brundige]

You can configure the Turn sever for firewall transversal, but in my experience, most of the trouble comes from clients that are on a VPN. For that, I just tell them to disconnect VPN. 

--

Joe Brundige 

 310.889.8288

 424.444.0555

 . 

[Peter Miller]

Hi Joe,

Thanks for getting back to me.  

We tested with a corporate user today and he checked that the VPN was 'off' on the laptop ( meaning the he said he was not connected to his internal network via VPN and his VPN status showed "Not Connected".)  In this case the user we tested with today was working from home and not ( as best as he could tell) connected to his corporate network via VPN.  We were on a web conference at the time but he only has a low level of permissions on the laptop anyway so we could not test further.

Given the scenario in today's testing we presume he is not blocked at a firewall level because he was not on his corporate network.  He also tested a live stream from CBSNews.com/live and was able to see those streams.

I think we are still in the dark as to how they are blocking our stream.

 

[Justin Hirsch]

Just a thought.. could this be the certificate chain issue?  You should verify using SSL labs free server test that your certificate chain is complete.  There was an issue and there is a workaround with version 2.2 of the server.

[Peter Miller]

Thanks Joe I will check the status of the certificate.  I sent a question into Ant Media's tech support also.

 

 

[Tahir]

Hi,

The corporate internet has probably a firewall like in most cases, which blocks the UDP communication between Ant Media and the client that is connected through the corporate network. They can indeed connect to your website because they are connecting your website through htpps and the firewall does not drop it because it is a TCP based secure protocol. Ant Media connects through TCP for the websocket but the stream in between AMS and client goes through UDP in WebRTC case and corporate networks does not allow free UDP communication for security reasons. In the case there are some options;

 

1) Build a TURN server, check out: https://github.com/ant-media/Ant-Media-Server/wiki/TURN-Servers

2) Enable UDP in corporate networks in between 5000:65000 ports ( which the configuration probably will not allow )

I guess you can also use TCP candidates depending on the network architecture but I don't recommend it. I strongly believe that a TURN server will solve your issue.

Cheers,

Tahir

[Peter Miller]

Thanks Tahir!

We will start looking into this.

 

[Peter Miller]

Tahir,

One more question has come up about the TURN server implementation.  Is it appropriate to put the TURN server on the same VM as the AntMedia server or should this be a separate VM.  We are not sure what resources it will require but we want to have a simple overall solution but  need the streams to be reliable.  Let me know if there is a Best Practice for the TURN Server.

Thanks Again.

 

[Robert Berger1648581691]

We are having a similar problem where some of our customers are on LANs that seem to be blocking ports other than things like http/https. Would a TURN server help that? We're using the Antmedia webrtc Javascript SDK. How would we configure the SDK to use a TURN server to talk to our Antmedia server in AWS?

Thanks

 

[Tahir]

Hi guys,

Let me explain how TURN server works very basically and I will drop you a reference for further info. 

There are 3 type of ICE candidates ( they contain information about IP, ports etc. ) which are coming from TURN server, STUN server or host generation. Basically STUN server and host generation types are trying to build a connection with one of the available UDP ports (5000-65000) between server and client. Since the NATs and firewalls does not allow a connection in between them, the solution is to build a TURN server, which the client and server will be connected to TURN server instead of each other and the stream will flow through it. This is a configuration that NAT types or firewalls will allow in many cases. Check this one for better explanations;

https://antmedia.io/learn-webrtc-basics-components/

This is how different NATs work and you can see STUN server or host generation will not work on some of them because they require previous contact;

https://en.wikipedia.org/wiki/Network_address_translation

So regarding these, let me answer your questions.

Peter;

Nope it does not make sense to build TURN server in same place with the Ant Media Server. TURN server should be somewhere that is easy to connect without a firewall or complex NAT structure. The stream will relay through it, there will be no encoding or so, so it is a low performance requirement.

Rob;

It depends on the internal architecture and where do you put the TURN server. I think in LAN it is better to just open to UDP ports in between clients. I mean it is already an internal network. If you place TURN server somewhere that both peers can connect it should work.

Cheers,

Tahir

[Tahir]

Also for configuring TURN server in javaScript, you need to change pc_config like this in our sample pages;

var pc_config = { 'iceServers' : [ { 'urls' : 'turn:<turn_server_address>:<port_number>' 'username': "username" 'credential': "password" } ] };

Reference;

https://github.com/ant-media/Ant-Media-Server/wiki/Turn-Server-Installation

For Android and iOS please see this reference;

https://stackoverflow.com/questions/62552158/how-to-add-stun-server-list-in-the-mobile-app

 

[Konrad Piwowar]

I just installed coturn on our servers - how does this work? Does it force EVERYONE over TCP or is it treated as a fallback?

 

 

[Robert Berger1648581691]

We cannot ask the customers to change their LAN network configuration.

 

I couldn't find an equivalent place to configure the Antmedia WebRTC JavaScript SDK https://github.com/ant-media/Ant-Media-Server/wiki/WebRTC-JavaScript-SDK-Guide to use a TURN server. This is what we are using to connect our webapp client to the Antmedia server. 

Could you show a code snippet on how / where to configure the WebRTC JavaScript SDK to use the TURN server?

Thanks

Rob

[Robert Berger1648581691]

I haven't had a chance to test this out, but it looks like what needs to be done is:

but do it when you call the constructor of the WebRTCAdapter, pass in 

```

'peerconnection_config': { 'iceServers' : [ { 'urls' : 'turn:<turn_server_address>:<port_number>' 'username': "username" 'credential': "password" } ] }

```

as described in How to add Turn Server to Ant Media sample pages

[Tahir]

Hi Rob,

 

Yes that is correct for javaScript, for android I sent you the stack overflow answer here; https://stackoverflow.com/questions/62552158/how-to-add-stun-server-list-in-the-mobile-app

 

Hi Konrad,

 

It does not force connection. There is a priority protocol in ICE, the official documentation is here; https://tools.ietf.org/html/rfc5245#section-4.1.2

Thanks

[Konrad Piwowar]

Hi Tahir,

Is it POSSIBLE to force or prioritize WebRTC over TCP, at least on the ingress end?

 

[Peter Miller]

Hi Tahir,

We installed a new VM with just the TURN sever and tested it successfully. So we know that TURN Servers is running.

We updated our webpage that we use for Demos so we could ask the Corporate Client to take a look.  We verified that the update to our Demo webpage is interacting with the TURN Server.

however the Corporate Client still sees a Black Screen where the 360 stream should be.

At the same time we see this:

Any suggestions on what could be blocking our stream to the Corporate Client?

 

 

 

 

[JLRishe]

A bit of additional detail to the post directly above mine (I am working with him trying to get this working).

We created a new server and installed coturn on it. We also opened all of the ports indicated on this documentation page.

We verified that it seems to be working correctly when we connect to it with Trickle ICE. We then updated the pc_config in our web page to indicate the url and credentials for this new server.

It seems that the WebRTC client is indeed using our TURN server now, since we can see activity being written to the coturn log file as we are watching a feed:

3634: session 000000000000000010: realm <xx.xx.xx.xx> user <turnuser>: incoming packet BINDING processed, success

3644: session 000000000000000010: realm <xx.xx.xx.xx> user <turnuser>: incoming packet BINDING processed, success

3654: session 000000000000000010: realm <xx.xx.xx.xx> user <turnuser>: incoming packet BINDING processed, success

3665: session 000000000000000010: realm <xx.xx.xx.xx> user <turnuser>: incoming packet BINDING processed, success

3675: session 000000000000000010: realm <xx.xx.xx.xx> user <turnuser>: incoming packet BINDING processed, success

3685: session 000000000000000010: realm <xx.xx.xx.xx> user <turnuser>: incoming packet BINDING processed, success

3695: session 000000000000000010: realm <xx.xx.xx.xx> user <turnuser>: incoming packet BINDING processed, success

3705: session 000000000000000010: realm <xx.xx.xx.xx> user <turnuser>: incoming packet BINDING processed, success

3715: session 000000000000000010: realm <xx.xx.xx.xx> user <turnuser>: incoming packet BINDING processed, success

However, the corporate user who had the original issue mentioned in this thread is still unable to see anything.

Can you suggest any further troubleshooting steps?

One part that wasn't clear to me - the provided documentation indicates that the TURN URL should be specified in this format, including a port number:

 'urls' : 'turn:<turn_server_address>:<port_number>'

However, there was no guidance about which port number to use, so we simply omitted the port:

 'urls' : 'turn:xx.xx.xx.xx'

I presume this was ok, since the WebRTC client does appear to use the TURN server when we view the feed, but please let us know if there is some port number we should be using there.

[Tahir]

Hi guys,

Yeah the port number should be given, coTurn by default uses 3478. https://meetrix.io/blog/webrtc/coturn/installation.html this is a useful guide for building coTurn

To understand what is going on with the TURN server, browser logs are very useful ( right click on the page- inspect - console ) so you can see the ice candidates there. Can you share them with me? 

To be 100% sure that the TURN is working you need to see something like;

sent message:{"command":"takeCandidate","streamId":"stream1","label":0,"id":"audio","candidate":"candidate:1654867310 1 udp 2113937151 23182a8c-9c9e-4806-9bdc-a4e509bb16f0.local 53518 typ host generation 0 ufrag eHqo network-cost 999"}

in the browser logs. See this is host generation type ICE candidate which means the IP address is directly sent from the host and it did connected because I am connecting inside my private network. What you are searching for is typ relay. If you can share the browser logs we can check it together.

Cheers

[Tahir]

Hi Konrad,

Yes it is possible. You need to enable TCP candidates from <AMS_INSTALLATION_DIR>/webapps/<your_application_name>/WEB-INF/red5-web.properties , add this line there;

settings.webrtc.tcpCandidateEnabled = true

One of our customers was reported that the tcp candidates making CPU crazy, however, we couldn't reproduce it although tried so much and the customer was not responsive. So if you face something like that please let us analyze the case if you are going to use TCP candidates.

Thanks