Vodia PBX

Maybe also take a look at http://www.videolan.org/vlc/streaming.html.

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.

Sounds like a good tool. For $ 19.95 sounds like a no brainer! If you just want to see the sockets, you can also just use netstat.

Now you have to put the username and password into the phone. The good old MAC-based authentication only works when you are in the same LAN...

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".

Consider setting the country code for the domain. That usually helps brining the numbers into the right format.

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.

Check the status of the setting called "answer_after_policy" on the phone. It should be "idle", not "off".

Do you PnP the snom M3 phones? I guess it would also make sense to turn the silence detection off there as well.

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!

Hard to say what the problem was/is (I assume a problem with the matching of MAC to a the user). But it seems that 3.3.0.3156 or later works.

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!

Not the expert here, but I believe that "VLC media player" (see http://www.videolan.org/streaming-features.html) is what you are looking for.

Oh can you turn the silence disconnect off on the gateway? That would solve the problem.

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?

Oh you mean for the DISA feature when calling from the call phone?

Can you call the mailbox (*97)?

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.

It seems that for some reason the Polycom phones are one week behind with the DST changes. Does the PBX show the right time (e.g. in the log)?