Asterisk 11.23.1 - FreePBX 13 - current with all module updates and patches - Whether Device And User Mode is set or not, when the base extension is called, the WebRTC phone never rings - I am sure this used to work!
The WebRTC phone can not ever be used in Device and User Mode. If you look at the setup of the phone (itâs a device in device and user mode). Itâs linked to a User. You would need to see what User the Device is linked to. I say canât be used with U&D mode because of how it works (EG Device is linked to a user which has multiple devices linked to it). I suspect the WebRTC phone doesnât have a user attached anymore for you. You can fix this by looking at the WebRTC phone and making changes
That is what I am saying - Device And User Mode on or off (per the Wiki) doesnât make any difference - the Web phone doesnât ring when you call the primary extension - And I could have sworn that it did at some point - we played with it, but did not have a use for it.
So Device And User NOT enabled - still doesnât ring when you call the primary extension (and I think it should).
Overview
The WebRTC Module allows an Administrator to enable a âWebRTC phoneâ that can be attached to a userâs extension which they can connect to through FreePBX User Control Panel, this WebRTC phone will then receive phone calls at the same time as the users extension using user and device mode behind the scenes. If you have User and Device Mode enabled any extension you enable the WebRTC Phone a duplicate extension of 99XXXX will be created (where XXXX is the original extension number), when the user then views the web interface of the WebRTC phone they will be connected to device 99XXXX which will receive calls from the original extension
Which is I guess what is confusing me - we did NOT have Device And User Mode - we havenât used that in a while - and the last time I tried using WebRTC, when I called the primary extension, the WebPhone rang - it doesnât now - I donât see anything in your post I havenât tried.
Perhaps I am not being clear enough in my responses.
Firstly, ditch user and device mode from your mind, just forget it. WebRTC uses User and Device mode behind the scenes but it doesnât matter? I think you are just over thinking User and Device mode. Remember that FreePBX is technically always working in User and Device mode even if you select extensionsâŚ
Now please do what I tried to state originally (but failed) in my first post and report back here.
So basically go here: config.php?display=devices
Look for 99{ext}.
See what User the device is linked to. Is it linked to anything?
No I get what you were talking about - I can see the extension in sip show peers:
994952/7qvq692f 10.12.24.101 D No No A 54576 UNREACHABLE
994953 (Unspecified) D No No A 0 UNKNOWN
994954 (Unspecified) D No No A 0 UNKNOWN
994955 (Unspecified) D No No A 0 UNKNOWN
994956 (Unspecified) D No No A 0 UNKNOWN
994957 (Unspecified) D No No A 0 UNKNOWN
994958 (Unspecified) D No No A 0 UNKNOWN
but it doesnât show under extensions, so I canât manipulate it in any way - and the machine that is logging in has the firewall turned off, but it is showing as unreachable even though it is fully pingable from the Asterisk - and under User Management it is indeed linked to the proper extension.
Agreed, but what can I check on the Box - The Windows Firewall is turned off completely and there is no other on the PC. The Sangoma firewall on the Asterisk is not even installed let alone turned on.
I am using stun.l.google.com:19302 as a stun server because WebRTC was complaining although with or without it doesnât make a difference - Is there a setting I am missing?
Even odder - Here is what I see when I log into UCP:
== WebSocket connection from â10.12.22.100:52569â for protocol âsipâ accepted using version â13â
â Registered SIP â994952â at 10.12.22.100:52569
but instantly I get this:
994952/7qvq692f 10.12.22.100 D No No A 52569 UNREACHABLE
from sip show peers
Is there somewhere that WebRTC could be thinking that it has a different address than what is actually there - Because my PC is finding the Asterisk, but the Asterisk does not seem to be able to get back to my PC.
No. Your IP and port are fine but Asterisk is unable to get a reply to the OPTIONS packet because a device on your network is not opening the pinholed port correctly. Unfortunately this is a network problem with your setup
Firstly, I would check out iptables manually to ensure there arenât rules in there at all (from CLI as root user);
iptables -L
Check out fail2ban - probably not getting banned, but I check itâs logs nonetheless because it takes ten seconds;
cat /var/log/fail2ban.log (I think, off the top of my head)
And, the ultimate tool to troubleshoot a network problem â TCPDUMP! (queue angelic singing)
tcpdump -nq -s 0 -A -vvv -i any host 10.12.22.100 and port 5060
You can drop the port filter above (assuming the webrtc phone uses 5060) and just watch every port between the phone and the server. Then you will pick up or give you a clue as to whatâs going on. Watch that output, when the PBX qualifies the extension (how it learns reachable or unreachable) youâll see your PBX send an OPTIONS like;
PBXIP send OPTIONS to 10.12.22.100:52569
10.12.22.100 send 200 OK to PBXIP:5060
You will see the PBX send th OPTIONS and you should see the 200 OK come back.
If you see no reply to the OPTIONS ping, then there is something between the PBX and the endpoint blocking it, or breaking this communication.
If you see the OPTIONS come back, check out the IPâs and make sure theyâre correct. If there is NAT in between, make sure that the IP is properly being replaced in headers, and that the PBX isnât seeing a private address where it shouldnât be, or seeing an address that it cannot get back to. Try pinging the endpoint from the PBX, does that work?
No, you all are missing above that I have two different system on two different networks doing the same thing - I could believe one but not two on VERY different networks.
And itâs not Fail2BAN or IPTABLES - I stopped them when I was testing.
I will do some packet grabs though - that should tell me what is actually happening.
Not a firewall problem and never was. I found this post here:
and it got me thinking - the farthest I could roll back to was 13.0.21 so I did and like magic, it worked:
994952/7qvq692f 10.12.22.134 D No No A 53547 OK (8 ms)
But if I roll up 10 13.0.26, like magic the problem comes back:
994952/7qvq692f 10.12.22.134 D No No A 53739 UNREACHABLE
Roll back to 13.0.21 again:
994952/7qvq692f 10.12.22.134 D No No A 53818 OK (9 ms)
And the phone operates like it should.
This test was done with Firefox, but Chrome behaves the same way - 13.0.21 and the phone registers and rings when called - any higher version and I am toast - on multiple machines - using Asterisk 11 and 13.
Works fine for thousands of others. @billsimon and I tested this extensively and we also use it for various other internal projects and it works fine. Unfortunately you are one person against many others.
Oh I have been summoned into another webrtc thread.
@GSnover do you have https and your cert in certificate manager all working correctly? Just be sure you are doing https and secure web sockets. If you are using plain or trying to mix the two then you will have unpredictable results. Browsers are getting more concerned about security and certs are free so there is no reason to do otherwise.
No, I am not using HTTPS and did not really want to - is that a requirement now?
Looking at the wiki here:
It still says âLogin to the User Control Panel ( http://yourserver/ucp )â - are you saying that the UCP login should be in HTTPS? If so, we should probably update the WIKI.
I am not against anybody. I am trying to make something work that used to work before and now (obviously) has different undocumented requirements - I am sorry this thread is so annoying to you - please drop out as you have provided NOTHING useful in this thread except telling me to chase the firewall which was NEVER the problem.
Thanks for the idea Bill - I will re-upgrade the module and switch to using straight HTTPS and report back