Dialling from the UCP is still listed as a bulletpoint for the appliances for sale. I’ve tried this in Chrome, Firefox and Safari and it does not work due to lack of browser support of lack of WSS in FreePBX.
Under what conditions does WebRTC actually function?
Just FYI safari has no support for webrtc. Doubt it ever will.
Yes, I know. I’m hopeful for change though, they may implement it at some point. If that happens, I’d expect them to require WSS though.
So the question remains. WebRTC calling is a listed feature for FreePBX. Under what conditions does it work?
Older version of Chrome work. And once we get a moment to wrap up our SSL items in FreePBX WSS will work
Gotcha.
Hope that’s the "letsencrypt’’ stuff. That’s going to be sooooo useful!
Good luck with it.
[edit: typo and subsequent grammar change]
You can see some of our work here: Drop requirements from PHP 5.4.8 to 5.3 by tm1000 · Pull Request #9 · analogic/lescript · GitHub
If you haven’t tried it yet, the updated Certificate Manager with Let’s Encrypt and secured WebRTC are working great. Thanks @tm1000!
we enabled this last night and the cert is working perfectly now. the only thing that started happening is now the webrtc clients are in an unreachable status. they can make outbound calls but can’t receive. we created the test ones from scratch with the same problem.
Get some log info and see when they go unregistered. Maybe your browser is closing the socket after some time. It stays connected fine for me in Chrome for Mac.
they actually stay registered as far as chrome/ws can tell, that is the strange part. any idea where else I should look? I get the same thing when I connect directly using the jssip demo site: https://tryit.jssip.net/
This is usually caused by something blocking the STUN server lookup. tryit and freepbx both use “stun:stun.l.google.com:19302” however that can be changed in FreePBX under Asterisk SIP Settings.
If you are blocking stun:stun.l.google.com:19302 you’ll have issues with audio
hmm actually we were using the free twilio one global.stun.twilio.com:3478?transport=udp let me try swapping that out and see what happens. we can definitely place calls from both jssip demo site and ucp but inbound is the one causing the issue since the client is unreachable and asterisk throws up a congested message
putting “?transport=udp” will cause issues with asterisk. WebRTC traffic isn’t UDP anyways (It’s websockets so it’s TCP) so even removing that might help you out.
The STUN server can causes issues with audio and inbound calls as it’s the only way the web client knows it’s external ip address. Though on tryit the STUN server is forced so you may be getting blocked by something else.
Furthermore the STUN server isn’t actually defined anywhere in the jssip tutorials or documentation, You have to dig through their codebase on tryit to actually see what they are doing, which is why FreePBX does this as well (otherwise you’d have issues)
isn’t the stun server different than the ws connection? all it does is help the clients discover the best path to connect (local, lan or wan) and the websocket handles signaling? twilio has a tcp version as well but ill use google for now.
looks like they let you set it manually using: peerconnection_config, tryit has a small, almost hidden advanced section
changing it over to google didnt help 
let me delete and recreate all the users and extensions and try on the ucp only
Get it working on tryit first. Once you’ve done that then try to work through FreePBX
same :-/
have any of the default values changed with the recent webrtc module updates? I had a previous user and extension that I swear was receiving calls but deleted it and now any new ones added do this.
tried disabling the server firewall just in case.
here is what I am seeing in sip peers:
any other ideas?
Well yes several of the default values changed in WebRTC. However, that’s what started making it work for myself, Bill and others. So I doubt it’s those settings.
The problem is right there your host is unreachable. So the call can’t be passed through. Looks like a firewall issue to me.
yes unreachable is what we have been seeing
Can you pastebin a sip debug from Asterisk of that peer? including the initial registration (opening the client on the browser)
Y.Y.Y.Y is the server IP and X.X.X.X is the client IP, they are not on the same network
http://pastebin.com/raw/grQ70kcD
registration from the asterisk log:
[2016-05-17 22:20:51] VERBOSE[6543] res_http_websocket.c: WebSocket connection from ‘X.X.X.X:55320’ for protocol ‘sip’ accepted using version ‘13’
[2016-05-17 22:20:51] VERBOSE[6543] chan_sip.c: Registered SIP ‘99123’ at X.X.X.X:55320