Open alper-yilmaz opened 2 years ago
This behaviour is experienced on mobiles and tablets, yes, you are correct. This is a power a resource feature that is simply not going to go away, and there isn't anything you can do about it. In fact it may even get worse. (iOS for example, shuts down any network connections immediately as the app goes into the background!)
Here is the thing... as it stands the browser phone has all the feature and functionality to be a fantastic Mobile Communications app, but it was only ever designed to be a Desktop PC web application. Bringing it over to the mobile and tablet space does require a re-think of some of these fundamental things. I'm busy building both an Android and iOS app that will "contain" the browser phone in a full screen webview - but will tie in all the native features of their respective operating systems... so for example, on iOS, it has full CallKit integration and features like ring tone etc are handled by the native code rather than the Browser Phone web code.
In both cases, normal calling is fine, Android seems like it will be 100% compatible, but iOS has much better tools like CallKit etc, that make development easier. Inbound is less simple - iOS does have a permission problems with the audio routing, and can't use the mic from the background (like callkit!), but im hoping in time this will be resolved.
So far Android, although more difficult to develop, looks like it will be able to host the webview with 100% of the feature we are used to, so long as you handle things like call management, audio routing, etc natively. If you are to develop something like this you would need to get familiar with the web hooks, and also be prepared to send your device a (voip) push to wake the app, register it, and ready it to receive a call.
If this is too ambitious for you, ill be making these apps available via a commercial service (hopefully by the end of the year), called SIPERB: https://www.siperb.com/ Add your self to the mailing list, and ill keep you posted. There will likely be some kind of free and paid version depending on what you use.
Thank you for your answer. But the problem I am talking about is not on mobile devices. I have this problem in PC usage. As far as I know Chrome or other browsers put the inactive tab to sleep. How can we overcome this problem in PC usage?
I have not come across this, not in a while.
There used to be something that Chrome tried - Discarding. I believe Edge and Firefox also have some sort of Low Memory Management - Either way, they almost all have a way to disable this feature.
Just disable it.
Maybe your issue is that when you open the browser phone you need to click somewhere because if you dont click it will not play the ringing sound , not sure if there is a way to fix this. Here is the console log : phone.js:1923 Unable to play audio file. DOMException: play() failed because the user didn't interact with the document first. https://goo.gl/xX8pDD
@edimondi that is unrelated.
But, what you could do is make a browser extension. This is also something that will come with the SIPERB solution. Basically, it’s code that runs in a background service that is always connected to say a web socket, or it can use the browser push service (something that I have not tried yet). Either way, it’s code that keeps active and awake even if you don’t even have Chrome Open! When the push message (of your own creation) arrives it would just need to launch the browser phone page, it would then automatically register, and that registration can signal to your dial plan that the device is ready to receive the call.
If the tab is in the background or minimized, the incoming call will not ring after 15-20 minutes. This is because the browser stops the app in the background. How we can solve this problem