Vodia PBX

Does the phone has a local dial plan on the phone? Did you plug and play the phone? What type is it?

The M700 is also provisioned automatically, though we could not figure out how to tell the device how to associate a specific handset with a specific SIP ID. Compared to the desktop phones, there is comparatively less experience with the M700. Also we did not get multiple cells, we could provision only one cell.

The PBX splits the fields up, separated by space. Then it calculates the day and month based on the numerical value of the xx/yy pattern. If the pattern is not a number it will read it as 0, which is not a valid day or month, which in turn means that the comparison with the current date will fail, which means that the element will be ignored as if it was not there.

In the old days there was no standard for this. For the snom phones we did a "hack" and just implemented it with our own protocol. Today we have RFC 7463, and I expect that more and more vendors will support this standard. Including us. But I am not sure if Yealink supports it yet.

If you can manually do these steps, the PBX can just serve as a TFTP or HTTP server. The files then have to be in the tftp folder. This also applies when using the HTTP protocol, where they can be found with http://pbx-adr/tftp/filename. Once the phone has been manually changed to the German version, you should be able to use the automatic provisioning again. Long term we expect that the phones with the small memory will be replaced with the newer models (e.g. snom D325). After all, a GB flash is not that expensive any more.

Same link like 5.4.1, just insert the "a".

The lockout is a good idea, however as far as I can see there is no lockout. All you need to do is to call in again...

Yes, unfortunately that makes a difference. In the early days of SIP, there were implementations that were simply buggy, and this has lasted for years. RFC 3261 makes it clear that the quotes are necessary: qop-options = "qop" EQUAL LDQUOT qop-value *("," qop-value) RDQUOT The problem is if we take the quotes out, we break other SIP trunks and we are not RFC compliant any more. Most implementation over the past years accept both quoted and unquoted. Your service provider needs to update the software...

The last login counts for the ANI determination. You can login again to a specific queue to make sure that ANI is being used.

Yes. The PBX cannot know if a number is a cell phone number or old grandma phone with rotary dial pad!

We have also a 5.4.1a for Win64 in case you want to try that. If you have two calls each one forking to a cell phone, all your lines are busy.

Actually we were working on that some time ago. However it did not end up anywhere instead got us into the whole scripting topic. At the end of the day, you might want to execute some JavaScript code there and in many other areas. We are still working on it.

Yes you can. Check out the changes in https://vodia.com/doc/huntgroups

Please use the documentation page at https://vodia.com/doc/agentgroups

This is a global setting for all domains.

What version are you running? There were versions with bugs in the cell phone forking area.

Maybe the cell phone mailbox picks up? Try to have the cell phone user press "1" to connect the call, then those effects should not interfere with the PBX connection.

If the customer is using ACD, there might be a way to get this done. If the extension logs into an ACD, it will take its ANI for outbound calls.

Oh the ACD has a "Ring stage duration" maybe that is the parameter you are looking for?

Faster frequency? You mean faster? The PBX calls the cell phone immediately in the ACD (not like when calling the extension), so faster would not be possible... It might take a long time depending on the cell phone provider.

I would take a look at the SIP packets and compare From-headers and Authentication headers. Maybe there is a mistake in the authentication, e.g. user@domain instead of just user. Sometimes providers have a problem with UUID, so please turn it off.

It is impossible to cover all requirements on reports. However in the meantime we have added support for MongoDB records, so that it is relatively easy to write report scripts that pull the information out of the database and present them in the way customers need it.

That seems to be a problem with the right pbxctrl.dat file. Did you use version 5.4.1? I remember there was a version that somehow had the wrong web images.

We have added the setting for the process affinity couple of years ago because of the topic. It is not very straight forward. Of course there are issues; first of all it is still one server and one memory and one hard drive (even when using SSD), it will not scale 100 % linear will the number of processors. But for sure you will get much more out of your server than with just one process on it. You need to bind the HTTP, SIP, LDAP, TFTP sockets to their specific IP addresses. They have all the same syntax, ip:port, e.g. 87.54.23.34:5060. Inbound traffic is relatively simple; outbound can be tricky because the OS really needs to present that IP address when sending out packets, especially UDP. Maybe the routing table needs some tweaking. The RTP port range can in theory overlap between the PBX, but it might make sense to have them separately to reduce the chances of allocation conflicts or also bind them to a specific address. There are several ways to do this with the script. One pragmatic way it to think of each PBX instance as a desperate service, e.g. pbx1, pbx2, pbx3 (each one have its own script in /etc/init.d based on the current startup script) so that they each can be start and stopped separately. Then they can run in separate directories, e.g. /usr/local/pbx1, /usr/local/pbx2 and so on.

If you spend some time on scripting (bash, find) you should be able to get this done. In that case don't have the PBX delete the recordings. You can add a cron job that daily searched outdated files and deletes them. Or you compress them using scripting tools that can handle audio formats, e.g. the opus codec comes with command line tools that can take the file and convert it to much lower bitrates. The compression is GSM format, which is 13.2 kbit/s. That is about 4 x more than G711 and 8 x more than the linear format. Browser playback is a tricky area; GSM is low probability that it will work with many browsers. What you could also consider is a recording solution, e.g. callcabinet. They have a service that takes the recordings and put them into the cloud. They can handle a lot more recordings that the PBX, and it also solves problems with compliance.