At the time of this writing CommuniGate Pro 5.0c2 from the current branch was used. An evaluation can be downloaded from the website of CommuniGate Systems.

Creating a good SIP network is a good first step toward connecting all of the communication tools an organization needs. Here is a diagram that provides an example of a phase 1 migration to CommuniGate Proas the main voice system for one office:



The cisco box in the diagram for example joins the CommuniGate ProSIP network with SIP modules and the phone network with the E1 modules it has installed. FXO devices with single or multiple lines are another alternative where all the channels of a T1 or e1 may not be needed. Legacy devices can connect via ATAs (Analog Telephone Adapters) available from many VOIP products sites.

For phones, it is simply registering the phone to use the CommuniGate Proserver. Most IP phones have web interfaces for this that are similar to configuring any of the soft phone clients. The X-Lite soft phone has been a good testing tool for me.

Starting from this higher level view you can then begin to connect the CommuniGate Procapabilities to the use on a voice network.

It is important to get to know SIP. Good Signaling starts everything. cs.columbia.edu has good information like this which can help as you test.

CommuniGate Pro Configuration Pages

In CommuniGate Pro-> Settings -> Network much had been added to support a strong NAT traversing SIP foundation.

LAN IPs
Local NAT/Firewall -> The info here helps with NAT traversal
Media Proxy -> Make sure firewalls allow these communications to occur
NATed IPs
NATed IP Addresses -> The SIP module must know the possible NATed networks you might need to traverse here

Settings -> Realtime (Signal, Rules, Nodes, and Media)
As you test you can adjust these log levels and read the logs to get and obtain more information about what is going on. I always also find the online help in the product helpful to me.

Settings -> SIP
I recommend raising logging here to learn more also. The online help also helps much here. The external PSTN gateway is my favorite part here. It is a very elegant way of connecting to an external SIP provider, SIP partner, or remote office if necessary.

Settings -> Router
Many new rules for signaling have been added here and reading up on those options has helped me much. A test tool for signaling routes was also added here just like the mail relay tools. I love routing calls as easily as I can route emails. I am not a fan of "VOIP call plans" but they are a necessary tool. I do like this option for many cases.

Router examples
pstnprovider-long = international_longdistance_free.sipprovider.com ; external sip provider account

pstnprovider-local = internalhost_outbound_FXO.domain.com@[10.10.10.10] ; ip address of FXO gateway configuration

pstnprovider-mobile = internal_ATA.domain.com@[11.11.11.11] ; ip address of ATA - not needed with good DNS - this is connected to a single mobile phone that calls other mobiles on the same mobile service provider for free

Signal:<011*> = 011*@pstnprovider-long ; dialing 011 and then any number routes the call ot my outbound provider

Signal:<1*> = 1*@pstnprovider-local

Signal:<+*> = +*@pstnprovider-mobile

Signal: = sipserver.host.com.5060.via ; special SIP routing for some internal calls

S:<313@domain.net> = ab@othercompany.com ; give a phone extension on your PBX to a partner at another company with a SIP address

S:<314@domain.net> = jon@domain.net ; an internal extension for an employee

S:<200@domain.net> = user@othercity.domain.net ; extension for a remote office user with their own SIP server

S:<100@domain.net> = attendant@domain.net ; this internal extension calls the internal attendant account that runs a CGPL attendant applications and provides a search by name directory to locate extensions internally

S:<317@domain.net> = newuser@domain.net ; wow a users account is their phone number extension so I do not need to re-provision all users again like another VoIP solution will require

Reading the online help in the product reveals that "S:" is "Signal:" or signal only route configuration.

OK, so now know a little bit about signaling and routing, so how do I route calls to the PBX and run a specific PBX App?

First lets look as what Apps we have in Domains -> PBX
Everything that ends in .sppr is an application. My install has conference, reception, passive queue, and voicemail. Most are obvious or commented. I encourage opening these and looking at the source. Then looking at the CGPL docs in the online help for more info on writing these Apps.

So now that we know what they are how do we use them?

Domain -> Accounts -> Select an account (mailbox, not forwarder or anything else) -> Select Realtime

This is where you select which applications to run for a specific account. Here is a typical user example:

On Busy: start voicemail
On No Answer for : 15 secs start voicemail
On Failure: return
On Self-Call: selfservice (for pre-authenticated checking of voicemail)

If I create an account for the attendant application (which is extension 100 above) I may configure my inbound calls to route here first. Then the "Realtime" configuration for this account would be:

On Busy: start reception
On No Answer for : 0 secs start reception
On Failure: default ()
On Self-Call: start reception

This then plays the welcome greeting and asks which extension you would like to dial.

The current applications in the PBX are:

Conference Call Manager - conference.sppr (media proxies run the conferences from the server)
Voicemail - voicemail.sppr
Voicemail Self Service for registered devices - selfservice.sppr
Call Center Queue example - passivequeue.sppr
Reception Attendant - reception.sppr

These are easy for programmers and even skilled non-programmers to write. There is currently a PBX app contest running at CommuniGate Systems. I believe it is worth looking closer at the architecture because in most cases you will want to customize these applications for your organization because it is that easy. In fact being too easy is what seems to throw most people off track from what I have seen. The easy routing, adding of audio, and < 200 lines for a voicemail application is hard to believe. I have seen voicemail source for other systems that is more than 10 times that number of lines of code.

I would invest the time in getting to know some of the PBX application internals here. For example:
.sppr files are the applications you can run while .sppi are functions you can call from .sppr files to do things like play the date as an example. The audio files are simply objects you can include in PBX Applications.

I did not even cover the 30-something supported platforms, multiple language support, multiple PBXs in one system, built in clustering, voicemails in the inbox with Message Waiting Indication (MWI) support, making sip calls from webmail and many more powerful things you can get with a truly unified full communications platform. I Hope this provides some help to those interested in testing CommuniGate Pro. The product manual always helps too.