Vodia PBX

Apart from using the same preference number twice the dial plan looks okay to me. Which one first only plays a role if a entry in the lower part of the dial plan should not rbe reached because of a entry in the upper part (defining the exception first and then handling other cases). But usually that is a feature - for example if you have a special trunk for calls to New Zealand put that first, and if it fails you go to a more expensive route that also works for New Zealand.

If you put "1#" into the direct destinations of the AA it will wait for a timeout.

The trunks also have a setting that tell the PBX how to present a number. Depending on the version, that even works for inbound calls. YOu might have to upgrade to version 3.2 to get that working.

Is using a prefix in the trunk an option? In R-O-W companies usually have a common company prefix and then append the extension number there. The other thing is that you can tell the PBX not to change the To/From headers. I believe that is in the domain settings.

Ehh - you mean "IVR Node"? Or auto attendant IVR tab?

The purpose on the "all error codes" is that the PBX can differentiate between the gateway itself being busy or the destination itself busy (talking). In SIP the gateway is supposed to send a 5xx code if it has no more channels available; but there are gateways out there which send 486 (destination is busy/talking). If you gateway does it right and sends a 5xx code when all gateway channels are occupied, you should select that it fails over only on 5xx calls. If it is one of those buggy ones, then you have to failover on all codes. The other failover is timeout. You can control with the timeout setting on the trunk how many seconds the PBX should wait before it generates a 408 response. This will also trigger the failover case as if the gateway would send a 408 code. When the failover happens, the PBX resumes the processing of the dial plan with the next higher number in the plan. You should avoid using the same preference number in the dialplan as it makes this processing kind of random. When the PBX resumes the processing, it will again look for matches. The next line that matches will be executed then. This line can also failover and the game continues until either there is a result (e.g. the call connects) or the dial plan has no more lines.

You mean putting a "8" in front of the extension, so that the call goes directly to voicemail?

Yea, that is a good old problem. If you have only one domain, make sure that you have the name "localhost" either as primary name or as one of the alias.

No, on 2.1 you can put the names into two fields. In version 2 we had "primary name" and "alias" names. The primary name could be "010" and the alias names "9787462777 9787462778" (seperated by space).

Generally speaking, if you want to use the PBX service, the PBX must have a routable IP address. Behind a firewall which does NAT that is not so easy. Actually, it is the intention of the firewall to make it as hard as possible. Even if you get it working, it will likely be instable. Not being able to change the firewall does not make the job easier. And one thing is also guaranteed: It will be a lot of work, setting it up and keeping it running. Bottom line: Try to make your life easier and change the setup. Ideally just get a public IP directly to the PBX and then it will be a easy setup.

I would make a backup of the working directory and copy it to the new host. There are no differences between Windows and Linux, even the CRLF are the same. Of course, you need to have another executable for the PBX itself; but that should be easy in Linux.

In version 3.1, just use the field "Account Number(s):". Use a space to seperate the list elements.

I believe hold was pressing the button right from the display (the one associated with the call). Transfer should show up as a soft key. Not sure if Cisco cancelled transfer as a feature. Maybe that depends on the firmware version.

I believe that problem is solved in 3.1 version (or later). Maybe after the next upgrade check if the problem perists.

There is also a way to write the CDR to a regular file. Similar to writing a log file, but only for CDR. You can specify the CDR filename in the SOAP CDR URL setting like "file:cdr.txt".

I can only recommend to get a routable IP address (so called "public IP address"). All other things are dirty workarounds, and they are difficult to setup and difficult to keep them going. Ask you service provider for a IPv6 address (I know he would not give you one, but increase priority for the IPv6 project - nothing happens without customers asking for it).

Hold and transfer should work using the phone's buttons. Monitoring someone else will be tricky... The Cisco SIP implementation is a little bit "unclear" on this point.

I would say we are talking about Polycom Soundstation IP 4000 here.

Do you have a country code set? Maybe try to register +15147899234. It could be a problem with the representation of the number.

Check out http://wiki.pbxnsip.com/index.php/Office_w...ic_IP_addresses.

I don't think so. Email-stuff is now running in a seperate thread.

What router are you using? Does it support transparent DMZ? If that is the case you can pretty much use http://wiki.pbxnsip.com/index.php/Office_w...ic_IP_addresses.

There is a setting called "offer_pickup" (see http://wiki.pbxnsip.com/index.php/Global_Configuration_File). If it is set to "true" then the PBX does offer pickup functionality instead of speed dial. IMHO it is not good, because it implies a race condition where instead of calling a party you pick a party's incoming call up.

If you have a public IP address and the possibility to put the PBX into a DMZ (transparent, no NAT) then such a setup is a lot easier. You can just configure one NIC for this public interface and the other NIC with a private IP address.

I believe that the replacement list is not 100 % clean. Probably the snom is not so picky with the Contact headers like the Polycom, and the conversation works also with this flaw. You will see if the PBX SIP messages contain a Contact header that can be reached from the phones. The other thing that would come to my mind would be the RTP port range which could be different between snom and Polycom.