Vodia PBX

I would make a PCAP and try to play it back from there to see if the audio stream in theory sounds fine. That might help getting an idea what could be wrong. Sometimes the codecs for sending and receiving are different and this causes issues, though the Yealinks are generally quite well at dealing with this. Generally, the Yealink templates work fine especially in the area of audio. I would be surprised if changing jitter buffer settings would improve anything. You could also try a newer Yealink firmware; there were some changes in the audio part, maybe they will make a difference.

If you can, wait a few weeks. We are working on a version 2.0 that is using HTML elements, so that you can just import the code into your project like this would be npm.

The 1.15 version was just approved in the App Store. It took longer than usual because of the US holidays, we had a bad timing... This will not be the last version, but should be one that end users can use productively. It was surprising that the transfer button problem did not create a crash report, then this would have been found earlier.

Pulling the tar will not delete the wakeup registrations. This makes sense because it might really just be a backup. Then when you restore it, there will be new registrations. There is not much we can automatically do about it. We have added something in the latest (unreleased) version where you can at least see all the wakeup registrations on one page, which will make the management easier. Right now, the only clean way is to go through the extensions registrations tabs and clean up the app registrations. IMHO it should also be possible to use grep to speed up the search so that you don't have to click through every extension. Maybe someone can write a script that lists the wakeup registrations (see https://doc.vodia.com/docs/shellscripts).

If you are into programming, the web front end is all yours. You can change the templates in the admin section of the PBX on system, tenant and extension level if you like. However keep in mind that this is not a "5 minute" task and it might take you weeks to get the results you want. The Windows and MacOS apps also use a lot of that customized code. For the Android app, things are getting a little different because n the mobile world, the device cannot download the whole app every time a call comes in. Also keep in mind that we keep making changes to the web front end code from the Vodia side and they might conflict with your changes sooner or later. There are a few things that can be done easily, like using a customer logo or setting the company name. Also some of the menus automatically enable or disable depending on the permissions for the extension, for example if the extension is part of a queue, the menu item will show or not.

Question... every extension has a different area code?

The 1.15 is in the Apple App review pipeline. Because of Thanksgiving it might take longer than usual. The display shows numbers in a canonical format. For example in the US, when you enter 6173998147 it would show (617) 399-8147 or in Germany a 03055578992 would appear as 030 55578992. Would the leading 0 be unexpected? The other thing to pay attention to now would be copy & paste of phone numbers into the dial screen, because many web pages use special characters like parentheses, dots, dashes and spaces to format the number.

The 1.14 had new transfer dialog, but it seems last minute the link to the dialog was lost in the app . We already have the 1.15 app in the Apple App store pipeline that should occur shortly. It might take a little longer than usual because of Thanksgiving.

Ok at least we know where the problem was... The workaround is to set the codec in the extension to use exclusively "ulaw", then the PBX will transcode it to ulaw. Looks like we'll have to update the App Store one more time.

We have just released a new version 1.14 into the App Store that has some automatic gain control for the speaker phone. Seems like that is what everyone is doing, though IMHO it would be better if the iOS audio subsystem takes are about this. But it seems it tries to stay out of it, and we'll have to do something. The AGC in 1.14 is not very aggressive, so if the levels are really very low it cannot turn that into a great audio experience any more but at least users should be able to hear what is being said.

Yea there are many problems with the CSS in that version, we are cleaning this up I the next major build.

You can also just disable the extension? Its in the account view, not the extensions view.

This should be in the "calls" menu.

You need to have the viewcdr permission or that extension (be part of a group that has that permission). Then there should be a select box o the top right where you can toggle between personal CDR log and tenant scope.

Yea keeping the API documentation up to date is a sisyphean task... For the tasks that you can do from the web front end, I would always just take a look at the browser PBX interaction and replicate it with curl or whatever you are using.

After creating the extension with the MAC, you can set the vendor and model like this. curl -u admin:password -D - http://127.0.0.1/rest/domain/localhost/macs -X POST -d '{"mac":"001565123456","vendor":"Yealink","model":"T26P"}' You can see it "in action" in /dom_macs.htm

The UC reseller trunk has special code because their headers require a mix of number presentations that cannot be setup with there regular settings. There was a bug with the representation on numbers that are not regular phone numbers. It's not easy to fix it with a setting.

68.0.5.beta is ready for CentOS64 and Debian64.

So we finally had the opportunity to reproduce this. The problem was specific to the UC Reseller trunk template. We'll fix this in the next build, if you want to try you can use the 68.0.5.beta build (only CentOS64 and Debian64).

Android does not have anything like CallKit in iOS that controls calls between apps. It would be wise for the Android team to come up with something that will make it easier for the app programmers to improve the experience... Anyhow, in the meantime we are trying to figure out how to handle this better.

The rules for what ANI to use are in https://doc.vodia.com/docs/trunk-ani in a nutshell unless you set something else up: yes. its an array because you can have different ANI depending on what trunk the call goes out.

The users for that MAC are sorted by their username, so that extensions with lower number appear before extension with higher numbers, e.g. "41" then "42" then "43". Its not always what you want but at least its predictable.

Well one step is to check the web client in the PBX if it does talk to the push server. You can see that easily on log level 8 or 9 in the system log. If it does not send it out we have to look inside the PBX. Otherwise we have to figure out why it does not trigger the app to wake up, which might a little bit more tricky. There were some recent finding on the inner working in Android when to wake the app up from more or less deep sleep, hopefully this is not a problem again!

The domain CDR view was not in the front end, we'll add something to the next build (68.0.5.beta). It should be there in a few days.

That is actually a brilliant point. This would save us from adding another switch!