Vodia PBX

We have looked at this in mode details. 1 GB of RAM is a little bit too small, the number of extensions in not the main factor for the memory size. Other factors like the number of CDR are also important. What is happening when the PBX gets close to the limit is that other processes that typically run on a AWS instance that are talking care about house keeping are not able to run and from then on things are going South to the degree that the AWS instance is not controllable for a few minutes. We have added also some more logs that provide more detail reports if the PBX gets hammered with requests (on log level 3) so that we can see if we can just cut them off. For now the recommendation is to upgrade to more than 1 GB.

Are you using the the HTTP or the DNS method? If you are using DNS—we are supporting DNS made easy only at this point.

Please make sure that you are using the release Yealink template. We have seen cases where the customized templates did not do the authentication {require-credentials} and then the template is rendered without a user. The other thing is that you might have to start the MAC pairing explicitly like you would do from the extensions list web page or the history section in the provisioning tab for the extension.

The New Relic integration was done a few years ago, and since then we did not touch this area. We just post a JSON object to https://platform-api.newrelic.com/platform/v1/metrics and that seems to have worked for years. Looking at https://docs.newrelic.com/docs/telemetry-data-platform/ingest-apis/report-metrics-metric-api/ it seems that the API that we are using should be still working, though in our account I was not able to get a new "Insights API key". There is a curl example on that page, if you find what API key works for you you can copy that key into the input field of the PBX and then it should work.

3.6 was released by accident, we have already reverted back to the 3.5.5 version. Seems on the Microsoft App Store, there was a flag that accidentally automatically released a version that was supposed to be experimental and internal...

Ok course hangup should hang up. So this is on the Windows App? What version of the PBX and what version of the app?

If it works with physical phones, the dial plan is okay. What Vodia soft phone are you using? Can you call the soft phone from the physical VoIP phone?

Its the same like all the other OS, just put the link into the SW update field and start the process. On the IOP please don't power-cycle the device for at least ten minutes because the file system is very slow writing the files.

That is probably because in your system there is no entry in the dial plan that allows the call to that destination.

For the domain there is are different API calls. You can see them in the status page for the domain. They are not the same, what are you looking for?

There are two ways to "miss" a call in the ACD. One way is the callers perception when the caller hangs up without talking to an agent. And the other way is that an agent does not pick up the call although the phone was ringing. Those are independent, for example one or more agents can miss a call but the ACD does not miss the call when another agent picks up. You can determine if the ACD missed a call by looking at the reason, e.g. "hr" would be a classic missed call for the ACD. The agents that missed the call are reported in a list with their extension numbers. I can't see that in the example above, assume that this is from an older version. BTW 67 should include a version number in the CDR record to make identifying this easier.

There was an issue with deleting MAC, but more of cosmetic nature. Adding a MAC was working fine. There were a few messages from Yealink about updates of the RPS, maybe you were just hitting the maintenance window.

The release notes should be up-to-date again.

Lets try this out in the 67.1 branch and see if it causes any unwanted surprises!

Excellent.

Sounds to me like the CDR had some unexpected string in it that would raise an exception. We have worked in that area anyway, and there are some good chances that this will work better in the next build.

Yes T38 is no longer the problem as it seems. At least the PCAP shows T38 going back and forth. Now we are back to good old FAX problems. Looks like the PBX waits for the end of the training, but it does not happen for whatever reason. Its already some time ago, but it would be great to see the LOG messages for media on level 9.

Looks like the "Reregister Before Expiration (in seconds)" was changed in that firmware — it's still a mystery to me how this parameter can have such a profound impact on the registration and why Grandstream would even change the behavior of this setting.

We introduced the ups flag in the URL to tell the PBX to set the URL, so that for the re-sync the phones would not go to the RPS but to the PBX directly (which seems to to work beautiful for us). I was trying to read up on the static keyword with not much success... It sounds like there is a shadow configuration that the user can override? The provisioning guide mentions the static here and there but there is no explanation about it.

The problem is that we are using the CDR internally both for the user and for the reporting side. A missed call is for the user something else than for the reporting end: a user might have missed a call that some other agent has picked up. The solution that we found was to mark the missed call leg as deleted by the user, so that is does exist, but is invisible to the user. Its in version 67.

The dialog state is at the end of the day just a way to turn BLF lights on, off or make them blink. The IETF could have come up with something simpler, but it did not happen and we have to use what is available on most phones. A blinking LED is the "promise" from the PBX that the user can pick that call up. When the call comes into the ACD, there is the first announcement that must be played. During that time IMHO it would be wrong to offer a pickup. Only when the call has made it through the initial announcements it should offer a pickup. Hopefully the phone is not too smart about it — if the call is first connected the phone might say, wait it was connected and now it is ringing how can that be? And not display the ringing state.

The category field is available also for CSV upload (it is actually the last column). In the next release we will introduce a group concept where extensions can be listed as group members. We still have only one domain address book, but we can start thinking how we use that for having something like department address books.

1. Vodia does not take care about synchronizing the working directory. But that can be easily done with rsync or a cloud-based file system. The pbxctrl-failover.xml is the one file that makes the difference between primary and secondary. 2. The automatic failover takes care about failing from primary to secondary. It I actually important that the primary does not automatically come up again and start messing with the file system, which would create a mess with the files. Going back to the primary is a manual process. You have to keep in mind that the failover is for the case that the virtualization layer cannot handle failover within the data center. This is typically geographical failover when the whole datacenter goes offline, which should be a very rare event (hurricanes, power grid issues over a longer time and so on). The failover when the hardware goes down is much easier done with virtualization within the data center. Most data centers offer that service as part of their offering, practically invisible, even for what they call bare bone which is essentially dedicated virtualized resources.

There is not much to do — just copy the API key ID and Secret and put it into the PBX. You can leave the MAC prefix list empty, it contains by default the list of Yealink MAC addresses. Also leave the API path empty, the default should be fine. Then try adding a Yealink MAC address and check in the Yealink RPS if that MAC was added. We are working on making this service also work better for LAN provisioning, but currently the focus is on cloud provisioning where the domain name is the DNS address for the phone.

The secondary PBX is almost just a clone of the primary PBX, with two exceptions. There is a file pbxctrl-failover.xml which by default is in the working directory of the PBX, but which can be also in another directory. This directory can be set with the option --serverdir <dir>. The other exception is the startup file (in Linux /etc/init.d/pbx) which may include that --serverdir option. That file must not be replicated from the primary to the secondary server, either by making it an exception for the sync process or by putting it into the directory for the --serverdir. 1. The easiest is to enable failover is to modify the /etc/init.d/pbx on the secondary server and set the --serverdir option. Then start the secondary and set the failover options. Then restart the secondary. Then it is a good time to start synchronizing the file system. Once you have a pbxctrl-failover.xml file you can as well just edit and copy it for another server the saves you the start and restart. 2. Only on the secondary. You will not see the information on the primary. 3. Yes add it to the startup command on the secondary server and make sure that this is not being replicated. 4. Just set both IP addresses in the IP address field separated by a space character.