Your problem? Sound familiar – Webmeetings is up and running but no voice or video and you can’t share your screen with the Spreed.ME chrome plugin.
There are plenty of topics around STUN and TURN services as well as port access configuration that could (and very-well MAY) come into play for you here.
HINT: Start simple.
Scenario 1: if two users are in the same open layer 3 TCP/IP environment that does not have NAT they should be able to connect to one another over WEBRTC straight-away with the out of box configuration. If they can’t turn off your PC firewalls or enabled logging and start opening up ports. Machines can’t talk WEBRTC without some open ports in the personal firewall without the use of a STUN/TURN enviornment.
.Scenario 2 – let’s say you have 2 people conferencing. Now you want 3 or more but only two parties can connect. There’s a learning curve with the software. When people click on links to attend a webmeeting they are simply placed in the same room, but they are not connected. The host calls the first attendee or the other way around and a conference is created. But now there’s an admission problem when the 3rd person comes into the room and tries to join in. The answer? One of the people already connected needs to call the person wanting to join. Nothing will happen until one of the people already meeting initiates it. The people in the active session will appear “busy” if the inactive person tries to call them.
REPEAT: when conferencing three or more people – the people already on the conference have to call the new party.
Once you get this working you can start bringing other things like choosing where you want to host your private STUN and TURN server from there.
Keep in mind that the party that controls the STUN server controls your universe. This absolutely needs Fort Knox level HTTPS encryption and it needs to live on a server that you control either by owning it or by having iron clad contracts.
One thing worth noting – COTURN works well with UCS appliance Kopano Webmeetings but you have to do some detailed configuration to make it work. Its documented in the Kopano site, not at UCS.
In my environment I have many layers, one public IP, and numerous antonymous interior firewalls that each connect into my DMZ segment with their own IP.
PAT = Port Address Translation – a type of NAT. You map any one of the 65535 TCP or UDP ports from the untrusted exterior interface to an interior host… you can even do it on another port if you want to…
Its a fairly tightly guarded environment obviously. There are some things that are interesting about PAT – you can even make all ports (and possible iterations of unused destination IP for that matter) funnel down to one host:port if you want to. (great for NIDS, BTW)
Here is the type of environment I was challenged to make WEBRTC run in:
+-- DMZ segment -- Firewall#1 PAT -- user1
internet router PAT — DMZ segment – Firewall#2 PAT – user2
+ - DMZ segment -- Firewall#3 PAT -- user3
--- DMZ UCS
+- DMZ ReverseProxy
+- DMZ STUN/TURN
Notice that “User3” can get to STUN/TURN without any NAT while User1,2,and any external internet users will always encounter multiple layers of NAT.
What I found is that basically NO combination of setting or not setting an external IP or setting STUN and TURN by IP or DNS in the application gave me a working STUN and TURN setup in all scenarios.
Eventually my Kopano Meetings configuration focused exclusively on using server name for these resources. My DNS is hosted externally and my firewall has request re-writing capability so I could consistently make users behind each firewall resolve DNS as expected. BUT that did NOT make my sockets for conferencing correct!! Things would die due to invalid request vs payloads right on the participant machines because the socket rules were wrong in some instances.
The answer? Multiple external-ip statements in the STUN/TURN config.
external-ip=REALPUBLICIP/TURNERVERIP
external-ip=FIREWALL#3DMZIP/TURNSERVERIP
Next – do STUN exclusively through HTTPS and TURN exclusively through UDP transport.
Make sure that in addition to the ports specified in COTURN config open I also had 49152-65535 open and forwarding to the STUN/TURN server in all scenarios
Bingo … every scenario I have thrown at this from a PC now solid and just works.
Next problem – mobile devices. iPhones particularly.
I’m battling an issue with the /webmeetings/api/vi/config returning config without a STUN server right now so it Spreed.ME client doesn’t actually work…
In order to get a start at making it connect you need to adjust your webmeetings.cfg.
There is a template file that randomly overwrites this – so once you figure it out update the template too or it will randomly break.
Look for “; Set to true to enable user functionality.”
Change this line:
enabled = true
To
; enabled = true
enabled = false
The other thing I found is the presence service built-in was uncooperative. My solution for now was killing the image, building a docker swarm, and pulling down the presence server image from Kopano directly and setting it up from there.
Only after I had overhauled the presence server was I able to consistently get multiple internal and external parties on a conference.
Mobile devices … still not working. Probably won’t work and, well “not supported”…