Vodia PBX

Hmm. Well we can't do anything about the administrator choosing a password that includes special characters, and IMHO a device should be able to handle that. XML properly does it. But for passwords that the PBX generates, AFAI can see, it should not contain an ampersand unless you are on a really old version. Setting if through the web interface will not help much, because you will set the web or SIP password which is unrelated. What you could try if regenerate the MAC password, easiest would be to delete the MAC and add a new one, maybe just for sake of proving the hypothesis. Or edit the file for the MAC in the file system, take the encrypted parameter out for the password and put it there in plane text, then restart the service.

In 69.0.3 you can now drag the calls into the conference room, if you want to take a look at that.

Yes the colon handling is inconsistent, but the reason for that is probably because the Message-ID was inserted by the mailer. We had already changed that in 69. What we could do is to add the Message-ID also in 68 and even add that space after the colon, so that if any other tool feels like inserting headers they would look the same.

It was introduced with the new ability to treat a hunt group like a shared line. We'll fix this in 68.0.30.

You are right. The new MAC range was in some places, but not all. We will include it in the next build. If you like, you can manually change the pnp_yealink.xml: <pattern>805e0c######.cfg</pattern> <pattern>249ad8######.cfg</pattern> <pattern>yealink.cfg</pattern> Alternatively you can manually set the provisioning URL in the phone to use something like yealink-############.cfg.

Well the passwords are encrypted in the file system, so you would not be able to see the content. However if you check the extensions folder, you should see that the file has changed and the content of the "password" entry has a different value (yes the "password" was the first password entry used by the system, then came the "web_pass" and so on). It does not make a difference if this is single tenant or multi tenant. But it does make a different if the tenant has the magic name "localhost", which serves as a wildcard name. There were some versions that had problems with the SIP password. What version are we talking about here?

AFAIK it does not matter which header comes first (see RFC 5322). I tried to Google for the message but it seems to be a problem with an empty line?! Maybe you can attach the content from the email log. Could be something "stupid" — as usual.

The port, and with it we also easily get the local IP address that was used. However the PBX SBC does not keep too much detail about each access (this would make DoS a real nightmare), so it essentially logs what has been stored with the associated address. The status is the SIP status for the trunk. 200 means "Ok", and other status depend. For example 408 means that the REGISTER that the PBX has sent did not return anything and timed out. Usually this is because of Internet connectivity problems.

There is no ghost in the machine. Even though it seems otherwise, there is no magic in running software. There are essentially two problems here. The first one is password security. If someone gets the password to your PBX that should not, yes there will be chaos. We actually did something about it — passkeys make it a lot harder to steal credentials and we expect that users like administrators will gradually migrate to passkeys. But if someone has the password to the server itself (file system), anything can happen. This is a standard problem and it the PBX is just like any other server software. But my feeling is that this is not the case: If your passwords have been stolen, you would probably have many more problems with other accounts that you own. The other one is what the PBX does. When the PBX starts up the first time after a fresh installation, it needs to set up a default configuration. This includes a default administrator account and password. When the code starts running, it has to make that decision if this the first time it runs or not. For that, it tries to read the configuration — and this was probably the problem: It could not read the file but it could eventually write it and overwrote the existing configuration. The reading and the writing does not necessarily happen within a second. For example, in MacOS when you start a process you get a pop-up to approve file system access for the process which is exactly that problem: It tries to read, which fails and then later when some other setting needs to be written, it still has that initial configuration in memory. In addition, the operating system calculates a hash over the executable image and stores the access rights based on the hash. If you do a software upgrade, the whole thing starts again because the operating system does not trust the new executable. If you have two or more processes running the problem is similar. The "sleeping" process eventually wants to write something and the overwrites the configuration of the "active" PBX. This is actually sometimes happening when the installation process manually starts the PBX and the administrator additionally starts the process with the service start command, without prior deleting the already running PBX manually. This is why we recommend a reboot after installation as this avoids that problem and also makes sure the daemon was installed properly. If you don't want to take this step and you know what you are doing, you can at least check with the ps command if there is only one PBX running. Lastly, we of course want to make this as simple as possible. That is why we have added additional checks for file system access during the start procedure in newer versions. If the PBX has no read and write access, it will exit. This might confuse installers, but at least it does not create hard to understand problem that we are talking about now.

It generally almost always makes sense to use the Yealink General parameter to make such changes. The PBX makes sure that the parameters in there are taking precedence over what is in the yealink_common by default. Then future changes in the yealink_common will be no problem.

If you are compressing the recordings to the GSM format, this might cause the problem. Unless disk space is a problem, I would today recommend to record it uncompressed and in stereo, so that it is clear who said what.

If you want to do the Vodia failover, you need to think about DNS. One solution is to choose DNS SRV records, which require that all clients support that (which most do today). Another solution is to choose DNS A records and use the Action URL in the failover case to trigger a script which changes DNS records. Using IP address will not help unless your script if able to re-assign the IP address to the failover location. Reminder: In most (99 %) of the cases you don't need the Vodia failover because your datacenter already provides you with failover of the VM without you having to do anything. The Vodia failover is for geographical failover and some really special cases, and it is a huge amount of work to set this up properly (and not make things worse).

Prepaid does not differentiate between extension types (at least today). With postpaid you have the option to have one price for all extensions or different prices for different extension types (at least today). So if you have lots of agents, it probably makes sense to choose the one-for-all option, and you can still do it post-paid.

Well "hosted" is post-paid, and everything else is pre-paid, including standard, pro and enterprise licenses. Technically they can also have multiple tenants in enterprise so that is why multi-tenant is not so much the point.

The ldap.name_filter does not look right. It should be (|(sn=%)(gn=%)(company=%)(category=%)). Are you sure you did not override the template?

Well who ever gave you the current pricing that you have ...

Yes, please make sure that you did not modify the Yealink template. What version are you on?

Those admin emails are not customizable, actually they are even hardcoded to English (who cares about the administrator ). It might be somewhere on the todo list, however it's usually not a big deal and most administrators on the planet can understand the content. But we are always interested in revealing more interesting information. For example the local address is indeed interesting. We did include a hardcoded link to a location service, however it changed and became useless. We do not send email on re-register. If you get an email every hour, you do have a problem that need to investigate.

If you are on a license type that does not differentiate extension types (like all prepaid licenses), the extension type for agents does not have a different price tag. Only if the license type permits other types like hotel rooms, the flip side is that agents will be more expensive than a regular extension. If you want to keep everything the same price like we had before, just use the license that does not differentiate extension types.

Call queue agents can be agents in a call queue... I know its sounds trivial, but there is indeed not much more to it.

We are making good progress on version 69 to fully support video on the apps, including stuff like changing horizontal and vertical orientation. While Windows, MacOS, browser and Android should be fine now, iOS is still on the todo list but we are getting closer.

For manual registration, there is the SIP password. It works with the extension number. You also need to make sure that you have the right tenant name in the Request URI (unless you use the name "localhost" for the tenant), e.g. REGISTER sip:30@tenant.com SIP/2.0 where 30 would be the extension name and tenant.com the name of the tenant. The authentication name then is the same 30, and you may choose a different outbound proxy e.g. the IP address of the PBX as long as the phone find the PBX.

There is no setting for this. You could change the HTML template and just take the icon out. The point about the information is to see who accessed the recording. It is sensitive information who listened to recordings. Why would you want to hide that information?

I think the problem is limited to app registrations for mobile apps. They are kind of random, for example after receiving a call the connection is still active for a few seconds and it makes no sense to count them as registration. However registrations for PC based apps IMHO do count — it should not matter if someone works from home with Internet perfectly okay when the office has an Internet outage. Anyhow we'll adjust that mobile app dangling registration in the next release (69.0.4).

SSH is not the problem for sure. It all comes down to the REST API. There are tickets that are two years old, so I take it we are talking about an older version of the PBX? The conclusion in the ticket was that the PBX did not have file system access during the start up of the PBX and was granted later, when it already created a new default configuration with the default password. If you are still running the version, either make sure that the PBX process has file system access from the beginning or upgrade to a later version, where the PBX process verifies that is has file system access before creating a new configuration.