Vodia PBX

Did not work... also tried a few other keys but still no luck. They must have changed their API seems Vodia is not the only one doing such things. [9] 20210802173943: https:metric-api.newrelic.com: Send request (698 bytes) POST /metric/v1 HTTP/1.1 Host: metric-api.newrelic.com Api-Key: XXXX-XXXXXXXXXXXXXXXXXXXXXXXXXXXX Content-Type: application/json Accept: application/json Content-Length: 516 {"agent":{"host":"TestServer","pid":"pbxctrl","version":"67.1"},"components":[{"name":"Debug System","guid":"com.vodia.pbx","duration":360,"metrics":{"Component/Traffic/SIP[packets/sec]":0,"Component/Traffic/HTTP[packets/sec]":24,"Component/Load/Media[usage]":[0,120,0,0,0],"Component/PBX/CDR[units]":113,"Component/PBX/Emails[units]":0,"Component/PBX/Uptime[sec]":9,"Component/PBX/Minutes[units]":9,"Component/PBX/Registrations[units]":0,"Component/PBX/Subscriptions[units]":0,"Component/PBX/Calls[units]":0}}]} [9] 20210802173943: Initialize TLS connection [9] 20210802173943: Received 298 bytes HTTP/1.1 403 Forbidden Date: Mon, 02 Aug 2021 21:39:43 GMT Content-Type: text/plain;charset=UTF-8 Content-Length: 2 Connection: keep-alive Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" Server: cloudflare CF-RAY: 678a75e59839e708-EWR

Let me try to clarify the problem: When calling from the cell phone, this call is the "caller" for the ACD (even though its an account in the system) and there should be an agent (e.g. in a VoIP phone) to pick up the call?

Yes multiple languages are supported, including German, French, Russian, Spanish, Greek and some English accents like UK and AU. The language is the language of the users mailbox. The data is stored along with the meta information about the voicemail in the messages folder, if you want to "dig" it out from there you could rewrite a script from https://doc.vodia.com/docs/shellscripts but it would be better to use the REST API for this purpose.

Its included in the daily 67.1 (test) builds. This should also work in the browser view, if your device supports multiple devices.

If you are changing accounts or the PBX configuration while doing a large backup this might lead to inconsistent data (so—don't do that). However if you are doing a backup without changing the configuration this is by far not as critical. You might miss a voicemail in the backup because the voicemail was written after the backup was started, but you would also miss it if you start the backup afterwards. Stopping the service for backup would be counterproductive. Scheduling backups during less busy times is a very good idea.

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.