Scenario Two (2):

This scenario will link with one or more "other" computers utilizing VoIP and allow the people to speak to each other over the Internet without paying phone "Toll" charges. This scenario is some what identical to the first scenario. But the web-site used to co-ordinate will have the appropriate software installed to allow for authentication of the "Identity" of the parties involved. In other - words - The people who utilize the Web-Site will be authorized and their request to access the web-site will require that they "Log-On" with their "User Name" and "Password" to validate that they are authorized to utilize this site. The Web-Site will actually be acting as a VoIP Server/Switch and will have the appropriate software installed to allow for "virtual signal switching" and "call hand-off/forwarding"and there for allow multiple users to call any of the other users at their leisure.

This scenario uses essentially the same tactics and schemes as the one-to-one scenario. The major difference here is that the Master can be a "virtual Switch" or a "Mediator switch". Either way, Authentication software is usually employed. That software is more often than not "Radius" Authentication and Tracking software.

The Call Hand-Off and Forwarding Call Scenario: This is the simplest of the two multi-VoIP switches. This switch essentially just manages the IP Addresses and then sets up the calls between the two "Clients" who then take over all the TCP-IP Stack operation on their own. Essentially, once the calls are initiated between the two parties, the Master switch slips into "Monitor Mode" and flags the two IDs of the Respective clients as "active". Once the two clients finish their calls, they send a call terminated ping to the Host/Server that lets the Host?Server know that they are no longer busy. This way if another client requests communication with one of the busy clients (already talking with each other) the Master/Host will reply with a caller busy reply.

There is also the capability for the Master/Host server to keep tabs on who wants to talk to a busy client (called Caller Que), and then connect them (or alert the requesting client) when the client that was busy is available , then completes their call connection.

Other than this, this scenario is similar to all the others previously discussed..

The Virtual IP Telephone Switch Scenario: This is the most data/bandwidth intensive of all the scenarios discussed so far. A Virtual VoIP Switch can service clients in the same building (such as a VoIP/PABX) or all around the world. The bandwidth requirements are multiplied by the required bandwidth of each caller (usually 128kps/256Kbps) multiplied by two (x2) and further multiplied by the number of call sessions (pairs of callers talking to each other) that can be handled at the same time. For a 30-Session switch we are talking 512Kbps X 30 or 15.36Mbps (about the average so called cable/DSL bandwidth capacity).

The Virtual VoIP telephone switch essentially does what the first scenario did. It Picks up a cal request from client one and then finds client two to connect. It then receives packets from client one and forwards those packets (Catches and Relays packets) to Client two. It also receives packets from Client two and forwards them to client one (Accepts and Tosses packets). the host is responsible for call quality (expanding the number of duplicate packets based upon call quality (usually monitored by software sub routines that gauges the latency of received packets vs the packet validation rate). The Host/Server is responsible for the connections, the clients are responsible for the call data.

This is multiplied by the number of call sessions that the Server is configured to handle. Actual VoIP Call switches usually employ dual and quad processors. The CPU Bandwidth demands are extremely high, even for Linux based systems. One such switch is TrixBox. TrixBox is a very powerful IP-PABX that also inegrates VoIP software to provide a virtual PABX over a simple LAN Network. In fact, the Trix/Box is the LAN. Each VoIP Phone has a LAN In and a LAN Out jack. A computer connected to the LAN out has Internet/Network Connectivity (even if a call is in session). How sweet is this? Even though the TrixBox is primarily aimed at the PABX market - the interconnection of two or more TrixBoxes would constitute a Distributed VoIP Switch. Which is whre Scenario Three is taking us. But first a little home work.

Here is the Wikipedia Info Link.
Here is some interesting reading. A note from Andrew Gillis the TrixBox Founder.

Now we are building a true IP Based VoIP Network. Other than this, this scenario is similar to all the others previously discussed.. Now it is Time for the Distributed VoIP Switch Scenario:


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