Scenario Three (3):

This is an ambitious scenario - This would involve multiple "Server Sites" that may or may not utilize the "Web-Host" Site to co-ordinate and authenticate requests from the other server sites. Or the servers can each be individual Hosts and inter-connect to all the other hosts. This scenario would be the most complivcated to set up, but would be the most efficient and even be the easiest to use.

The individual "server" sites would each have static IP addresses and would have additional software installed that would be able to communicate with Multi-Line Telephone Subscriber Cards installed in these servers. A Multi-Line Telephone Subscriber Card has two, four, or eight (or more) Telephone Ports (FXO Ports). These cards provide all of the features that are required to connect to a Telephone Central Office via the Phone Line. They sense a ring and answer (after a pre-programmed number of rings), They hold the line open while a conversation takes place, and they hang-up the line after the conversation is finished. When a call comes in from the "trunk" side (this is called "Inward Dial" - this is Telephone Speak for a Telephone connection that is other than local - such as from another Telephone Exchange or a "Long Distance" call) - we will be referring to calls coming from the "Internet" as "Trunk Receive" calls, and calls going out over the Internet as "Trunk Send" calls. (Incidentally, out-going calls are referred to a "Outward Dial"). When a call is received from the trunk - it is a) authenticated (we can't have any un-authorized calls tying up the system): b) scanned to see where it is to be routed to ( is it going to be processed for "outward dial" or "other address" (other address could be a recording saying the number is invalid - or that the call is unable to connect). If the call is to go out as an "Outward Dial" call, the first available line is accessed, then it is taken off-hook (this is what you do when you pick up your telephone). The requested number is then dialed by the card and the call is "processed". The calling party will hear the phone ringing and when the called party answers they will be able to talk to each other. The call processor will monitor the line, and the port for status and maintain the call as long as needed. When either of the callers hang-up, the call session will be terminated and everything will reset for the next calling event.

Each Server/Switch will do this very same thing for each and every FXO Line it has installed. If it is a TrixBox, it will do the same for IP Phones and other Switches calls that it receives. The scenario in paragraph one is the exact same scenario that all PABXs go through. Be it an analog Telephone PABX Box, a Digital PABX or a TrixBox - it doesn't matter. If it doesn't do what is outlined in paragraph one, It Will Not Work correctly.

All we are doing for a distributed switch network is to put more than one VoIP Switch out. One could be in Los Angles, California, one in san Diego California, one in Phoenix, Arizona, One in Tuscon Arizona, One in El Paso Texas, and one in Albuquerque New Mexico.. They all would individually be set up the same. But they would need to connect to each other. Just hooking them up to the Internet just won't get it done. You need to have Virtual Private Networking (VPN) Tunneling software to interconnect the VoIP Switches over an Internet Connection.

First of all we need to cover one more Switch requirement: A switch inter-connects to other switches using "trunk Lines". The Los Angles California Switch may have ten or twenty truck lines that connect it to the Phoenix Arizona Switch. The VPN Links will serve as the regular "truck Lines" for our scenario. All a VPN is is a dedicated protocol session where the two switches are pre-programmed in and serve as an on-call (meaning the circuit is activated once there is a need). Instead of the servers having to "discover" a route between then selves, they already have one pre set. And the VPN is already secure (so no one else can theoretically use the VPN. It only connects the two points it is programmed to connect to.

VPN's are also bandwidth intensive. each VPN for a 128Kbps call link will require about 256kbps (about double the bandwidth supplied in voice data). A 256kbps would naturally require 512Kbps. So If You Have just ten VPNs connecting from Los Angles to San Diego, From San Diego to Phoenix You would have 2.6Mbps/5.2Mbps tied up in each trunk group between each city. Think that is a lot of bandwidth?? How about ten VPNs between each City and Each of the other Cities (ie: Los Angles to San Diego, Los Angles to Phoenix, Los Angles to Tucson, Los Angles to El Paso, Los Angles to Albuquerque: This would require 13Mbps or 26Mbps at each of the five cities. But the system would have minimal latency. Once again this is called "Trunk Flooding" where trunks are connected to all other switches in the system.

Using a TrixBox you would only need to set a TCP-IP Stack for each "Virtual IP Trunk", then configure the Trunk and name the link (ie: SanDiego-1, SanDiego2..... Phoenix1, Phoenix2.... etc). Then you just assign an IP and call area code to the trunks (we like tio use the actual phone area code - Since we do fault redundancy and configure PRI-ISDN as C.O. Lines, we can get the call through by long distance dialing when all out VoIP trunks are busy. Which can be costly if you don't have enough VoIP trucks to support the traffic load). VoIP trunks can be added and subtracted at will, which means if you have the Super bowl in Tuscon Arizona, you can allocate more bandwidth to VPN's and increase capacity by two three, four, five, ten, etc (until you spend all your SuperBowl Ticket money on Bandwidth). After the SuperBowl, just reallocate and remove the excess trunk capacity.

In our last section we are going to tie everything together. Hope you have been paying attention. There will be a lot of Phone Jargon, Telecomm Jargon and VoIP Jargon. Of coarse I will be giving explanations for each phrase (but trust me - this is where it can get really confusing, really quick.

Feel free to read on by clicking here. However if you wish to return to the VoIP intro page click here