Vodia PBX

Can you provide a little more context? So you mean when an agent is stuck in a call with the mailbox, that agent does not receive any more calls? How does the agent call the voicemail? The login and logout is that on mobile devices? If calls get dropped that does sound like problems with connectivity? You can as well open a ticket about this, especially if there is sensitive information that should not be publicly visible.

Ok the .dat might have been built after the executables, but the version is the same.

Is the tenant address of the PBX a DNS address? How about the address for the system? Do you have a certificate, so that you can use HTTPS? Is this server on a public IP or a private address?

All builds for 68.0.30 were built on Apr 17. Where do you see Apr 21?

Right now we don't have that — who ever is allowed to start a recording is also allowed to stop it. But 69 is bringing some changes regarding ad-hoc, where it (by default) is now similar to the automatic recording.

You could use nodejs (see https://doc.vodia.com/docs/using-nodejs) for this and use something like that: // Get the extensions in a domain: const getExtensions = async (domain) => { const users = await fetchPath(`/rest/domain/${encodeURIComponent(domain)}/users`) for (const user of users) { if (user.disabled) continue; if (!user.license) continue; if (user.usertype != 'extensions') continue; console.log(`extension ${user.alias[0]}`); } return extensions }

Can you try with a file e.g. from the audio_en directory? If that works, the format of your file does not work. It should be 8 kHz, mono, linear (16 bits/sample). On a side note, in version 69 user front end you can use the microphone to record the prompts now or use text to speech.

I think the easiest would be just to hide the button in the css (recordings.css) with a rule like that: button[name="info"] { display: none; } Its a little bit of a hack and if the customer understands CSS they would be able to make it visible again; however if they are really good they could as well use the REST API as well.

There should be only one build date? The release notes were written before the actual build, this might look unusual but its okay.

There is no big point in using docker. If you want convenience, you might want to look into the EC2 image on the AWS market place. But if you want to spend one minute on the Linux command shell, just use the install.sh shell script. For docker the PBX is a "unusual" service. A typical docker container will just open one or two TCP server ports. However the PBX will open thousands of UDP ports, which requires a relatively large number of networking resources on the docker system. Because of this, it's easier to use a virtual machine or even a bare bone instead of a docker container.

A typical problem with the upgrade are unresolvable DNS management addresses (see https://doc.vodia.com/docs/release-notes-690). Another thing that is causing issues is that the new version is a lot more restrictive regarding sending sensitive content over unencrypted connections. I know it's a pain, but sooner or later entering a password in plain HTTP will be very hard anyway. The new version has a way to explicitly set the admin password with the options --admin-username and --admin-password. There is no more need to exit the pbx.xml file, which was inconvenient and—depending on the tool used—even dangerous. Also, you should make sure that the PBX can send emails out and that there are email addresses set for the accounts. The password recovery email can then be used—like with most web services today—to get access to your accounts.

Admittedly the 69 frontend turned out to be a bigger project than anticipated. But we are getting there. For example, it can now do things that were not available in 68, like dragging calls into the conference room and actually showing participants in the conference call, or allowing redirection while turning DND on for some time. Visual appearance is always debatable, but at least 69 is completely responsive and modular, which should give us happiness in the years to come and the screen resolutions to come.

If the carrier supports IPv6, you can just do that. All you need to do is add an IPv6 record. iOS and I think also Android prefers IPv6 today, so IPv4 and IPv6 can coexist. But even with CGNAT it should be working with the Vodia PBX SBC as long as the PBX runs on a public IPv4 address that can be resolved from the handset.

I would assume that all they are looking for is RTP content, which is relatively easy to spot by filtering for UDP packets with a certain header. It does not matter if the content is encrypted or not, the header looks the same. On the Vodia apps, we could think about changing the RTP packet signature to some random, proprietary format because we control both ends; however this will not work when we use standard SIP devices and software. The other interesting avenue could be to loo into RTP header compression (RFC 2508). Maybe the carriers just want to preserve bandwidth and apart from that have nothing against VoIP, and this could be a way to have everyone happy. Apart from that, there is almost no reason to use the standard port 5060. It just attracts scanners and creates unnecessary traffic.

There are NAT types that change the port if you send a packet to a different port on the same destination, though thinking about it this should not cause any issue because the PBX never changes the port. Luckily, the router industry has realized that VoIP is a reality today and have also improved their algorithms. Ultimately, WebRTC will pressure all manufacturers, and we don't have to worry about two-way audio any more. But until then it's a good idea to stay away from standard ports for VoIP, unfortunately.

Would the watch VoIP call work without the phone being in Bluetooth distance? I would doubt it. I would assume the watch is from audio point of view just a Bluetooth speaker device. I have also taken calls on the watch, but the audio quality is given the hardware far inferior to the phone itself. I do it if the phone is too far away, e.g. another room. I agree there are some cases where taking a VoIP call on the watch would make sense, but I would say something in the 1-5% area of all calls.

You don't need STUN for NAT traversal. The PBX SBC takes care about it. Yes the PBX in the beginning sends the packets to the "advertised" address, but as soon as the first RTP packet from the phone hits the PBX, it will change the destination and "learn" the real IP address. STUN may help to make this a little faster, but it can also make things complicated for certain NAT types. IMHO it is not worth the trouble.

One way audio is almost certainly a problem with the firewall if other offices and devices are working. You could try to use TLS so that the firewall cannot intercept the traffic. You could also ask the user to move the Yealink phone to another location (e.g. different office or home) to see if that makes a difference.

You would need a newer license key, please contact the sales person of your choice and they will give you one.

If only those users are affected and other users are okay, it is usually their Internet connectivity. I would turn the PCAP on for those users and take a look at the RTP. If the problem is only with a specific SIP trunk, then that SIP trunk provider might have a problem. But this happens almost never. If all users are affected, the problem is likely with the server. You can check if the server run out of RAM, which can happen sometimes. If a restart solves the problem, you might have not enough memory on the server. BTW 68.0.30 is available.

There was another post about it — we'll address this in version 69.

The ring tones should be loaded after the user logs in. After that they are just referenced in other words, if the admin changes them they need to reload them. So a "F5" should reload them.

Ok let try that in the next 69.0.3.

Not being against it, however in HTML how you want to achieve this? Placeholder will not work; title might be able to help when you hover over it. But it seems there is no easy way to show the name.

Nobody wants to be the first to try a new API plus its debatable if you want to talk to your clients through your watch.