Vodia PBX

Yes that looks okay. We still have the topic of the buttons which is another tricky area with the Grandstream phones (every model seems to have their own PXX values ) and for that we would have to change the models.js but lets do one step at a time...

As for recording there is no need for *93 or *94, you can use the button for that (it even starts blinking when recording is on).

Hmm, it's not clear when the wss://user:pass@domain URI will work, but it's probably not a good idea to rely on it. But for sure setting a cookie should work. That means you'll need a step before opening the web socket and fetch the session cookie first using /rest/system/session like you would login from the welcome.js code.

According to https://stackoverflow.com/questions/4361173/http-headers-in-websockets-client-api you should be able to use the username and password in the URL and this should just work?

Hmm that might work depending what you use (e.g. C#, JavaScript). On the protocol layer, there needs to be an Authorization header with Basic authentication that contains the username:password (no tenant name there) and the Host header needs to contain the tenant DNS address.

If all does not work, rename the DNS address of the tenant and then rename it back. This should generate a fresh certificate.

Yes its possible, but not easy. You need to change the pop_grandstream.xml file and then add a new entry for the new file. The new file must be in the file system because there is to existing file built-in. If you put the pnp_grandsteam.xml into the file system as well you'll need to restart the service to have the PBX pick up file changes.

I don't know... What is your expectation regarding WhatsApp? Does it ring only when you have it open? How do you know that someone wants to call you? LOL should they call you on GSM first? Or am I misunderstanding something here.

It's not outrageous, if you really have a case where there are a lot of redirections the value of 10 might be indeed too low.

Yes, see the post from March 25...

Please try again we made the Windows build.

So in a nutshell, you want to show the early state for all calls unless they are talking to an agent?

Well there is a global setting called max_loop that you could increase. You can do this in /reg_settings.htm by clicking on the edit symbol in the header without having to edit the pbx.xml file and restarting the service.

You can try version 68.0.3 if it works for you. That one should have the cipher.

Try to set the transport layer to TCP and reprovison the phone. Maybe you try TLS and the phone does not like the certificate of the PBX. You would see that actually in the log if you turn pin the log level for TLS, however its very noisy.

Well in that case as a first step I would turn the SIP logging on (possibly just filer by the IP address of the phone if possible) and see first of all if there are any packets and if yes, what the PBX response is. Maybe there is just a codec mismatch. But there should be some clue where the problem is.

Can you call other extensions? Or the mailbox? Then the problem would be somewhere with the dial plan and the trunk.

Are you using a ATA or the user front end?

Well that's not how app are supposed to work... The app is actually easily drifting into the background e.g. when you switch to another app and the OS is quick to completely remove it from memory. When the user wants to use the app, the PBX still needs to use the wakeup service to deliver a call or message. I think what we really need is to split the "call app" flag which we already have into "call mobile app" and "call desktop app". That flag would actually be available also on the desktop app, so that the user could turn the iOS app "on" from there as well.

I think its okay. The PBX needs the record only when trying to register and after loosing the registration. Refreshing the registration does not need a DNS lookup even if the DNS record has already expired (this is something you can actually set on the trunk).

The ringer topic was a difficult one, it took many iterations to sort of get this woking on all different platforms (hopefully we should have most of the problems solved in 68.0.2). One important point that makes life easier is to tell the browser to allow audio playback for the user portal, so that all those things we do to allow audio at least after one user interaction are not needed. And the other problem is to clear the cache, which is relatively easy with the browser however the apps don't have such a refresh button.

There was a fix for that in 68.0.2 when the first page was not complete and the second fax happened to be on the same call slot.

There are several things here that are mixed up. The fundamental issue is that employees don't like calls outside of "working hours" (whatever that exactly is) or on unrelated topics (e.g. support calls). As for the working hours, there are several things possible today: Service flag: This works well if the employee has more or less fixed hours. The service flag defines when the app and the cell phone gets called (desktop phones get called anyway as they are supposed to be in the office). For example, you could set up 8 AM to 6 PM or maybe 9 AM to 5 PM depending on how tolerant you want to be and you can define what days are holidays. This can be defined per tenant or per extension. DND: When it is difficult to define fixed times, an employee can just use manual do-not-disturb. This can be done (as of 68) for a few minutes, until the end of the day or until the end of time. This method can be combined with the service flag. It's easy to do from the app but its also easy to forget thus the time features. App flags: A little bit more inside the app, the app offers control over which device class gets called. We have currently app (which might be too broad considering that iOS app and PC app are in the same class), VoIP phones and mobile phones (GSM). This is a manual process. iOS 15: Lets not forget that Apple has introduced "focus" where you can define what app can interrupt a user. This is a fantastic feature, because it can use e.g. the geolocation instead of a fixed time schedule. And it is also great because if can mute unwanted apps while working, further reducing the number of interruptions and improving the work life balance. Lets see what Android comes up with, there is already a work profile and a private profile it might be not too hard to enable or disable them similar to what Apple has done. Completely unregistering the phone at the end of the day sounds to me like a misunderstanding of what the use case is. As far as the topics are related, this is largely related to logging in and logging out of a queue. That means largely logging in and logging out of a queue. So far we have seen only few agents using the mobile apps (might be changing), but the PC apps have the login and logout flag in the queue view.

You have to keep in mind that records that have expired are not shown in the list any more. Maybe the _sip._udp record had already expired? That would be totally fine. You can turn the logging for DNS on, maybe that contains another clue. For example, maybe you are talking to the wrong DNS server.

Yes the term "app" is misunderstood by many people. We'll need to figure out how to separate "mobile" from "desktop" or just have that flag really just for that one device.