I’m building a support infrastructure for a small team of engineers (DVOP.net, Data and Voice Operations). Here I will describe some useful design notes, tips, and challenges.
Server information: a XEN VPS, hosted at Softronics.ch, Debian 6.0.2
Squeeze, x86_64, 256MB RAM, 15GB disk.
The ticketing system is built with RT: Request Tracker version 4.0.2, so far one of the best ticketing systems, and definitely the best open-source ticketing system. It’s installed from Debian backports packages, with Apache, mod_fastcgi, and MySQL as data storage. Postfix is used as MTA (The default recommended MTA is Exim, but I have no experience configuring it).
Google Postini is used as the incoming email front-end filter for the ticketing system. They charge per account, and I thought I would need a separate account license for every incoming address on the ticketing system, but it appears that a single account allows an (unlimited?) number of aliases. So, basically one Postini account is sufficient.
A Swiss PSTN SIP trunk is most probably going to be purchased from FOXFON.
I am going to build the virtual PBX by myself. I have read the books for Asterisk and FreeSWITCH, and I find FreeSWITCH to be much better organized and easier to make what I want.
FreeSWITCH (as well as Asterisk) is very sensitive to the hardware clock precision. People report very poor results with VmWare VPS, as it emulates the hardware clock, and it’s not physically related to the host system’s clock. XEN, on the contrary, provides direct clocking data from the host system, and people report good FreeSWITCH performance under XEN.
I planned to buy a separate VPS for the PBX, and in the meanwhile installed a FreeSWITCH instance on the same VPS where the ticketing system is running. Surprisingly they feel quite OK together in 256MB RAM, although some swapping is involved. FreeSWITCH is launched with higher process priority, and it occupies only 20-25 MB RAM. But I haven’t yet populated the final configuration, and also some additional web services will be set up, so I’ll have to upgrade to a bigger VPS.
The main purpose of the vPBX is to provide enhanced reachability for the on-call engineers. They should be reachable wherever they are, via their mobile phones or SIP accounts. Also the system should be completely autonomous: the next on-call engineer would simply redirect all hotline calls to himself, without involving the supervisor.
If the on-call engineer is not reachable, the PBX takes a voice message and forwards it as attachment to the ticketing system. The ticketing system then notifies all engineers via SMS that there’s a new urgent ticket.
The main challenge is how to treat various availability events on the mobile phones. Especially that they are abroad. It looks like the most reliable is to call all available phones and play “press 1 to answer the phone”, and wait for input. The only difficulty that on touchscreen smartphones the dial pad is hiding after dialing.