I'm at my wits end with this one...
I'm running the most recent Thirdlane 9.0.2 with Connect 2.0.2.
I have working STUN and TURN servers setup and I've tested them using TrickleICE (https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/) So I know they are passing values for outside IP and relay to the client. One of these is the CoTURN that's installed with the Thirdlane appliance. I'm using default ports.
If I enable or disable the STUN/TURN servers has no effect.
If I drop the iptables firewall has no effect.
The Connect client simply refuses to setup a webrtc connection to the telephony server. So calling is disabled in the connect app. Same for all platforms I've tried; Chrome, Windows, and Android.
However, I can get status updates and check voicemail with audio working for the voicemail.
My Thirdlane is multi-homed single-tenant. I have a public IP on one interface and two LAN interfaces. One LAN connects to the local handsets, the second to the AT&T SIP gateway. Default route is setup to go out the WAN interface with the public IP. I use static routes to handle the LAN subnets.
Everything had been working some time ago before I switched to a Go Daddy cert. This was due to problems getting the previously used Let'sEnrypt cert to renew itself without issues. After beating my head against the wall long enough on that issue I went to a GoDaddy cert. Then Connect quit working. At first I couldn't log in at all due to some leftover config with specifying the intermediate certs that I didn't do at first. Did that and then I could log into Connect. But then the problems with WebRTC cropped up.
I initially had challenges with WebRTC when we first deployed and I was able to resolve them at some point. This time no go.
I get log entries like this in Connect...
[8/17/2018, 4:30:27 PM] [WebRTC Srv] - A sudden disconnect. Attempting to reconnect in 10 seconds
Other log entries are not very usefull and I must say this one isn't offering many clues. Running asterisk -rdddddddddddvvvvvvvvvvvvvvv from bash cli shows a log of entries like
chan_sip.c:4208 __sip_reliable_xmit: Serious Network Trouble; __sip_xmit returns error for pkt data
These go away when I flip my extension back to SIP from WebRTC.
Anything I should try? Or logs you'd like to see?