How to Enable the missing 'allowUseBusyOptForGroup' Option in 3CX v7 / How to Add Boot Parameters in v7

This requires you to modify the 3CX databases. While I have done this several times without issue, please be aware that you take full responsibility for your own PBX and you use this info at your own risk. You should make sure to have a good backup on hand. As well, it is likely 3CX would not support these changes and either will I.

OK, here we go....

1. Download pgadmin III to use for modifying the database. http://www.pgadmin.org/download/
2. Install pgadmin on your 3CX box, the defaults should be fine
3. Launch pgadmin and go to 'File->Add Server'
4. For 'Name' and 'Host' enter '127.0.0.1'
5. For 'Port' enter '5480'
6. For 'username' enter 'phonesystem'
7. For 'password' we need to perform the following....open your ini file located at c:\program files\3cx phonesystem\bin\3cxphonesystem.ini. Do a Find and look for the string 'dbPassword'. You should find a long alphanumeric string with hyphens. Copy the alphanumeric string and paste into 'password' in pgadmin
8. Make sure the 'connect now' option is ticked
9. Hit OK.

You are now connected to your 3CX database with full admin rights. At this point, you can completely mung it up.

Now, in pgAdmin....

1. Navigate to 'databases->phonesystem->schemas->public->tables'
2. Expand tables
3. Right click the 'parameter' table and select 'view data->view ALL rows'
4. Scroll to the bottom of the table
5. We are going to create a new row by typing values in the row marked with '*'
6. In column 1 enter 'ALLOWUSEBUSYOPTFORGROUP'
7. In column 2 enter 'allow group busy'
8. In column 3 enter '0' (thats a zero not an O)
9. In column 4 enter '1'
10. At this point, the last column has nothing in it
11. Click in another field elsewhere in the table (in other words, click off this new row). this commits the row
12. Now, click the refresh button at the top of the window. This will autopopulate the last column with the proper next seq num.
13. Exit pgadmin

Now, go back to 3CX and restart all services. Once everything comes back up your old 'allowUseBusyOptForGroup' should be working again.

Happy 3CXing!!!!

Best,

Mike

Connecting your Home Phone to 3CX

I wrote a post for the 3CX corporate blog about this here....

http://www.3cx.com/blog/voip-howto/connecting-your-home-phone-to-3cx/

Some of you may find it interesting.

Mike

Managing Aastra 5xi Series Configs via XML

One of things I love most about 3CX is the simplicity of the management interface. 3CX has done a great job making it very easy and intuitive for administrators to command and control our IP PBXs.

But what about managing our IP Phones?

As many of you know I am a big fan of the Aastra family of XML enabled IP phones. I really love the balance of usability, function and cost that Aastra has managed to achieve (especially with the 5xi family). As well, I am also a big proponent of leveraging the use of XML control that is available in today's IP phones.

While there are a whole host of things we can do with XML scripting on our IP phones, I have become specifically interested in the topic of config management.
If any of you manage a network with more than about 25 IP phones, then you know that managing config files can sometimes become a little bit on the painstaking side. Sure, the use of centralized, tftp based, config distribution definitely makes it easier to "centrally" manage our IP phone config files. It helps us avoid having to make changes on individual IP phones via web interfaces.

There are a few drawbacks to this approach. First, we are still managing a lot of separate files (both global and mac specific files). Second, if we do need to institute changes to subgroups of phones then we may not be able to do this via global.cfg files and will need to edit several files manually. Third, changes made to cfg files are not applied to the IP phone until it reboots and requests it config via tftp.

So, while serving up our config files via tftp is far superior to managing a large amount of phones via web interfaces, it still is not the perfect solution. So, I decided to go in search of some other possibilities and, of course, I love anything than can be done via XML :)

Introducing the AastraIPPhoneConfiguration element...

After some review of the Aastra XML specifications, I came across this little shining gem. The AastraIPPhoneConfiguration XML element allows us to do exactly what we would want, send config parameters/values to an IP Phone as an XML data structure.

What could this mean for config management?

This capability opens the door for users to begin storing phone configuration in a database and serving configs back to the phones via XML push. As well, changes could be made centrally and pushed to phones in real-time rather than requiring reboot (now, the caveat is that certain changes on IP phones always require reboot).

What would this solution look like?

An Aastra IP phone can be configured to request a web application at boot time. A simple front end web application could be created to send back the proper XML data structure based on the MAC address of the phone through a simple database query. Furthermore, the web application could offer a simple admin front-end via which an administrator could make configuration changes to a phone and push those changes in real-time. Effectively, we would be creating a centralized phone configuration management application.

You have to love the power and flexibility that XML controls give us over our IP Phones, I sure do. Wouldn't it be great to have a phone management utility that has us spoiled as the 3CX admin interface? I think it's possible!

Happy 3CXing!!!!

Best,

Mike

"Pocket" VPN Appliances to Ease Deployment of Remote Extensions

Some of you may be familiar with some work I did in the past to simplify the deployment of remote extensions using a combination of openvpn on a 3cx server and a SNOM 370 IP phone. In this case, we used the built in vpn client on the SNOM 370 to connect back to the 3cx server running OpenVPN and provide simple and secure remote extension setup. If you want to read more on this you can find it here... http://3cxblog.worksighted.com/2008/09/first-post-test.html

This work still left us faced with the problem that, while this is great for 1 model of phone on the market today, what about everyeone else? And what if a company already has a VPN infrastructure in place (like many companies do) and perhaps does not want to (or is not permitted to) leverage a secondary OpenVPN infrastructure? How are these users to deal with remote extensions?

The inherent design of SIP w/ RTP makes it reasonably complicated to "easily" traverse firewalls since we are dealing with a lot of 2-way connectionless traffic. It becomes somewhat "hit-and-miss" to get remote extensions working properly (for the lay user anyway). Throw into this mix the fact that many ISP are now offering their own voice services and in some cases bocking service or degrading quality for users not on their voice solutions and we have a nice recipe for a solution that's more complicated than it's worth.

If a true VPN exists from Site A to Site B, the implementation of the remote extension become quite simple since we have full internal visibility between the phone and the 3cx server. While this is typical for branch offices where they can justify VPN endpoint devices at each site, what about the typical home tele-worker who needs an extension? We certainly cannot justify expensive equipment at user's homes and, as well, certainly do not want to deal with attempting to modify users home equipment to create patch work VPNs or battle against dynamic IPs and port-forwards. Yikes!

What we need is a simple, easy to deploy, easy to manage, inexpensive vpn solution for remote workers.

Enter the "pocket" vpn appliance....

It seemed to me that what we needed was a tiny hardware VPN appliance that could sit in front of a remote phone and provide true, IPSEC VPN capabilities, irrelevant of the phone being used.
After spending some time hunting around I came across this interesting product from ZyXEL. The ZyWALL Personal Firewall P1. It is a tiny, wallet sized, IPSEC VPN appliance designed for mobile workers. Now, they are intending it to function for a PC, but I see no reason why it couldn't work for an IP phone. Take a look here....
http://www.zyxel.com/web/product_family_detail.php?PC1indexflag=20040908175941&display=6244&CategoryGroupNo=0E8EA8FA-AF7D-434F-A527-F337AB9A3A51

I realize there would likely be some complexities getting this to work with different brands of VPN concentrators at the head-end, but in concept, I believe this to be fairly do-able. It would provide drastically simplified deployment of remote phones as well as security and encryption.
I'm interested to hear what others have to say about this possibility. Obviously it does not need to be this particular product, but something similar anyway.

Happy 3CXing!!!!

Best,

Mike