No the compression is still using the GSM codec. IMHO a reasonable combination of CPU load, audio quality, Windows compability, and file size. If you don't compress, the codec will save 16 bit/sample.
Check if the router sends SIP traffic to the PBX upon an incoming call. If that is the case, check the log of the PBX why it would reject that call. If there is no SIP traffic going to the PBX, check the router setup (again).
In version 3.2, it is 7.1.39. In version 3.3, we'll switch to version 7.3.14. The 7.3.14 version requires a different way of provisioning, some details have changed (e.g. the enabling of the intercom feature).
Yes, the red line is the one that is used for the license count. 18/40 means there are 18 calls, and in total there are 40 call legs. You still have 50 - 18 = 32 calls available.
That's pretty serious!
If internal calls work fine, then we must have a problem with the DMZ and/or DNS. This sounds like the original setup had the DMZ set up in a slightly different way. Or maybe the new firewall has a different firmware version, and the forwarding works in a different way. Maybe it also has a logging feature that you can use to find out where the problem is.
Next time, also make a backup of the firewall. Every component can fail.
The head version now contains a feature that allows "global" dial plans that can be shared amongst domains.
But I agree, we need a simple way to copy and paste dial plans.
If your setup sends out emails, the PBX will send you an email when a call got rejected because of this. Check if you have an email with the subject "CPU Limit".
If you set the country code to "1" then you must use 10-digit numbers in the dial plan now (not 11-digit). Then on the trunk you can decide on how you want to present the number to the carrier. You can choose 10-digit, 11-digit, global formats. This could be the problem.
That usually means that the device is working and can make calls...
Aha. Interesting. Try upgrading to 7.1.39, that contains additional fixes for the shared line.
Where do you set that up?! Usually the dial plan should be automatically provisioned!
As long as the issues with Windows 2000 are not a pain in the neck I think we can continue supporting it. Though the interesting features like IPv6 require something more up to date!
Try http://pbxnsip.com/protect/pbxctrl-3.2.0.3139.exe. Make backup of the working directory before doing this!! If there should be trouble you can revert to the previous version any time.
Do other phones in that network work properly? Is the problem limited to the snom M3? What firmware is on those phones?
Obviously Windows 2000 does not support this. Some new functionality is using this. Try http://pbxnsip.com/protect/pbxctrl-3.3.0.3157.exe if it fixes the problem.
If the server has the right time then the timezones.xml file is correct. Do you have the change to provision other phones (e.g. snom)? Then we can isolate where the problem is. Maybe the way Polycom wants the switch week is different from what we send.