Vodia PBX

Pending really just means that there are other requests that are not finished yet. I would turn on the logging for the web client to see any clue, like the wrong password or a firewall issue. There is no limit on how many requests are pending (they take only small amount of memory), but obviously this is something that eventually need to resolve. You can also always login to the Yealink management console and see if anything has reached the server.

It is less about the agents but more about the queues. The queues are about the caller experience and the reporting. It is not a dramatic price difference, and it helps keeping the other prices stable while many other cloud services are currently significantly increasing prices.

The login problems that we saw in the first 69 version should be all resolved now. If you did customize the welcome.htm page, you need to revert this page. There is a page called raw login.htm (less stylish) the you can use to login, and then do the customization from the web interface.

Are you on 68.0.3 or maybe 69.0.3? Maybe better to open a new topic... Can you navigate with the browser to the PBX over HTTPS and see the "green" safety sign?

This is obviously something that needs to be addressed. I would check if the pbx.xml file time stamp gets updated when you save the super admin password. If not, maybe there is a problem with the permission writing the file. Or sometimes there is a competing second PBX running on the same port and it gets random which one get the HTTP/HTTPS port.

68.0.28 is a good version, and there is no rush moving to 69 unless you need to have one of the new features. We are making every few days new builds for 69, and we have internally started to use 69 on some servers for production.

The only version which is still there is pbxctrl-debian64-63.0.7. There is really no other version for Debian. The 63.0.5 binary is available for Win32, IOP (Raspberry Pi), and MacOS (Darwin) if that is any help.

In such cases, try to turn the log levels up, there should be some hint in those messages.

Well at this point this is more like a roadmap thing, it will happen step by step.

We are changing the way to manage MAC addresses because of the IPEI addition. Plus it always made sense to manage devices independently from extensions. If there are a lot of extensions, it turns out its with the current 69.0.3 a little bit clumsy to access a single MAC quickly, we'll have to come up with something better.

Agreed. SMS has grown over the years inside the PBX, some things are hard to understand today. We need to eventually restructure the SMS similar to the trunk. This might be something on the list for version 70. When an inbound SMS cannot be delivered to anyone, this is a little bit like a missed call. Agents need to be registered with an app to receive the message. Someone should be aware about it — in the case of a queue the manager is the one. If there is no manager, well then the only thing the PBX does it to generate a log entry about that.

Hmm it looks okay to me... Maybe a problem with some strange/invisible characters?

Hmm it's still not 100 % clear. There are a lot of displays involved! First of all, presenting caller-ID on a SIP trunk is a tricky and endless topic because every trunk provider has their own way (e.g. spoofing caller-ID). You might be only able to present numbers that are owned by you on the PSTN. Presenting caller-ID on the VoIP device is easier. However, for example if you dial *00xxx, it is a feature that you will not see the actual cell phone number. Also the question is what version you are using.

Sounds to me like the ANI is used for authentication? How can a ANI be alphanumerical. I tried to put that name here, it worked... Which version? Which page? Which field?

Did you anything in "Address for pulling MMS content" (in /reg_messages.htm)? There you should put https://phonesystem.mydomain.com.

Hmm did you manually register the W70B or did you use the provisioning from the PBX?!

We have release version 1.22. It its a little bit clumsy but in the settings you can now see and change the service flags.

Please update one more time to 68.0.28 there was a glitch checking the default SMS value.

Did you enter a system name (System name in /reg_settings.htm)? Then this text should be automatically be prepended to the email subject. We all have that problem that there are so many addressed being blocked .

Hello there! Can you provide a little more context? How can it be on the same trunk, internal calls are not supposed to hit any trunk... Where you do see it? On the VoIP phone, or on the app? If it's on the VoIP phone, is this visible in the SIP INVITE?

We have a great relationship with QuestBlue (even a few drinks). if it's really them let's collect the logs and talk to them, I am sure they would see if there is something that can be done on their end. Or maybe we just need to indicate that we are using UTF-8, and not something like ISO-4565.

We are now at 68.0.28. There was a problem that the TLS connection was disconnected because of some TLS configuration, but I think that is definitively okay in 68.0.28 now. That would explain what you cannot receive any SMS/MMS. For outbound MMS, this might also be the problem because it cannot pull the content from the PBX — because its also TLS. TLS has become pretty important!

Thank you so much for this great tip!

There is 00, 011, and also 0011. It is indeed very confusing if you have many countries involved. The PBX internally always converts it into the +-notation, and only converts it for presentation reasons. So when a user in the US receives a call, it should show as 011-44-xxx, while the same call would show for the UK caller as 00-1-xxx (probably 001-xxx). That is perfectly okay. In order to make it easier to write dial plans, there is a setting in the dial plan of the PBX how it should present the number to the pattern matcher, and again, if you don't like the default, you can explicitly say there how it should be presented. The telecom world would be simpler if everyone just uses + — but is it not...

For the PBX, emojis are just UTF-8 characters. This works (surprisingly) beautifully between the apps, and as far as I can tell the SMS gateway should take care about conversions if necessary.