WebRTC line is not registered (Desktop App)

[KjetilSorby]

Hi!

We experience from time to time getting the following message: "WebRTC line is not registered" We then have to close and restart the Desktop app to make it
work. Desktop app is used with Jabra headset and jabra Direct installed and updated.
This often happens if the PC has been left on overnight.

Is there a fix for this?

 

[Kiwiastra]

When you have this problem again, can you try next?
Don't close the desktop app, juist open the webclient and click on reprovision.

 

[Scott D]

I've experienced this too. Some further details:
- Server version 18.0.5.418 (but has happened on previous versions)
- Ver 18 Web client on a Windows Surface Laptop, but have seen it on HP laptops, all running Win10 Ent.

Trigger:
Laptop has been moved from dock or cabled network connection to wifi, or back again (so, possible momentary network connection interruption), or
Laptop has come back from sleep/low power mode, or
Client has been running without restart for some time (days) and any of the above events could have happened in that time, but the client was not used, so difficult to match exactly which event caused it.

Either way, as best I can tell, it's an interrupted network connection that is quickly resolved automatically by Windows, but 3CX must lose connectivity temporarily and not recover from it.

The issue I have is: with the v16 client there was an easy to find "re-register" option. With v18 it requires a full Quit of the app and restart, which is not show-stopping but is inconvenient. Also, the lost of registered connection in the v16 app was obvious - nothing showed on a call board and any BLFs were clearly offline (I think there may have been error message displayed on the phone?). With v18 it still shows the "last" info, including calls that were happening at the time, people online, etc - so at a quick glance everything looks ok, and it's not until you go to do something like make a call that you find out that you've actually be offline for some time.

Given I, like I assume many other people, spend a lot of my day going from my desk+dock to meeting rooms and on the move, I'd say:
- The v18 web client appears to be less resilient to network connectivity changes, and
- it also is less obvious when it has these problems, and
- the resolution is more annoying.

 

[Vivian1]

We experience the same here on WIndows and macOS Systems:
Desktop App mac: 18.10.461
Server Version: 18.0 (Build 418)

After the desktop client is in standby the app is not reconnecting the WebRTC line. A complete Desktop App Restart is necessary to reconnect. It would be great, if the reconnect could happen automatically on connection loss.

 

[Tynan E]

The "WebRTC line is not registered" error has been ongoing for a number of months on different 3CX PBX and Web App versions. I've ended up creating a forum account to specifically highlight this error affecting our client.

Our client's 3CX environment utilizes the following at this time:
Enterprise Annual - 18.0 (Build 418)
3CX Web App Version 18.10.461
The client's laptop fleet is HP, all devices are running Windows 10 Version 22H2 Enterprise / Pro.
Jabra Direct is installed on the laptops, peripheral audio devices are running their latest firmware.

Issue Description:
The dialer presents with the "WebRTC line not registered" when attempting to make an outgoing call or self-test *777. Transferred calls fail to the user's extension when the Web App is in this state. The audio/video settings also appear to be greyed out / locked up while the app is in this state. Attempting re-provision via the browser for the web app has no effect.

Cause:
Similar to Scott D's findings, we've found this is related to network configuration changes, where the Web App loses its provisioning.
- Laptop has been moved from dock or cabled network connection to WiFi, or vice versa (network change).
- Laptop has returned from sleep mode.
- Laptop network adapter has went to sleep/waking.
- Network steering software (such as Netskope). The WebRTC error was observed to still occur even when the software was disabled.
- Initiating VPN connections.

Workaround:
The web app needs to be closed / exited via the system tray, and restarted via Start Menu.

WebRTC Error - 3CX Logs - Snapshot:
----------------------------------
[2023-02-07 18:35:27.701] [warn] (provisioning-process.class) provisioning failed, reconnects in 5000 ms
[2023-02-07 18:35:32.718] [info] (remote-file-reader.func) remoteFileReader https://[Redacted].3cx.com.au/provisioning/[Redacted].xml
[2023-02-07 18:35:32.724] [info] (remote-file-reader.func) remoteFileReader https://[Redacted].3cx.com.au/provisioning/[Redacted].xml
[2023-02-07 18:35:32.738] [warn] (provisioning-process.class) {
name: 'ElectronFetchError',
message: 'request to https://[Redacted].3cx.com.au/provisioning/[Redacted].xml failed, reason: net::ERR_INTERNET_DISCONNECTED | request to https://[Redacted].3cx.com.au/provisioning/[Redacted].xml, reason: net::ERR_INTERNET_DISCONNECTED',
type: 'system',
code: 'ERR_INTERNET_DISCONNECTED'
}
[2023-02-07 18:35:32.744] [warn] (provisioning-process.class) provisioning failed, reconnects in 5000 ms
[2023-02-07 18:35:37.758] [info] (remote-file-reader.func) remoteFileReader https://[Redacted].3cx.com.au/provisioning/[Redacted].xml
[2023-02-07 18:35:37.764] [info] (remote-file-reader.func) remoteFileReader https://[Redacted].3cx.com.au/provisioning/[Redacted].xml
[2023-02-07 18:35:37.773] [warn] (provisioning-process.class) {
name: 'ElectronFetchError',
message: 'request to https://[Redacted].3cx.com.au/provisioning/[Redacted].xml failed, reason: net::ERR_INTERNET_DISCONNECTED | request to https://[Redacted].3cx.com.au/provisioning/[Redacted].xml failed, reason: net::ERR_INTERNET_DISCONNECTED',
type: 'system',
code: 'ERR_INTERNET_DISCONNECTED'
----------------------------------

There is no indication that the 3CX web app is experiencing the issue, until the error is encountered in an actual use case - which is leading to frustrated external callers. Echoing Scott D's comment, the web app doesn't appear to be resilient when it comes to network changes.

Any assistance or feedback would be most helpful.

 

[Mark Hirst]

We are getting exactly the same on all of our 3cx instances and seeing the same behaviour as Tynan. this needs fixing as a priority.

We've tested this with and without different headsets/plugins/users and it all comes down to the fact that it does not recover from a network "break". usually through coming out of sleep mode, but also seen it when moving between Wi-Fi and wired connection.

 

[Charles_3CX]

Regarding your question and from the description of the cause, and if I have understood correctly, the desktop app is left open after the computer hibernates or sleeps or network connections are closed or changed, so the networking is stopped, and the desktop app disconnects.

net::ERR_INTERNET_DISCONNECTED

Therefore, the advice here will be to either set the power mode not to sleep/shut down the nic or close the desktop app and re-open it after the computer wakes up and the network is available. This particularly applies when changing from doc, wifi to lan, etc., as Ip addresses may also change here, depending on your network's configuration.

The bottom line is if networking is lost, the app will disconnect, and reconnecting requires it to be restarted due to the network being unavailable.

Having said this, I have performed some tests with the latest Update 6 and the latest desktop app version with tested headsets (Yealink). However, in my case, no software to interfere with the traffic was installed, and by switching the network from Lan to Wifi, I could not replicate this issue. The Desktop app reconnects after a short period once network connectivity is re-established.

Therefore, I recommend updating the system to 6 and the desktop app to the latest version and then checking the laptop and the networking side.

 

[Tynan E]

Hello Charles,
Thanks for your response, however your understanding is not quite correct.
In short, the WebRTC error is being encountered simply whenever there is a network configuration change. This could be simply docking a laptop (WiFi > Ethernet), resulting in a network configuration change that effectively breaks the web app. The networking has not been 'lost'.

The error logs I have provided were on a laptop device that was connected via ethernet, with internet connectivity, and yet it was producing the net::ERR_INTERNET_DISCONNECTED continually in the logs, despite there being internet connectivity clearly present for an extensive period of time.

I'll clarify again, that the following instances are most likely to cause the "WebRTC line is not registered" error to occur:

- Laptop has been moved from dock or cabled network connection to WiFi, or vice versa (network change). There has been no loss of network connectivity, simply a network change. The WebRTC error is encountered.
- Laptop has returned from sleep mode, and proceeds to re-enable network connectivity. Despite re-connecting, the WebRTC error is encountered.
- Laptop network adapter has went to sleep due to device manager power settings (devmgmt.msc), and has now woken up.
Despite re-connecting to the network, the WebRTC error is encountered.

In all cases, there is network/internet connectivity available. The web application simply not detecting it.

Thank you for your other suggestions, but we already attempted them.
- We already turned off the setting which was set to allow the NIC to be suspended/turned off to save power. No change.
- We attempted turning off all sleep settings on the laptop devices (whether on battery, or plugged in). No change.

I'm not convinced that updating the PBX System to Update 6 is going to resolve this, given that this has been long-standing and presenting on several prior updates beforehand with continuous recommendations to simply 'update the system' via support tickets, yet leading to no change in behaviour. Our own managed IT services company has only just recently upgraded to Update 6 as part of our pilot testing before roll-out to other clients, so we won't be doing so immediately at this time.

Is there any release notes that you can provide that indicates Update 6 addresses this issue? I don't see why a web app is not resilient enough to detect when there is valid network/internet connectivity, requiring it to be fully closed and restarted. It does not solve the issue, it's requiring us to workaround it reactively.

 

[Mark Hirst]

Regarding your question and from the description of the cause, and if I have understood correctly, the desktop app is left open after the computer hibernates or sleeps or network connections are closed or changed, so the networking is stopped, and the desktop app disconnects.

net::ERR_INTERNET_DISCONNECTED

Therefore, the advice here will be to either set the power mode not to sleep/shut down the nic or close the desktop app and re-open it after the computer wakes up and the network is available. This particularly applies when changing from doc, wifi to lan, etc., as Ip addresses may also change here, depending on your network's configuration.

The bottom line is if networking is lost, the app will disconnect, and reconnecting requires it to be restarted due to the network being unavailable.

Having said this, I have performed some tests with the latest Update 6 and the latest desktop app version with tested headsets (Yealink). However, in my case, no software to interfere with the traffic was installed, and by switching the network from Lan to Wifi, I could not replicate this issue. The Desktop app reconnects after a short period once network connectivity is re-established.

Therefore, I recommend updating the system to 6 and the desktop app to the latest version and then checking the laptop and the networking side.

I understand all of that Charles, but we've see this for several iterations of client and system and it's still not working.
I'm also concerned that the app is not resilient enough to handle this and automatically reconnect, as most other apps do (Outlook, Teams etc).

Often the first time people realise that this is an issue is when they receive an incoming call that they cannot answer, and this is neither professional or satisfactory when we are trying to get people to work with the application and trust it as their core phone system. I would also say asking people to close and open the app all the time is not sustainable and putting in place workarounds for this issue is simply not scalable or manageable for something that should be able to handle this modern way of working "out of the box".

Thanks

 

[Scott D]

Regarding your question and from the description of the cause, and if I have understood correctly, the desktop app is left open after the computer hibernates or sleeps or network connections are closed or changed, so the networking is stopped, and the desktop app disconnects.

net::ERR_INTERNET_DISCONNECTED

Therefore, the advice here will be to either set the power mode not to sleep/shut down the nic or close the desktop app and re-open it after the computer wakes up and the network is available. This particularly applies when changing from doc, wifi to lan, etc., as Ip addresses may also change here, depending on your network's configuration.

The bottom line is if networking is lost, the app will disconnect, and reconnecting requires it to be restarted due to the network being unavailable.

Having said this, I have performed some tests with the latest Update 6 and the latest desktop app version with tested headsets (Yealink). However, in my case, no software to interfere with the traffic was installed, and by switching the network from Lan to Wifi, I could not replicate this issue. The Desktop app reconnects after a short period once network connectivity is re-established.

Therefore, I recommend updating the system to 6 and the desktop app to the latest version and then checking the laptop and the networking side.

Thanks for responding Charles.

I will admit getting examples of this is going to hard - for me and my team it does not happen //every// time we move from networks or come back from sleep, just sometimes. So I'm assuming it's just bad timing for a heartbeat or some form of process (local or server side) that attempts to do something while networking is not available, and the desktop app is then offline without visible failure.

I understand that the desktop app is effectively just a browser/wrapper for the web version anyway, and I think that may be helpful to dive into. In the same way that a web page of any kind with a session can time out or fail if network connectivity is lost or if the laptop went to sleep, I get that this would happen with the 3CX web client. In all those cases, including the 3CX web client, I just refresh the page and everything gets back to normal, registers, etc. However there is no Refresh or Re-register on the desktop app, just a webpage stuck on the way things were whenever it stopped working.

To get to the core of the problem: Using the desktop app:
- it can randomly end up in a disconnected/failed state;
- I can't easily tell that this is the case; and
- when I discover that it is, the process is annoying (killing the app via the system tray, and restarting it), and not as simple and well known as "just hit F5".

Of all of these, the biggest problem is the app being in a failed state but looking like it's still live. If there was some way for their to be a visible notification of the problem, before we go to attempt to use the phone or find that people have been trying to call us, even if that is as simple as to show no data at all, no calls, extensions, etc... Well, it's not a solution, but at least then I wouldn't look like an idiot waiting for a call that will never come.

 

[SteveITS]

> I can't easily tell that this is the case

Since there is a Disconnected message displayed when Internet drops, I wonder if that implies the app isn’t detecting it as a drop…

 

[Tynan E]

I concur with Scott, and I should clarify that we have the same behaviour. It doesn't occur every time; just sometimes.

If closing the app and restarting it is really the only way to rectify the error - is it not possible to automate this into the desktop web app?

For example, if the web app loses its provisioning due to believing there is no network connectivity (net::ERR_INTERNET_DISCONNECTED), can the desktop web app be set to automatically close and restart after X seconds (eg. 30 seconds) of failing to re-provision?

At least this way, the likelihood of having this handled reactively is dramatically reduced, leading to less disgruntled callers.

As per Scott's recommendation, it would really help to have a visual indication that something is wrong with the desktop web app, before finding out the hard way.

The ultimate however, would be for the desktop web app to properly detect when network changes occur, like other modern apps. A solution where we don't need to close and restart the app at all.

 

[Mark Hirst]

Hi all. I've now got a whole group of people in our business reporting this and getting quite frustrated. It seems to be occurring for us in the following situation -

1. Every time and replicable

• Device is going into low power mode through settings
• Device is then in that state for a long period
  • Done some testing but can't find out what that time is or see anything obvious in event logs

2. Occasionally

• Device is disconnected from the network
  • Either through a Wi-Fi move or Ethernet to Wi-Fi move (docking station disconnect)

The overnight, low power mode is the one most complain about especially given the lack of knowledge of it until the error comes up.

In an attempt to workaround this for issue 1 and ensure users do not see the system as "broken", and maintain them using the system, I've gone a little old-school but thought I'd share. We have pushed out a scheduled tasks to all devices that fires on workstation unlock. this contains a batch file (I know, I know - like I said, old-school) that detects if the system is running, kills the process and restarts it for them. I've also built in that if it is shut down it forces it to restart to encourage them not to exit the app to avoid calls. Batch file is below -

@echo off
SETLOCAL EnableExtensions
set EXE=3CXDesktopApp.exe
FOR /F %%x IN ('tasklist /NH /FI "IMAGENAME eq %EXE%"') DO IF NOT %%x == %EXE% (
GOTO NotRunning
) ELSE (
GOTO Running
)
:NotRunning
start C:\Users\%USERNAME%\AppData\Local\Programs\3CXDesktopApp\%EXE%
EXIT
:Running
taskkill /F /T /IM %EXE%
timeout /T 1 /nobreak
start C:\Users\%USERNAME%\AppData\Local\Programs\3CXDesktopApp\%EXE%
start c:\Tools\systemtrayrefresh.exe
EXIT

I will develop this further and probably into a VBS file for more features, but it is working OK with my test group and is helping to maintain engagement, so thought I'd share.

Still disappointed I needed to do this, and would still like a proper user focussed fix from 3cx, but it does the trick for now in most instances.

 

[Terry_S]

I would like to chime in and use the "happens to me too" button.
I cannot add more details as what has been discussed previously, except we haven't been as deep in troubleshooting as what I've read on this post. We do see this happen most on machines for general purpose (like our shops) or external sales people. Those machines have a history of long uptime, which would confirm some tested theories above.
in our case, restarting the desktop app (18.11.1213) doesn't always seem to solve the issue though.

Hope a user oriented fix will be added in the client in the future, something like a color coded connection status and a reconnect button (in the same way updates are presented).

 

[Nico Haas]

Same Issue here, since last Update several Notebooks show this error after re-switching from Screensaver/Sleep Mode. Even power and Network Cable pluged in.

 

[hwsknudsen]

same issue here seems tied to change in network connectivity e.g. anyone using a laptop

 

[GuillaumePerrin]

Same issue here. Restarting the computer solves the issue. But users are annoyed. Every other software manage to work and find the network after a brief network outage or resuming from sleep. Why 3CX can't?

 

[cjean.fr]

Same problem as described. I hope 3CX will fix this issue (a fix not a workaround).

 

[Phone systems NZ]

Sounds like an issue i had on a site once back in October 2022.
I was able to get around it by tracking it down to pc network card settings where if they had either 8.8.8.8 or 8.8.4.4 ,manually set as there Preferred or alternate DNS server under "use the following DNS server address"

Setting this to Obtain DNS server address automatically fixed the issue. I did report this to 3CX but heard nothing back from them.

 

[MCNY]

We also have received this error when someone's laptop comes out of power save. It happens rarely, but it is a big deal to someone that can't answer the phone.