Vodia PBX

Speed dial codes should be in the range 0x-5x anyway, which does not overlap with 90. So you won't loose anything. And you can still just three digit speed dial codes, giving you around 500 speed dial entries. Plus in the 3.1 version you can also use a intercom code which starts without a star, making 9123 possible (9 would be the star code for intercom and 123 the extension). Together with a suitable dial plan on the phone, that should get the job done quiet nicely.

Is the DNS server available? Without DNS you are not able to resolve ntp.org, or whatever you specified as NTP server. You have to reboot in order to get the new settings have any effect.

Well, at the moment you would have to list them all... And keep in mind that this might create a mess with the MWI, because they all will get it.

There is something on the Wiki about OCS - see http://wiki.pbxnsip.com/index.php/Office_C...ications_Server. Virtual servers have the problem that the PBX cannot safely allocate CPU resources as other VM may seize them as well. This will result in jitter. Thats why we say for testing it is fine, but for operation you should avoid it. Well, we run it for several years... Also Microsoft was running it on some of their booths (e.g. http://www.voip-info.de/cebit2007/newsartikel__3254.php). TMC also wrote something nice (blog.tmcnet.com/blog/tom-keating/voip/pbxnsip-ippbx-review.asp).

That happens when you select that your domain is in the NANPA region.

Check out http://wiki.pbxnsip.com/index.php/Outbound_Calls_on_Trunk.

Static registrations are described in http://wiki.pbxnsip.com/index.php/Extension#Registrations. The registration string should look like "sip:+493039978418@ocs03.extranet.itacs.de;transport=tcp". I guess it does not matter if you really own that DID number (how can OCS know?). I would not put that strange Microsoft parameter into the username... Don't forget the tcp parameter, OCS does not talk much on UDP.

Oh yes, there is really a crazy difference after about 10 seconds (packet #848). Is that the time when the PBX sends out the second call? In the embedded world, it is a little bit tricky to deal with the sudden demand for CPU. We tried to do a workaround in 3.0 (CS410), if feedback from there is okay we can port it back to 2.1 and then make another build for the PPC appliance.

.... try to use a ANI for the extension that wants to call the other name or a Prefix on the trunk. The PBX probably thinks the call comes from an extension, not from a trunk.

Well, when the snom phone receives the setting it decides that it needs another reboot before it can start working. The drawback is that the PBX needs to be in the "regular" LAN and the VLAN at the same time. Provisioning VLANs is a tricky topic. It should actually happend before DHCP. Maybe LLDP is the answer.

Nice drawing... I assume that you have more than one public IP addresses?

If you are using tel:-alias, check the "Global" flag on the trunk. We had to do a "security" upgrade here...

For a 2.4 GHz server that is not the problem. Bringing me back to the point of bandwidth limitations. When a group starts ringing, there are a lot of large SIP packets leaving towards the network - they occupy a lot of bandwidth. Did you set the change the registry to enable the tagging of RTP packets for the Type of Service? There is a article from Microsoft on this topic: http://support.microsoft.com/kb/248611/en-us (see http://wiki.pbxnsip.com/index.php/Installing_in_Windows).

Yes, SSL was introduced after this. Before, all emails were sent in plain text. The next version will have a hidden global settings where we can turn the SSL support off for SMTP. In trusted datacenter environments it should be okay, and even more efficient.

Nice First, IP is a pretty redundant protocol already. If you have redundant ways of sending the traffic, it should be possible to let the routers do the failover. Then the application layer (in this case, the SIP-PBX) will just have a little hickup during the switchover. Are your registering those PBX trunks? If that is the case, we could do stuff like double registrations or even use a "hunt group" (!) on the central switch that first tries the first building trunk, and if there is nothing coming back it tries the trunk to the second building. Not sure if the trunk redirection would help in this case - if that PBX goes offline, it will not be able to redirect the calls!

Okay, we analyzed the problem. The SMTP server requests a client certificate from the PBX and what the PBX sends does not make the server happy. Is it an option to put a certificate on the PBX that the server trusts? You don't have to buy a certificate; if you can generate your own organization certificate and make the SMTP server trust your organizations CA, then the problem should disappear. But I think it makes sense to add an option to turn the SSL support off in email. Seems to be a major pain in the neck.

Can you do an upgrade of the PBX? Then those messages should disappear.

Okay. I don't like it when "someone" changes public IP to private IP. There was a self-declated SBC that would even change the IM attachment which says "hey, my IP address is 192.168.1.2" into "hey, my IP address is 213.214.215.216"... But if it works, fine. Never touch a running system. Don't fix it if it is not broken!

I would exclude that the router makes a difference with the destination. I think the fastest way is really to get the packet coming out from the SIP phone (okay, that might involve a hub or port monitoring on a switch) and running Wireshark locally on the PBX. Then if the packets differ we know what we are talking about.

No, sorry that's "duration". Alternatively, if you like, try http://pbxnsip.com/cs410/update-3.0.1.3013.tgz. That image has a little delay that slows down hunt group call setup, so that it should work more smoothly.

??? Still the 503 message ??? Are you sure the upgrade worked? Do you see the build number in the status screen?

Should be fixed in the next 3.0 build.

I would upgrade the PBX to 2.1.14, 2.1.0 may be not the best choice, see the release notes http://wiki.pbxnsip.com/index.php/Release_Notes. When the setup stays the same, and you have this "overnight" experience, it could be that your SIP service provider wanted to do you a favour and upgraded their switch. The service providers often have problems with DTMF, mostly because they are in a "sandwich" situation between their providers and the endcustomers and have to do DTMF transcoding - which is pretty buggy and hard. I would take a Wireshark trace and check the DTMF negotiation and the DTMF traffic between the PBX and the service provider. Maybe if it is not too long, you can just port the ZIP file here. Then I would make a backup of the PBX directory and upgrade to 2.1.14 see if that makes any difference. The licensing model did not change between 2.0 and 3.0. Just the prices went up a little "because of the oil price"...

Hmm. Why not? Will be in the next version.

You cannot put SIP URI in the hunt group itself, you always have to run this through an extension. There you can use a static registration to have the same effet.