Vodia PBX

There was obviously something wrong in the deployment process. The installer is the same between 2 and 3, seems something got mixed up. I suggest to make a backup of the directory and perform a manual down-grade to 2.1.14. The downgrade should work seamless, I cannot think about anything that would cause an issue. We replaced the installer. should be the right one now (I verified it!).

That is very weired. Anything in the log? Is that on a temporary key? What is the time on the system (maybe it is still in 1970)? What OS is it? Is the OS behaving okay apart from that? Any other applications on that system? Maybe check netstat when the system is not accepting anything any more, maybe there is another process stealing the SIP traffic from the PBX (it would not be the first time we something like that).

That should (of course) not happen. Do you have your own files in a html directory? Can you just try a clean installation? 3.0 should work just great!

Yea usually it sounds like a good idea to go to the latest and greatest. But in this case there is trouble...

Did you try 3.0.0.2998 (http://pbxnsip.com/software)? This build should support langauges on the phone.

Ehh. Yepp, little problem (you can improve your Dutch with that version). Go for 3.0.0.2998.

What version of the Cisco phones? Any SIP traffic available? Maybe there is a problem with the Replaces-header in the REFER...

When it comes to media related problems, it usually makes sense to get a PCAP trace and analyze it with Wireshark (AKA Ethereal). The CS410 has a program called tcpdump installed which can create PCAP files (also with UDP packets, the name is a little bit misleading). You need to log into the CS410 by secure shell for that and operate on Linux level.

Can you increase the log level to 9 and show only the SMTP events? Then we should be able to see what the problem is.

Short answer: Don't use 7.3.7. There is no feature that you need for the pbxnsip PBX in that version. BTW 7.1.35 was just released.

You either need to know the PIN codes or you must set the value on "Allow Access for Extensions" for the respective extension (see http://wiki.pbxnsip.com/index.php/Extension#Mailbox).

Well, most (all?) low-end firewalls don't have a setting for that, it is just hard coded. I think it is time to think about getting a Wireshark trace. The CS410 also has a packet capture tool on shell level (tcpdump, see http://linux.die.net/man/8/tcpdump). Then we can give a definitive answer on what is going on here.

Probably it is easier to have the functionality explicitly like stated above (is already included in the latest 3.0 build).

Okay, that would be a bug then. Needs to be fixed.

Well, as said above in a server farm you cannot assume that a specific domain is physically on the same server. If that was possible in 2.0, then call it a bug. Needless to say, it caused a lot of problems to have one call in two domains. We have to document the ANI topic on the Wiki, answering that question here is the wrong place.

In a hosted environment, you cannot assume that a tel:alias is on a specific server. There is usually a server farm, and then you must resolve the name by using a trunk anyway. tel:-alias matching makes sense only for inbound calls that come from a global trunk.

(A little bit at wits end) Is there something like a firewall in between? Maybe the NAT closes after 3 minutes if there is no refresh from the other side? We were able to reproduce the problem in the lab (though the timeout was not 3 minutes), and after the change it worked nice.

You definitively have to switch to TCP or TLS transport layer (set in the PnP params). TLS requires a valid certificate in the PBX (http://wiki.pbxnsip.com/index.php/Getting_...lid_Certificate), if you don't have one better stay on TCP. APart from that, you should follow the procedure in http://wiki.pbxnsip.com/index.php/Polycom. As far as I know there is no way of exactly saying what key gets what BLF. It is all dynamically assigned by the phone.

I mean the domain name in the PBX, not in the server. Typically "localhost", see http://wiki.pbxnsip.com/index.php/Domain.

What about the domain name?

At the moment that is not possible. However, it seems that the dongle manufacturer supports OSX. So the answer is a clear "maybe".

Here you can see how the DTMF detection works. The PBX looks at 9 frequencies (the one in the middle is the FAX detection tone). If anything is significantly standing out (2 is not significant), then that tone is treated as "present". A DTMF tone has one of the first four and one of the last four frequencies. Needless to say, this kind of logging literally eats the CPU. So turn this only on if you want to debug something with inband DTMF.

That's when the hunt group redirects a call to the outside world. Depending on the on the caller-ID presentation, you need that. IMHO that is clearly the job of the phone.

You can check if there is another process using port 5060 by running netstat (same in Windows and Linux). Sometimes there are softphones which like to sit on that port. If the port 5060 is really taken by the PBX, then check if you have a domain name or alias "localhost". Maybe you changed the name of the domain and then the PBX gets picky with the Request-URI.

I would run Wireshark in the network to figure out what is going on there. If you have port mirroring on your switch considering using that to see what the phone specifically is doing. In general, having two DHCP servers in the network should not cause such a problem - this would cause different problems.