Vodia PBX

You can place the template into the html directory (not the tftp directory), and then you can change the value in the template. Attached is the latest template (please note that once you put it into the html directory, you will miss new versions of the template that come with new PBX versions). Do you think it makes sense to make this parameter configurable? We did not really think about this parameter, we just took the default coming from Polycom. This is usually a reasonable approach. There are a lot of configurable parameters (well, the file is 120 KB!!!), so we definitevely don't want to include all of them. For example, we included a parameter that makes it possible to turn the HTTP server off (security leak). Also, if you are using a analog gateway (FXO) you might have to check the gain on the gateway (see http://wiki.pbxnsip.com/index.php/Gain_Adjustment). Maybe the gain there is too low and then you have to increase the volume on the phones to hear something. The default config on the Polycoms is usually pretty good if the incoming gain is okay. Ouch. At least we want to avoid that other guys go through the same pain again. polycom_sip.xml

What OS is it? Is the OS behaving okay apart from that? Any other applications on that system? What about netstat when the system is not accepting anything any more? Is there a firewall in front of the system? Maybe you can quickly run Wireshark when the problem occurs to see if there is anything strange. Also is there any way you can monitor the system with SNMP? Maybe watch the host and also the application (e.g. CPU usage, number of registrations).

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.