Vodia PBX

If you have 360 extensions I would set it to 500. That should be still pretty good.

In the private message there is nothing really out of the ordinary. A few connections to 389, but no waiting connections. Did you check your settings for Maximum number of SIP connections (reg_sipsettings.htm)?

Yes please send it privately or just replace the public address with 1.2.3.4.

I would not put LDAP on port 389 because that causes a lot of scanners sitting there the whole day thinking this might be some old Microsoft server. This might actually be the reason why you are running out of sockets. Please try netstat -anp|grep pbx

Most of the web site problems are because of customization of the old web interface that are not compatible with the new interface. Because the new web interface is new, such customization can easily conflict with the new interface. If you have such problems check if there is anything in the webpages folder, try to move them out of the way and restart the service. If you want to delete an account (not only extensions, you can do that from the account overview where you can see all of the accounts.

What does the picture look like on netstat level? There is should be possible to see if there are any stale sockets. There is a setting that controls the number of sockets for SIP and also for HTTP, did you check that already?

We have made the builds for version 58.0 today. This release comes with a new web interface that uses a responsive design and a complete API, and it fixes a couple of issues. Most important issues: TLS1.2 depreciates RC4. There is a setting if you need to turn RC4 on again. This could be the case if you are using older VoIP phones that don't support AES block ciphers yet. Also you can control what minimum TLS version is being used. We suggest using TLS1.2, but you can go down to TLS1.0 if you have old devices that require that. The pnp.xml file was split up into vendor specific files, making versioning much easier. Lots of smaller fixes, release notes will be out soon at https://vodia.com/doc/releasenotes580 Documentation will also show the new screen shots soon. You can check if your license includes version 58 by logging into your vodia.com account and then check https://vodia.com/en/mplan. The link for the upgrade is http://vodia.com/downloads/pbx/version-58.0.xml.

Having a LED button for each caller in the queue is an interesting idea. Not sure if this has been done before in PBX history... In the web client, such things are much easier to do; VoIP phones are kind of dumb when it comes to those things.

What could be a possibility would be to use the label next to the button with a (2) behind it. Many phones use LED space for the button anyway, where you can put text.

It is included in all builds made after 6/14/17, also the latest 57.4 builds.

Yes you can combine that with conditional statements. If you want to compare with empty string, you can use {if ext-param1}, because the argument is missing and evaluate to "". There is actually no quoting there.

We added some more logging to the latest version which will hopefully help us getting a better insight what is going on there.

Are you using https? Do other sites that use WebRTC work with your Mac?

Latest 57.4 versions have this already with a reasonable default (hopefully) settings for ignoring characters.

In theory BLF should also be working with service flags. The logic underneath does not depend on the phone type. Looks like this is something we need to try out.

Yes domain-paramX also makes sense!

If there is a huge backlog of emails I would understand that it can take some time until the email gets sent out. What is happening is that the PBX lines emails up one after each other for each email server. So if the first one blocks for whatever reason, it will take some time to get the others out later. Usually that should work nicely and email should be (and they mostly are) going on in near-real time. Maybe you can set the log level for email to 9 and write the log to the file system so that there is a 3 day log for the email traffic for better understanding what is going on.

The first problem I see here is that you need to handle true and false cases. Otherwise you will end up with "Whatever" <sip:anonymous@anonymous.invalid123456@domain.com>. I think it makes sense to include the general purpose parameters that are available for extensions and also other accounts. We will call them {ext-param1-3} in the next build. Then you can put whatever you like in there and reference it when building the header.

The thing is if we add that to the PBX itself, we should make it a settings at least on system level. Who knows, maybe there are people who want to dial spaces and brackets. But I think as a default the characters space, dash, brackets and dot should be removed. We'll put that into the next build.

This is not a dial plan issue. The question is how to interpret the SIP packets, especially the request-URI coming from the soft phone. Do they contain those funny characters? Technically they are fine, and it is actually the job of the "user-agent" to take care about such things. But it might make sense to add a flag or something saying this user, domain or system only process phone numbers and everything else should be taken out.

Might depend on the version a little bit, as we have introduced a "original To" header feature somewhere in the 57.x builds. That might also have an impact on the extension that was dialed.

This also depends on the phone type. Some phones simply don't support it.

There was a problem with snom button in the versions made in the past few weeks. It has been fixed, if you can, try to upgrade to 57.4 or higher where the problem is fixed.

IMHO you should use TCP or better TLS anyway. UDP was a mistake in the SIP RFC for registered devices. If you should still want to use UDP make sure than you automatically provision the phones. That will make sure that you don't set any "STUN" server which causes a lot of confusion and problems like these. If is still a problem, you somehow tricked the SBC. Take a look at the REGISTER message and what IP address the PBX has "seen" (Rx) for that packet. It should be the public IP address of the phone. If there is is the private IP address there is a major problem in the IP routing level.

I am not sure, but assume that the V4.5 write a timestamp "0" into the password file, which is triggers that prompt in Linux. IMHO if you change the admin password from the web interface, you will have to change it also on SSH later, to a different one. Then it should not prompt for it any more.