Vodia PBX

The log shows that the ACD redirects the call because of the night mode. It sends it to 311, was that intended?

If you "Inspect the element" (right mouse click on the number) you should find something like "makecall.htm?destnumber=...". Is that number looking okay? Also you need version 5.3.0 on your server as we have introduced a safer way for those links.

Make sure that you re-apply your license as this was originally not part of the license.

I would suggest that you use a test system before rolling this out. Also we have made changes in post-5.3.0 (5.3.0a) that will simplify the snom provisioning. The number of files was just getting out of control. Let us know if you need a head build for testing. You can also add the 725 without an upgrade. Copy the 720 file and copy the entry in the pnp.xml file accordingly. Later when you upgrade, make sure that you undo those changes so that you don't end up in a mix of different versions.

The 725 should work with 5.3.0. Please make sure that you did not make custom changes to the templates, and if you did, revert to the default and then re-do those those changes in the templates. Then the phones should work. We have 715 and 725 in our office, and once that the 765 become publicly available we will buy one and also try to integrate it.

We had cases where the CDR directories contained old records with higher sequence numbers (e.g. 102134.xml). The timestamps in the file system will tell you if they are outdated. If that is the case just move them into a separate directory and restart the service.

You mean the PBX software? I am afraid there is no such thing, you simply need to create a trunk on the PBX and then configure the gateway to accept and send the SIP packets from and to the PBX.

With the 4.5 version some calls cannot be deleted, there were some tricky problems that were resolved in later version 5 builds. What you can do to reduce the problem is to make the maximum call duration shorter, unless you have calls that really last two hours.

Well the PBX does not have the log; you would have to log on the device to access the log.

If you are using Chrome, we have just added a Vodia extension to the Chrome extension store. That could help solving your problem. Requires the new 5.3.0 version, though. See http://vodia.com/documentation/clickcall_extension

How about asking the provider if they can use e.g. P-Asserted-Identity headers? It would probably help interoperability with other SIP devices...

Well, that is obviously non standard... We would have to add that to a new version.

Can you share with us (private message, possibly) the XML file for the trunk? Maybe there is something "stupid" like a space character behind the outbound proxy. I guess other DNS addresses work, for example for sending out emails?

Do you have the DNS server set up properly in /etc/resolv.conf? That is what the PBX uses to determine the address. Also, anything in the log? I don't quite remember if the 4.3 already had a separate log level for DNS.

Yea the process size is not too big for 32 bit. I think the only thing we can do at this point is have that gcore stuff ready if it should happen again.

I think you need to set the ulimit before starting the service. If you have gcore you can use that one to generate the core dump.

Ahhhh okay sorry I now got it. You are right this has nothing to do with the restart script; it seems that the PBX simply got unresponsive. I can happen for a short time when the non-realtime thread is crunching numbers (or do a large table lookup); however it should eventually after a few seconds max resume operations. If that is not the case, then this would be a lot more serious. If it should happen again, it would be great if you can generate a core dump, so that we can see what the problem is. Also, there is a reason why we are building 64 bit versions. Maybe you have just exhausted the memory size limit. The problem is mainly that each thread takes up a lot of virtual memory space (not even physical), so that memory allocation eventually fails and then things go down south pretty quick, with all sorts of effects. You can check with ps how many threads you have and how much virtual memory has been taken already, and depending on how it looks, upgrade to 64 bit.

Did you install the software using the install script? There must be a script for the PBX in /etc/init.d otherwise every reboot will require a manual start of the PBX service (which is extremely risky).

Is this on a snom ONE plus appliance? In that case check if the file system is full. The PSTN gateway that was installed there was writing log files without deleting them and this way creating a "time bomb".

Sorry, sees like the image did not make it. Please try again.

It depends on when you originally bought the license. If the time was more than two years ago when 5.3.0 was build you are fine. You can check this at vodia.com then log in and view your licenses, they show you the date of purchase. More information is available on https://vodia.com/news20150828 (yes it makes sense to read the newsletter ). You can still go back to 5.2.6, just "upgrade" to 5.2.6 then.

You mean systems that get very loud when something happens?

It is a real problem, and that is why the PBX limits the call duration to two hours by default. In many cases the problem is caused by a PSTN gateway that does not properly detect the call hangup on the far end. For digital gateways (ISDN, PRI) it should really detect the hangup; for analog gateways it is more difficult. Check if there is a "polarity change" option on your trunk then. You can also consider making the call duration shorter e.g. one hour to reduce the problem. And of course remind your agents that they should properly hang up the calls....

5.2.3 should be fine for this, no need to change the version. I would at this point really install Wireshark and filter for traffic coming from the phone. If you don't want to install software on the PBX server, consider using a port mirror on the Ethernet switch and run Wireshark on another computer (this is less intrusive).

As far as I can see from the various forums about Windows Server 2012 unless you changed something with the TCP configuration it should work out of the box. Older Server versions could have license limitations on the number of connections. But if you don't have a license limitation or changed the settings, you should be able from the server side to have millions of TCP connections there. Also if you can still log in to the PBX through HTTP (which is also TCP) it seems unlikely that the PBX process ran out of sockets. So one key question is if the TCP config has been changed on the server. Maybe we are looking into the wrong direction here... Is there anything special about those phones that are now using UDP? Like they are home office phones, going through the public wild Internet. What you could do is to install Wireshark on the server to see what is going on on the cable level, if the TCP connections make it to the server at all. Also in the SIP log, you can see a log message when the PBX has accepted a TCP connection, which means that everything has worked fine into the PBX.