Vodia PBX

Version 64 has a new feature - bulk change of parameter in the extension list. You will still have to know what exactly to put into the parameter , but it is a lot easier than to make a CSV file.

That is "0" seconds, or just "" seconds. It means that for whatever reason the timestamp for that call is not there.

We are planning to release 64.0 today or at least in the next few days if anything goes wrong. So it might be worth waiting a little bit.

Obviously the opus.dll is missing. After all, this is not a release just a daily build. The opus.dll is not public available yet.

We simply don't have DNS-based whitelisting yet. Also not in the daily builds.

Does the bot speak SIP? In that case it might just be a matter of using the SIP protocol to redirect the call to the right destination.

When you import certificates make sure they are base64-encoded https://doc.vodia.com/admin_certs also note that the PBX can generate certificates using letsencrypt.

For class rooms you can link the DND to the class hours.

AFAIK this is currently under review and should be approved shortly.

There was a bug in some older versions in that area - what version are we talking about here? The caller-ID is indeed a nuisance, we also have to look into this generally with the click to dial.

Should be in the latest 63.1.4 build.

Its all in pbxwebai by default - try ...../pbx/pbxwebai/ or maybe ...../pbx/pbxwebai/pnp (not sure), for example /pbx/pbxwebai/yealink_common.txt. You need to make sure that the PBX actually reads from the file system in the system settings (reg_ports.htm - Read content for global and domain files).

We have added that to the 63.0.6 .dat file. Essentially these are the important changes in the pnp_grandstream.xml file (for all models, similar). In a nutshell it is not neccessary that we check the beginning of the MAC any more because we are already checking the user agent: <file name="grandstream-ht80x.xml" encoding="xml"> - <pattern mac="3">cfg000b82######.xml</pattern> + <pattern mac="3">cfg############.xml</pattern> <user-agent>Grandstream.*HT80.</user-agent> <prefix>true</prefix> <vendor>Grandstream</vendor> </file> The only exception is the grandstream-reject which keeps the phone continue with the provisioning process: <file name="grandstream-reject1"> <pattern>cfg000b82######</pattern> + <pattern>cfgc074ad######</pattern> <prefix>true</prefix>

If you have the PBX send out the email and then delete the message, the light will flicker briefly while the message is in transit internally (we consider that a feature). The PBX cannot know if the email was read or not, that is why the message is supposed to turn off after the email is out and the message deleted.

Whow they must have sold a lot phones. Thanks for the info, we'll swiftly add it.

Yes that is still the case. If you want to "squeeze" more out of a CPU with more cores, you can also run multiple instances on the CPU. Then you can either bind each instance to a different port set (e.g. 5062, 5063) or different IP address. In modern OS it is possible to have multiple IP addresses so that they will occur like separate server instances. If you are using virtualization it will do that for you, but you can also do this directly on the OS similar to a docker image.

This is a difficult question. It is similar to the question what kind of hardware do I need to handle 100 emails per second... But let me try. For up to 64 calls I would say pretty much any PC server should be able to handle it unless you steal it from a museum; 128 calls are done by a cheap new server; 256 by a good server; 512 will require a top server; for 1024 you will have to get everything that is possible today, and you have to avoid call recording and transcoding and maybe even SRTP. Memory is not as important. 4 GB RAM is enough - you probably don't even get such small servers any more. Same for hard drive unless you want to do massive call recording.

There was a similar problem with snom phones - according to the RFC the PBX is supposed to send a NOTIFY after every SUBSCRIBE refresh - even if the refresh is every 30 seconds. What the RFC does not say is what should happen when that NOTIFY is not coming. Most phones just keep things as they are, so they will keep the lights on. Seems like Grandstream reads in their firmware also from the RFC that the LED should be turned off. We'll probably have to give up and send the NOTIFY to every subscriber even if it is a gross waste of resources. P.S. 63.1 is not a full release - we keep building it for those who want to be on the latest & greatest.

Oops that does not sound like a good experience. As for the discount consider registering with our distributor - they will give you the reseller price.

Hmm did Yealink change the behavior that the first occurrence of a setting is the one that will be used? If that is the case we will have to move the yealink-general to the bottom of the template. Or we just put it to the top and the bottom. Please make sure that you did not introduce a XML syntax error - then the whole file will not be accepted by the phone. The voicemail depends on a system setting. The "Calling own extension number goes to mailbox" (in dom_mailbox.htm) controls that. By default this should be on - if you turned it off yes then it will cause that problem. I believe in the next version we should use *97 instead - we will change the template to make sure that this is not causing the problem again.

Ringback usually means that a human is being called and that the call will connect within seconds. Generally we want to keep it that way. That is why the ACD plays that sound when an agent is being called for the current call. However there are situations where this is not desirable, e.g. when agents are available only sporadically or when it takes a long time to get an agent to answer the call, and you want to keep the caller on the phone. Yes The way this currently works is that there are no more announcements rendered into the music - a very subtle hint that the ACD is actually ringing an agent! You can actually have multiple calls ringing. For example the ACD can assign the call to a specific agent and then schedule the next agent, even while that call is still ringing. For that, you can set the "Allow multiple calls to ring agents in parallel" option to yes.

I would not random down or upgrades without knowing what is causing the issue. Downloading a domain should be pretty safe - except when there are so many records that you might run out of memory. Maybe you'll see the pattern and then once it is reproducible we can say what the problem is/was.

My thinking would be around using an auto attendant that can distribute incoming calls where we can control the redirection with a star code (aka winter storm redirection). But what is the use case here?

Of course if it happens when a specific action is taking place that helps a lot with identifying the problem. Also the question is what exactly happens - for example does it just stop accepting new connections (which would hint at problems with the number of sockets), does it go berserk with the CPU, or does it just silently drop out. Are you using the RPS service?

Oh what did you put into the field? Maybe there was something the backend did not understand which would explain why the email never went out...