Vodia PBX

I guess that one is fixed in 2.0.3, see http://wiki.pbxnsip.com/index.php/Release_Notes_2.0.3#Emails.

Did you see http://wiki.pbxnsip.com/index.php/Login? What information is missing there to solve the problem?

We have uploaded a brochure at http://www.pbxnsip.com/download/flyer070413.pdf. If you are interested, we can also give you professional handouts (glossy paper, offset printing). In this case, contact pbxnsip sales.

He can just visit his address book from the web interface and change the contact type.

There is a tab called "logging" in the system administrator mode/settings. There you find a radio button for "Log email events". On this page you can also see the overall logging level.

We have prepared a version 2.0.3. See the release notes at http://wiki.pbxnsip.com/index.php/Release_Notes_2.0.3. Images are available from the following locations (Comment added later: please note that there are new version available today!) http://www.pbxnsip.com/download/pbxctrl-2.0.3.1707.exe (Windows XP) http://www.pbxnsip.com/download/pbxctrl-debian3.1-2.0.3.1707 (Debian 3.1) http://www.pbxnsip.com/download/pbxctrl-rhes4-2.0.3.1707 (RedHat ES4) http://www.pbxnsip.com/download/pbxctrl-suse10-2.0.3.1707 (SuSE10) As far as we can see there are no major issues with this version. However, as usual we recommend to be careful with this update. Especially when you are using SRTP, we ask you to be careful because there was a critical change.

Well, in the end we can see what is going on only by looking at the Ethereal traces locally on the PBX. If there is significant jitter on RTP already locally on the PBX, we have a CPU overload problem. If it is not the case, we have to drill down into the network and see where the packets get congested. Divide and conquer the problem.

Okay. Done.

Try something like !\+([0-9]*)!\1!. The trick is to escape the + symbol with a backslash, because it has a special meaning in extended regular expressions.

You can call the 8+extension number, then you get to the voicemail box of that extension. The "8" is actually a domain setting. If you call from "your" cell phone, the PBX explicitly offers you in a IVR menu to go to your voicemail box. Though there was a bug in that area, so that you should move to 2.0.3 if you want to use that feature.

The "root" password cannot be recovered. You can only remove the password in the pbx.xml file and restart the service. Then the password is empty again.

You should enable the email logging and set the log level reasonably high. If you only want to see the email-related log messages, better turn the other messages off.

The PBX normalizes the From and To headers on new calls. This means is checks if the domain name is a known local domain name, and if that is the case, it replaces it with the primary name. If you use the name "localhost", it will match all domain names. On the snom phones, make sure that the domain name for the registration is the same as the primary name of the domain. Usually the easiest way to make this happen (considering domain names like "localhost"!) is to use the outbound proxy feature on the phone.

Don't worry about that. Once the dialog is established, a user-agent can use whatever contact it likes - the PBX identifies the contact by its Call-ID. The PBX is not a proxy, therefore the routing information is not important. The contact was set this way because there is a large ITSP in America that insisted on this style... There are two styles for G726. On is the "IETF" way the other the "ITU" way. They could not agree on the same bit nibble format or so. The IETF has defined a RTP packet load type, but it seems that is very confusing and can easily lead to misunderstandings. Here I do see room for improvement from the pbxnsip side.

That is a pretty old version. We tested interop with 2.0.2, and there the 601 was working fine. If you can update to that version.

I think we had our own experience with such a kind of setup. We tried to run the PBX locally through cable modems and other Internet connections. The result was that those connections tended to be so unstable that we got scared of accepting calls. Also, QoS is a huge, practically unsolvable problem. Initially we had a server in New York in a nice colocation with a doubtless Internet connectivity. We thought it would be superflous. But it turned out that is the best way for us. We can register wherever we are (home, travel, office), and usually have a good connectivity. And at least when someone is calling in trough our ITSP, we know that that connection is rock solid. DoS is an issue, but if you don't want to open the SIP ports to the whole world, you can easily move it to an "random" port (e.g. 45456) and DoS is not such a big problem. If you can limit the access to specific IP addresses on the built-in firewall (e.g. possible in SuSE Linux), then the system should be very stable. We also put a DoS protection into the latest versions that simply limits the number of new connections per second, so that the CPU always has enough time to process everything. So far our system on public IP did not get into any trouble. But we are just a small trial - so the 100 % success rate might not be representative...

A very simple trick is to add the IP address as alias name for the domain. Then the PBX will change the IP address to the primary domain name. If the domain is not a local name, it is neccessary to keep the domain name. Otherwise, calls from sip:123@pbxnsip.com to your domain would always appear as a call from extension 123.

T.38 only solves the problem for traffic between the two T.38 endpoints. If you have international carriers, they might tunnel the voice traffic through VoIP and don't deal with packet loss. In that case, you will not be able to receive faxes, no matter what you do on your side. Generally speaking, if your RTP traffic is just in the LAN (where you have no packet loss) and your PSTN termination comes from a PSTN gateway, using T.38 or just G.711 does not make a difference. T.38 makes only sense if you want to send faxes over links that might loose packets.

What version? Try to set the delay explicitly in the user login. http://wiki.pbxnsip.com/index.php/General_User_Settings

What version? There were some old versions that had problems with that. Also check if the domain has other CO lines with the same name.

We never got a Zyltus phone in our hands... So far their support for us was not overwhealming! Maybe we should get a phone in the lab and take a look. I think just by looking at SIP traces this could become difficult. The good news is that the Swedish prompts are ready and we will make them available shortly

Well, realisticly is you want to provide hosted services you need a session border controller anyway. And that realisticly means that you need to relay the media anyway. And realisticly, statistically speaking, most of the calls are external calls anyway and there media path optimization does not give you anything. The biggest problem is delay, and here especially DSL. If you have fast DSL or other access methods, the delay becomes less critical and then it does not really matter anymore if you relay or not. And the good news is that you can easily offer features like call barge in and recording.

You can load the attached file into the html directory of the pbx and restart the service. If the html directory does not exist, create it first (in the working directory of the PBX). The future builds will contain the new file, this file is just for a fix of existing installations. When upgrading to versions after 2.0.2.1668, don't forget to delete the file. timezones.xml

We did get it working some time ago on a very basic level (only showing on/off). But did not look at it again so far.