Vodia PBX

Well who has a comma in the SIP trunk name when using CSV . But seriously, CSV is a loose standard and we have seen cases where the tools did not properly decode the CSV either. So yes it might actually be a serious proposal to take the comma out of the SIP trunk name.

It should be working with 68.0.26. There was a change in the provisioning template for the Yealink phones that makes the phone send DTMF in 48 kHz.

It looks interesting. Intelepeer also have SMS, it would make sense to add them to our dropdown. Looks like we have to take a look.

Just my opinion, sending PBX emails from a free gmail account does not help making the service shine with your users. You might want to take a look at sending email through other services like Amazon SES where you can make sure that the emails do not look like SPAM and they originate from a domain of your choice. If you don't care, you can as well use the Vodia cloud email which is in the drop down for the email setup.

Well the Android ecosystem is hard to manage. There is a huge amount of different OS favors out there, and many phone manufacturers don't update to the latest Android for a long time. It seems that this is part of the problem. We were excited to hear that the latest Android comes with a long-awaited feature to handle calls through a central, OS-like instance but it seems that using it is not everywhere working as it should. I guess we have to seriously consider taking a step back and see if we can address all devices in a satisfactory way.

The load balancer is not helping you with redundancy. It is used for routing incoming requests to the right server. The load balancer can be behind a firewall or NAT, which is useful if you are remote managing PBX on customer premise. That is what the load balancer address in the settings is for. The other way to use the load balancer is to route incoming calls from a trunk provider that must send all calls to one IP address to the right PBX, based on the DID. Today, usually you have a trunk registration for each tenant, which eliminates that use case. Because the PBX is on a public IP in these cases, the refresh interval can be generous and this generates only very little overhead. As for redundancy, you'll get usually everything you need from the virtualization of your server. Most of the time, data centers offer that without even telling you. Unless you order a bare bone, modern datacenter software automatically deploys instances on hardware without you having much visibility on it, including the possibility to move the service to another server if the underlying hardware should fail. What is important is that you take periodic snapshots of the data. It also does not hurt to take automatic snapshots of the whole virtual machine either. Anyhow, the snapshot of the working directory in a location out of the data center is key for geographical failover, e.g. if your whole datacenter goes offline and there is a need to resume operation somewhere else. In that case, your data backup will be very valuable. The cost for running the PBX should be almost negligible. If you put let's say a hundred tenants on a system and let's say you pay one hundred dollar for the instance, your cost per tenant is one dollar. This is a magnitude cheaper than the cheapest instance you can get for single tenant systems, which will suffer from quality problems because those cheap instances share all their resources with hundreds of foreign web services running on the same CPU. It is better to choose a more solid instance with a dedicated CPU core and use it entirely for your hosted PBX.

Its complicated... For a call between two extensions that both support OPUS, it should sound awesome. Calls to the PSTN are a different story, because every transcode operation reduces the call quality, even if a great codec is in use. This might cause a small metallic sound, but it should not be dramatic. If the mobile phone has a great connectivity, it is better to use G711. If the mobile phone has less-than-perfect network connectivity, it makes sense to give OPUS a try. It can handle packet loss much better then G.711.

There was a small glitch with keeping the ID of the file.We'll fix that in the next build. In the tenant, it was already fixed, but not ported into the system view.

Ok lets try... There is a version 68.0.27.beta that has those two models and buttons added.

We have currently buttons defined for GXP1628 and GXP1630. Grandstream has this hard to understand way of numbering their settings. Are we talking about P323 and P324 (MPK 1/2)?

If you don't explicitly specify the associated addresses for the trunk, it will do a reverse DNS lookup, following possible paths. However when the provider uses something like random DNS A addresses, this will obviously not work with all possible addresses. In such cases it is better to explicitly specify the addresses. In the 68.022 versions you can also specify IP address ranges.

It depends on the email. E.g. the variables for the missed email are different than for a status change. In the next version 69 there will be a log message on log level 9 that shows what variables are available, making this easier.

In the web interface, the browser can insert the year with a simple Javascript replace. However for the email it does not work that way. An easy workaround is obviously just to change the footer text. It might mean you have to do it every year, though...

I would just put them into one tenant. There is no point making this too complicated. Then they can use the group functions to make sure to answer the calls properly.

Almost sounds like a problem with SRTP. If you enable other codecs, does it work? What does the SDP look like?

You can always send a message to another user in the system. It is a different story kid the tenant is not set up for SMS, e.g. outside contacts. In that case the popup does not offer SMS. The term "SMS" in the French translation is a little bit misleading.

Yes, we'll hopefully release 68.0.26 in the next few days.

There is the page with the release notes on https://doc.vodia.com/docs/releasenotes, and you also get the links when you navigate in the admin portal to the software update page. But we don't have that for alpha/beta releases.

I don't know... A single click call is a problem e.g. if you put the phone into your pocket and it dials a random number. IMHO there must a confirmation. That pop-up serves that purpose well.

You can have a separate SMS provider per tenant, but not multiple SMS providers in a single tenant. As more and more customers use SMS we might have to reconsider this limitation eventually.

As for the address book and at the risk of being stubborn, the iOS app is working with the phone address book. You can use the local contacts to dial with the Vodia app, all you have to do is choose the right app from the contact detail view (just like with all other apps like WhatsApp, Telegram and so on). Yes, the address book is not inside the app, but IMHO it is even better to use the Apple contacts app instead of trying to write our own copy of the contact app. Copying the local address book is IMHO a complete no go that would justify immediate removal from the app store because it violates everything I could imaging about privacy. Maybe other vendors see it differently, but this would be outright theft IMHO. Having incoming calls show up in the local call log is already a problem thinking about sensitive data when someone leaves the company, but that's another topic. I agree with service flags status and ACD login and logout, although the good old DND serves well if you don't want to get calls, including from the ACD. This is something for the next version. But as for the address book, we first need to understand what the users really want before making a huge effort to come up with our own version of the build-in address book and then find out its not what users need.

I would not see a problem unless 3CX is looking at the User-Agent header and decides to reject it. Depending on what you want to do you could consider using a trunk (Vodia sends REGISTER) or an extension (3CX sends a REGISTER).

Did you see https://doc.vodia.com/docs/voicemailtranscription

It should be builtin1.

In the later versions (68+) we have added lots of logs why and when the PBX includes agents. Possible reasons are login/logout status, recovery time, DND, loss of registrations, hot desking. Sometimes even the phones reject incoming calls, e.g. because uses have set up local redirects. Just turn log level to 9 for IVR.