Vodia PBX

Hmm it should just work. The user needs to have an email set for the account, but that's about it.

It should be in 68.0.37.

Generally speaking, when you set the log level to 9 for email it shows you what variables are available. Most emails are limited in what they have in terms of predefined variables. The queue statistics are a little bit more elaborated, maybe you can use them.

Should be there now.

Fanvil X210-V2 should be in 68.0.37. We can also make a 68.0.37 Win64 build if it is needed.

Yes. The page title is "RTP", so the "port range start" is actually about the RTP "port range start" on that page. Admittedly it's easy to miss that.

Did you try 69.2.4? Also we have seen that certain SIP trunks don't handle the changing of the SSRC in RTP very well. If the problem occurs only when talking to a SIP trunk and not when talking to an extension, this might be the problem. In that case the allow_ssrc_change needs to be set to false for the SIP trunk.

There are two different topics. One is the problem of sending bulk SMS to e.g. a group of parents and the other one is group messaging where everyone sees everyone else message. They both are obviously valid requirements. So far we have worked on the bulk part of it; as we see users starting to use it we will have to address the problem of transferring conversations around in the team, similar how you would transfer a call. As for the group chat, we actually had that in the early plannings. However in the real world, as of today, it seems most users don't use the PBX for such group chat. This is the world of the mobile phone chat apps, including iMessage and Android Messages that do that job very well.

Thanks we had it pretty much like that now; however the LDAP was still generally turned on; its probably better to turn it off for the LDAP devices.

Sometime the SIP trunk providers also change their stuff. In this case, this might have been a good thing.

From a non-UK perspective kind of hard to understand why they fight VoIP so vigorously. RTP and SRTP are the same. You can set the port range in /reg_rtpsettings.htm, however don't make the port range too narrow so that there is enough room for finding the free ports for a new call.

Not sure if STUN or TURN would help bypass carrier blocking VoIP. I would assume you would have to use VPN for that. SIP ALG are also not a problem because the apps always use TLS (invisible to ALG). The SBC also take care about all sorts of NAT. As long as the mobile phone can reach the PBX over HTTPS and SRTP, there should be audio.

This should be in the 69.2.4 .dat file.

Was that 10 minutes or 10 seconds? There was a 10 second delay internally for certain calls what should now be near-immediate with 69.2.4.

Would be great to know it this actually works for you...

We have added in 69.2.4 the possibility to send a message to the members of a SMS policy. This would be useful for sending messages like "school is closed today". What is different to regular groups is that participants can send opt-out and opt-in messages and also group members cannot send each other messages through the group, or even see who is in the group.

69.2.4 starts to support sending bulk SMS to the numbers listed for a SMS policy. It's obviously a new feature, but it might hep to address the typical problems and it also has the ability that users can opt out.

That link was probably created in error, we took it out. Well it's obviously debatable how many options a regular caller can take. The idea is to build a tree of attendants that can handle the additional options, also also play their respective announcements. For example, the head attendant would say something like "press 1 for accounting", then it would redirect to a secondary attendant where the attendant could offer "press 2 for accounts receivable, press 3 for accounts payable, ... and press 0 to go back to the previous menu" which would send the caller back to the head attendant.

What is you start the PBX with ./pbxctrl --version? The PBX needs only libopus and the usual standard libraries. I would expect the loader to log something what is missing?

Hmmm. IPEI = International Portable Equipment Identity, IPUI = International Portable User Identity. Some of the DECT base stations are fixed to the handset, so that there is no need to enter the handset ID. They will always register to their handset. From the PBX point of view, they look like normal VoIP phones that just have a MAC address. As for the LDAP, if you include this in the template (or general parameter), does that work for you? {loop-start 1} handset.{lc}.ldap.enable = 1 handset.{lc}.ldap.user = {domain}\{account} handset.{lc}.ldap.password = {ldap-pass} {loop-end}

A simple way of doing it is to use the file system, e.g. mount the recordings directory on some external SAN. You could also use a cron job to mirror the recordings from the past day to a remote location, e.g. a S3 bucket using s3cmd. The PBX has also a way to store recordings on S3 buckets, but this is at this point still a little hard to use and it's probably easier for now to go the cron job route.

Emergency calls are a problem when there is a front desk and rooms (class rooms, hotel rooms, apartments, ...). Emails are nice, so are overhead paging announcements, ActionURL but having it in the PC of the people working in the front desk is another logical way of telling who called an emergency number.

You will have to address the problem with the IP address. In a nutshell you need to create a DNS entry for each tenant and set it as address. Then if port 80 is open, the system should be able to fetch a certificate for that tenant, so that you can log in using that DNS address without the browser complaining. HTTPS is essential for using the apps, and also for the users to login, because modern browsers are not happy sending passwords over insecure lines. As for the password, thats a longer story. There is no real need for a user to have a password any more (what is your WhatsApp password). The email is like a password reset email. Once you click on the login link, the browser should set a passkey for the account which the user can use next time for logging in, and if not a passkey, set a session token that is good for 30 days (default). If that passkey gets lost, well send the password reset email and do it again. But you can still do it "old school" and enable passwords for the extensions in the /reg_usr_control.htm page. However passwords are creating a lot of problems, especially when users use the same password in multiple accounts and one of them gets hacked. That's why we like to see users use passkeys.

Well 68 is not a masterpiece when it comes to frontend-design (in case you wonder why we would start a new front end project). The first save button is for the image. Yes, the second save button would be for the user data. Maybe we can still add a horizontal line to 68 to make this a little more clear.

If you can reproduce this, it would be useful to get a PCAP trace for this and see what is going on.