Vodia PBX

Nono. If you open the box you will see that the chipset actually is mindspeed (www.mindspeed.com). They provide the audio subsystem (they have their own DSP unit for this on the chip!), and AFAIK they sold truckloads of these chips already. The problem with FXO is finding the right gain, and once that is done echo compensation is not such a big problem. We upgraded our software to the 2084 version and so far echo was reasonable.

No BLA yet - though the Aastra phones seem to be able to do that. Maybe you can tweak the files a little bit ;-)

That should already work, there is even a RFC for that (Reason-header, RFC 3326). AFAIK snom phones should support that for some time.

Well well well. SIP does not support SLA or SCA. That is sad, but true. The honesties in the IETF believe that "nobody" would need such a stupid, old-fashioned functionality. So we have to live with workarounds. The workaround is "dialog state", so that someone can watch the status of an existing call. The PBX uses that for monitoring trunk lines (which we call CO-lines). You can see that someone is on the call, and you can see that it is "ringing" and if your SIP phone supports also this, you may pick up the call (using the Replaces header in SIP). When the call is parked, the PBX sends an updated XML as well that indicates a special flag that the dialog is not "rendering media" (haha). Essentially they developed a protocol for replicating the calls database. You can do the same watching with extensions and also with ACD and hunt groups. Interestingly you can do that also with night mode flags (although there is no call). I think we have done what is technically possible. But it is all too complicated. Actually, the whole XML serialization stuff kills the CPU of the PBX and also of the phone. We are working on a new package called "buttons" (outside of the IETF to spare us the endless discussions there), which is just used to turn buttons on and off. There is even interest from other parties like Asterisk guys. The idea is very simple: If the PBX wants to turn a "button" on, it just tells the phone to do so. No big XML hassle, just a small ASCII IM message and we are all set. This already works fine with everything that we could imagine, with the last piece of puzzle being the seizing of the shared line and the association of calls later. This protocol is also very suitable for software switch-boards that suddenly become quite lightweight. So my recommendation for today is to stick to the dialog state. With that you can at least see what calls are going on in the office and that is the main point.

If you put them into the html directory of the PBX (relative to the working directory), the PBX will use these files as templates for generating the config information on the fly. There is some information in http://wiki.pbxnsip.com/index.php/Automatic_Provisioning, not 100 % up to the latest and greatest but a good start (we need to update that eventually). Usually you don't have to do anything with these files - as long as you are satisfied with the default config in there. But we found that it is much more flexible that we hand out these files, minor adjustments become much easier this way. In that case - just put them into them html directory and change them as you like. The latest 2.1 RC1 version contains all PnP files in the html directory, including those Aastra files.

Okay, here we go with 2.1.0.2093: http://www.pbxnsip.com/download/pbxctrl-2.1.0.2093.exe (raw Windows executable) http://www.pbxnsip.com/download/pbx2.1.0.2093.exe (InstallShield) http://www.pbxnsip.com/download/pbxctrl-cs410-2.1.0.2093 (CS410 appliance) http://www.pbxnsip.com/download/pbxctrl-debian3.1-2.1.0.2093 (Debian 3.1) http://www.pbxnsip.com/download/download/p...se10-2.1.0.2093 (SuSE10/32-bit) The InstallShield contains this time the files neccessary for plug and play of the various vendors. We feel that it is useful to provide these files outside of the image, so that you can easily make changes to it - making the provisioning process easier. We have currently some technical difficulties with our RedHat server... Will add that build later. This version seems to be quite stable so far and we want to give it the name "RC1" (release candidate 1).

I would not worry about the connection refused at this point. This has nothing to do with DTMF. If you increase the log level to 6, you will see DTMF events also in the PBX log ("Received DTMF ..."). You need to enable "Log media events" logging for that (see http://wiki.pbxnsip.com/index.php/Log_Setup). This should help to track down DTMF detection on the PBX. Be aware that the PBX does not always listens to DTMF stuff, especially if a regular 2-party call is establised. A safe way to make the PBX listen to DTMF is to call the auto attendant. There is some information about dial plans in http://wiki.pbxnsip.com/index.php/Domain_A...ator#Dial_Plans. 99 % of the time the simple dial plan is enough, the ERE dial plan style is usually only neccessary if you trying to do fancy stuff (like ENUM).

I would try to make the timeouts shorter to narrow down the problem (maybe 10 seconds). In many cases, the operator will already hang up after 30 seconds.

Right, you need to narrow down the problem. Maybe you have two seperate problems. First of all, if you hear anything Exchange, that is already a good sign. The first on is your ITSP. We saw ITSP advertizing RFC2833, but then sending inband - which is obviously quite confusing. You can fix that by turning inband detection on. The 2.1 has a better inband DTMF detection, I recommend to use that version for inband detection (see the annoucement forum for the latest build). You can test this without Exchange simply by calling the auto attendant and see if the PBX responds to DTMF input. The second one is Exchange. I also heared from other users that Exchange has problems with DTMF. But I also saw that DTMF was working with Exchange, so maybe there is a Exchange setting for that. AFAIK Exchange supports RFC 2833 The PBX should do "DTMF transcoding" - that means if the operator sends out of band but Exchange expects inband, that should work. Maybe you can call from a VoIP phone that does DTMF using RFC2833 without any doubts and call into Exchange and see if that works. I guess you saw http://wiki.pbxnsip.com/index.php/Microsoft_Exchange. Not sure if there is any hidden setting about DTMF on Exchange.

Yea, we just changed that. Changing the To-header was technically a brilliant idea, however almost no phone does show the To-header. Now we changed it to the From-header and that should be in the 2.1 release candidate (hopefully coming out today).

Well, a certificate for "localhost" does not make much sense. localhost usually resolves to the same computer. You need to get a certificate for something that is resolvable through DNS (e.g. host.bigcorp.com) and then you can issue a certificate for that host. I used the root certificate service from cacerts.org and that was finally working okay (after playing for several hours with this kind of stuff...). Probably it easier to set up your own root authority and then issues keys from there and ask people that want to use the key to load the root certificate into their Internet Explorers.

There is a checklist at http://wiki.pbxnsip.com/index.php/Troubles..._Trunk_Problems that might be a good point to start with.

Counterpath (www.counterpath.com) is great. They also have a free version (X-lite).

There must be something wrong with the domain email setup. What is the content of the field "email_from" in the domain (maybe do a quick check of domains/1.xml). What version?

That looks okay to me... Is there anything in the log saying "Dialplan: Match ... to ... on trunk ..."? Maybe just save the dial plan again and make sure you have no spaces before or after the strings?

Well, the PBX collects the list of (valid) MAC addresses and if one MAC address matches the MAC in the key, then the PBX assums the product is licensed. "Valid" means No VMWare, and no other invalid MAC addresses. So if you are switching servers, you probably are in trouble. If you want to switch servers, you can either request a key change from where you bought the license or you can request a dongle. The dongle has the advantage that you can put in any server that has a USB stick.

Can you start a new topic in the Exchange forum and attach a trace/log that gives more clue what the problem could be?

The latest version 2.1.0.2090 (http://www.pbxnsip.com/download/pbxctrl-2.1.0.2090.exe) includes the possiblity to provision Polycom phones completely by http. This is very useful when the phone is behind NAT that does not support TFTP.

Is that post related to the beta version or is related to Exchange?

That sounds like the phone sends out the "855" as the destination number. Maybe a problem with the dial plan on the phone???

Did you set the "Allow Access for Extensions" (http://wiki.pbxnsip.com/index.php/Extension#Mailbox) to something like "123 124 125"? Also, try calling something like 8234 (234 is the shared mailbox). *97 will not work as it dials only the own mailbox.

137.xml says that this is the 137th record. Probably some records before that one have already been deleted (when a record gets deleted, the PBX does not rename all other files. This is e.g. useful when a CDR record gets removed).

Look at the file system. There you find the following three directories (amonst others): extensions: Here you find extensions (which are one kind of accounts). The size of this dir is limited by the license parameter "extensions". In the case of an Office 10, you may have up to ten entries in this directory. users: Here you find the "accounts", which may include extensions, auto attendants, conference rooms, and others. The size of this directory is limited by the license key "accounts". In the case of an office 10, the size is limited to something like 20 (not sure), so that you can have also other accounts like auto attendants & Co. user_alias: This dir contains the alias names for accounts, for example "123", "fred.feuerstein" or "tel:123454546". There is no license limitation to the size of this dir. That means you can have hundreds of alias names for one extension, and it would still take only one license.

Well what counts are extensions. An extension has one or more primary or alias names, for example "123", "jf" or "tel:2123456789". If the only alias is a tel: alias, well then it counts. If an extension has zero primary or alias names, then it does not exist any more (deleted). Not sure if that made it more clear.

There is also an update to the beta2 version available. I just post the link here, we will have to put that into another tgz when everybody is happy with this version. http://www.pbxnsip.com/download/pbxctrl-cs410-2.1.0.2090 is the location of the file.