Vodia PBX

Try setting RFC3325 on the trunk. That should solve the problem, Broadvox is usually quite well on being standard compliant.

As discussed over the last few weeks, there is a new 2.1.6 available. The release notes are as usual available on the Wiki at http://wiki.pbxnsip.com/index.php/Release_Notes_2.1.6. The primary goal of this version was to increase stability and usuability, for example we removed some mouse traps like including tftp in the backup. The following versions are available: http://www.pbxnsip.com/download/pbx2.1.6.2446.exe (complete InstallShield) http://www.pbxnsip.com/download/pbxctrl-2.1.6.2446.exe (bare executable) http://www.pbxnsip.com/download/pbxctrl-cs410-2.1.6.2446 (CS410) http://www.pbxnsip.com/download/pbxctrl-debian4.0-2.1.6.2446 (Debian 4.0) http://www.pbxnsip.com/download/pbxctrl-rhes4-2.1.6.2446 (RedHat ES4) http://www.pbxnsip.com/download/pbxctrl-suse10-2.1.6.2446 (SuSE10) Unfortunately, we had to move from Debian 3.1 to Debian 4.0, but people said that 3.1 was quite old anyway and it seems that the new image also runs on the old platform. However, of course we recommend to upgrade to Debian 4.0 as well. Please let us know if there is any problem with the new build.

If you have a FAX, check out the latest image http://www.pbxnsip.com/protect/pbxctrl-2.1.6.2443.exe. Set a direct destination of "F" to your FAX extension in the auto attendant and see if the PBX redirects the call to the FAX device. I don't have a FAX here... Obviously I was able to survive without it!

Well the PBX runs the Goertzel algorithm (see http://en.wikipedia.org/wiki/Goertzel_algorithm), as most other applications that look at only a few lines in the spectrum. By default, the algorithm is in floating point. Then the threshold is easy to dertmine. Obviously we are fighting problems with fixed point arithmetic, and in order to solve this we just "amplify" the signal by the value dtmf_gain / 256. If you have really loud signals, there will be distortion - but it seems that DTMF is always relatively silent so that danger is not too high. BTW we are also looking at the FAX CNG tone (that is the tone in the middle of the 9 values), that should make it possible to detect FAX in the auto attendant.

Whow maybe we should make 512 the default then!

Did anyone check out http://www.linux-ha.org/GettingStartedWithHeartbeat? I think that does solve the problem for Linux-based installations.

Strange. Maybe just change the system name and hit the save button in the admin settings page to make sure that the file gets written. You can use notepad to see the file, not beautiful but you should see the XML tags.

Yes, that link should do the trick. You can use for example notepad to edit the file. First check if the file now contains the setting, then if that is the case you don't have to edit it.

Well the problem is that there is no common standard. Essentially one PBX - one attendant console. So we have to do our own :-(

Are there any? I know the OC is overdue - we changed the project from Visual Basic to C#...

It is in the Global Configuration File, http://wiki.pbxnsip.com/index.php/Global_Configuration_File. Yes, it is invisible - in this case for a good reason!

Whow that is really very silent. The threshold is 50, and those values are far away from that. The problem is probably that we do the algorithm in fixed point, 32 bits. That is a must in the embedded world, on the PC we could use floating point. Maybe we can solve the problem by having a DTMF gain (at least available as static setting), I have prepared a build at http://www.pbxnsip.com/protect/pbxctrl-2.1.6.2442.exe that contains a global setting with the name dtmf_gain. The default is 256, which means factor 1. 512 would be factor 2 and so on. Maybe you can try this version and see how far we have to amplify in order to get the cell phone DTMF working... and of course it would be interesting if landline still works!

Setting the time was a pain in the neck in the embedded system. There were a lot of installations that did obviously not have a DNS server to resolve ntp.org or had no Internet access at all. Then the system gets a bad start and things go south ways.

It is in the email section for the extension ("Send email record for all calls").

Check out http://wiki.pbxnsip.com/index.php/Installi...P-PBX_Appliance. P.S. Maybe it is worth waiting a few days. 2.1.6 is coming around the corner and it also includes some benefits for the CS410.

There are two things that need to be done. First, you need to need to periodically copy the file system from the active to the standby host, ideally using a differential copy. The second thing is to switch from standby to active. When this happens the standby service needs to be started. I guess we need to come up with a shell script that does this.

Sometimes providers send from different addresses than they receive from. This is not very NAT friendly and it makes it very difficult to authenticate incoming requests. In this case it makes sense to have one trunk for outbound and another one for inbould.

Two things come to my mind. First, you can assign a list of DID numbers to each account (e.g. "tel:2121234567 tel:2121234568"). This may help you to assign several DID to one account. Second, there is a setting called "Change names in To/From-headers" in the domain settings. By default it is on, maybe you want to change it to off.

2.1.6 already has a setting called "cdr_email_size" (invisible global setting in pbx.xml) - see http://wiki.pbxnsip.com/index.php/Global_Configuration_File. Check out http://www.pbxnsip.com/protect/pbxctrl-2.1.6.2441.exe if you like.

Nope. The supported header does not include the magic word "from-change". See http://www.ietf.org/rfc/rfc4916.txt.

CDR is probably a topic that we address in a new way in a 2.2 version. There are a lot of problems with transfers and call segments. We probably have to dive it much deeper than we do today, and then re-assemble the pieces into something human readable so that Joe A is able to read the CDR report.

That seems to be the problem. Are you using an outbound proxy on the trunk? This outbound trunk must also resolve to the "inbound" trunk - the PBX needs to IP address of the trunk to determine that the calls is supposed to come from that trunk.

One thing is clear - you need to use a port range for RTP, not just one port. Typically devices use thousands of ports for RTP just to make sure they are random "enough". I personally agree with your frustration with ICS. I also tried some time ago and did not get anything working...

Check out you default gateway. If you set a default gateway in the LAN then it will be used. What does your /etc/network/interfaces file look like?