Monday, January 29, 2007

What Are The Different Types Of Bandwidth BackBone Connections That Typical WISP's Use?

Here are some of the typical BackBone connections that WISP's [WISP - Wireless Internet Service Provider] use:

* SDSL (Symmetrical Digital Subscriber Line):

Speed: 128Kbps up to 1.1 Mbps

- It can go about the same speed as a T-1 at a fraction of the cost.
- In many cases it can be installed very fast
- Easy Installation

- Ping times are not as good as many T-1's
- Many providers do not allow resale of these lines, so you have to be careful and check the TOS
- Downtime maybe greater then that of a dedicated line
- Speed is usually NOT guaranteed
- Not available in a lot of areas

Bottom Line: For startup WISPs who would like to provide service to a minimal amount of people or who don't have the justification for a T-1 yet at the time of service.

* Dedicated T-1:

Speed: 56 kbps to 1.5 Mbps

- Low Latency (Good Ping times)
- Speed is guaranteed
- Dedicated line (Great Tech Support, compensation for downtime)
-- Available in almost all areas around the US

- High Cost
- Tech Savvy setup

Bottom Line: For WISPs with a good customer base that are ready for the next step.

* Bonded T-1's (Dedicated):

Speed: 3 Mbps to 6 Mbps

- Low Latency (Good Ping times)
- Speed is guaranteed
- Dedicated line (Great Tech Support, compensation for downtime)
- Available in almost all areas around the US

- High Cost
- Tech Savvy setup

Bottom Line: This is for WISPs that have exceeded or are projecting exceeding the maximum capacity of a T-1 in the near future, but can not justify the cost of a T-3 yet DS3 Usually, they just add T-1's and bond them to make it fast, so the lowest speed would be around 3 Mbps, so that would make the cost double in most situations.

* Dedicated T-3:

Speed: 12 Mbps to 45 Mbps

- Low Latency (Good Ping times)
- Speed is guaranteed
- Dedicated line (Great Tech Support, compensation for downtime)
- Available in almost all areas around the US

- High Cost
- Tech Savvy setup

Bottom Line: This connection is for WISPs who have many customers and are ready for a much faster connection. A T-3 is a big jump from a SDSL connection or say a T-1 or a Bonded T-1, so don't buy a T-3 until you are sure that you have enough users to pay for the connection.

* OC-X (e.g. OC3, OC12, OC48, OC192):

Speed: 53 Mbps to Infinity

- Low Latency (Good Ping times)
- Speed is guaranteed
- Dedicated line (Great Tech Support, compensation for downtime)
- Available in almost all areas around the US

- VERY High Cost
- Tech Savvy setup

Bottom Line: A very fast connection with a very high cost. DO NOT purchase one of these connections unless you have SUBSTANTIAL financial backing!!! These connections require very expensive routers, and a lot of technical experience just to get them to work.

NOTE: T-1's and T-3's are sometimes referred as DS-1's and DS-3's respectively.

Tip: To help determine just the right bandwidth solution for your application....and compare multiple providers available at the desired location(s)....we suggest using the no cost consultant services at Network Bandwidth

Labels: , , , ,

Thursday, January 25, 2007

Videoconferencing Bandwidth Decisions, Challenges, And Solutions

The choice between using ISDN or LAN (Local Area Network, including Internet connectivity) cannot be made simply by comparing bandwidth. One reason is that a comparison of bandwidth between the two types of transmission protocols is actually difficult to make. Other factors involve quality of the perceived image and the reliability of the channel.
Desktop conferencing systems that utilize ISDN typically use one ISDN phone line.A standard ISDN line has two data channels that combine to provide the capability to transfer 128,000 bits of data per second.

Group conferencing systems may use three combined ISDN lines to provide the capability to transfer 384,000 bits of data per second. The audio and the video signals must share the bandwidth.

Desktop video images are standard sizes. A QCIF video frame is 176 by 144 pixels, or 25,344 pixels. Eight bits are typically required to encode a pixel. This means that a single frame of video is 202,752 bits.

Motion picture films are shown at 24 frames per second. The human eye perceives a jerky motion at low frame rates. A commonly accepted lower bound on video signals is 15 frames per second. 15 frames of video is 4,041,280 bits. Fortunately, the video frames can be compressed before sending and uncompressed when they are received.

A compression ratio of 10:1, which will degrade the image slightly, means that one second (15 frames) of compressed video can "fit" into 404,128 bits.

Unfortunately, a single-line ISDN desktop conferencing system can only transmit 128,000 bits per second. The top "speed" that can be transmitted on ISDN works out to more like six frames per second with just over 6,000 bits left over for the audio signal.

That means that the best that single-line ISDN can deliver is still a jerky image. Sacrificing the image quality by compressing even more can yield a higher frame rate.

An ethernet LAN can transmit 10,000,000 bits per second. Two computers linked by this LAN could transmit 5,000,000 bits per second to each other. Even carving out sufficient bits for a good-quality audio signal leaves plenty of bandwidth for 20 frames per second of uncompressed video. However, it is seldom the case that there are only two stations on a LAN. It is very probable that 100 stations could be using the network, which lowers each station's "share" of the bandwidth to just 100,000 bits per second (4 frames per second of compressed video). Of course, LAN bandwidth is not divided equally among the stations. Some stations will be using more bandwidth than others at any given time, which allows some stations to achieve high bandwidths when they need it if other stations are not competing for the network. Thus a station on a LAN could exchange high quality video at some times but not others, depending on its neighbors' activities.

The hardware component of some video conferencing systems may limit the bandwidth, also. The CODEC (the hardware component that compresses and decompresses the video signal) may have been designed for use with ISDN-based systems, and therefore may be limited to a 128 or 384 Kbps transfer rate, despite the availability of more bandwidth on a LAN.
Some LAN-based videoconference software stops sending a video signal if the frame rate degrades below a pre-determined level. For that reason, those video conference systems refuse to exchange video when the network is busy. During those times, the guaranteed performance of an ISDN connection is attractive, even if the image may not be.

Network technology is constantly evolving. New protocols and equipment for providing a guaranteed portion of network bandwidth are being deployed. ATM (asynchronous transfer mode) has the ability to reserve network bandwidth. However, the network connection from one desktop to another will typically not be implemented completely using ATM. Instead, the backbone of the network may be ATM, while the connections within a building are still the equivalent of a shared LAN. Similarly, RSVP (resource reservation protocol) for IP networks can provide a guaranteed amount of bandwidth, but it must be implemented along the entire network path. Connections to sites outside one's own local network are the ones most in need of a Quality of Service guarantee, but are the ones least likely to have the necessary protocols implemented along the entire connection. These new network developments are promising, but will probably not be available to the average desktop videoconference user for several years.

For assistance in finding just the right bandwidth solution for your videoconferencing application(s)....comparing multiple providers available in your specific area....we highly recommend the no cost consulting services from

"Videoconferencing Bandwidth"

We also recommend reading both of these articles:

* Plan Ahead - Determine Your Bandwidth Requirements For Video Conferencing Early

* Getting The Right Bandwidth For Your Video Conferencing Applications

Labels: , , ,

Monday, January 22, 2007

Rapid Growth Of Medical Imaging Creates New Challenges For Network Bandwidth Requirements

Medical imaging studies, as part of a patient’s historical records, are subject to long-term security, integrity, and availability regulations defined by governing bodies. Examples include the Health Insurance Portability and Accountability Act (HIPAA) in the United States and the Medical Device Directive (MDD) in the European Union. However, the change from film to digitized storage has created a new set of challenges and requirements.

Digital mammography and multidetector computed tomography (CT), coupled with post-processing techniques such as 3D and CAD, enable medical imaging to be used more extensively for diagnosis, not only in radiology but also in other departments such as cardiology. Dynamic studies using positron emission tomography (PET) and functional magnetic resonance imaging (MRI) enable clinicians to image diseases and to increase the effectiveness of resulting therapies. These technologies enable medical imaging to be included in protocols for a wider class of clinical applications and, in some cases, replace invasive (and risky) diagnostic procedures.

The growing adoption rate of these medical imaging technologies is causing an exponential and often hard-to-predict increase in the volume of images that must be stored. The magnitude of the increasing storage requirements for medical providers is often tens to hundreds of terabytes per year. This growth makes it difficult for IT managers to ensure adequate storage capacity. These challenges also highlight the need for affordable yet flexible storage systems that enable growth on-demand. Information access and business continuity needs must be met from the provider’s perspective, while addressing the stringent regulatory requirements for data privacy and protection.

The mergers and consolidations that are so common in healthcare today have resulted in IT environments that most often do not work well together. Currentapplication architectures as well as the slow movement of the industry towards interoperability and the limited adoption of industry standards have created a utilization, management and access problem that is common to most providers.

The current healthcare infrastructure can best be described as complex, inflexible and inefficient. As a result, applications that depend on it are slow, exhibit bottlenecks, suffer unacceptable levels of application downtime due to single points, and require unnecessary amounts of dedicated resources. Managing this hybrid infrastructure demands expertise for each type of application and manufacturer at multiple levels, as well as resources to manage the environment across each storage platform. Infrastructure scaling and upgrades prove to be very costly and difficult due to the time, money and people required to perform them.

As a result of these inefficiencies, healthcare IT resources are severely underutilized with storage utilization running at between 15% and 30% over a 24-hour period.

A potential fix for these issues is use of a framework for the creation of an enterprisewide, grid-based virtual medical image storage system designed to enable healthcare organizations to share data across distributed sites. These solutions are meant to be complementary to PACS applications and extend the capabilities of these systems across a wide area network.

Many providers have implemented multiple PACS solutions across many geographies, each with its own storage environment. Each PACS implementation drives its own requirements for storage and administration. The application of grid technology enables the sharing of storage and allows the logical separation of the application from the underlying storage infrastructure. This means that multiple systems can share storage resources wherever they are available. Additionally, through their local applications, users can access remote images populated by other systems on the grid. Key benefits include higher utilization of existing storage investments, the migration from storage silos to grid-enabled storage pools that can be made available to all applications, and the ability for IT departments to administer the grid centrally from a single location.

For assistance in finding just the right grid-based storage system for your Medical organization and/or network architecture bandwidth solution for your PACS application(s).... comparing multiple providers available in your specific area....we highly recommend the no cost consulting services from: "Medical Imagery Bandwidth"

Labels: , ,

Thursday, January 18, 2007

How To Solve A Consolidation Of Your Business Phone System Needs With An Asterisk VoIP Solution

Here's the scenario.......

You're planning planning ahead for a consolidation of your business phone systems including a potential move of your headquarters to a new building.

Currently your company has 300 employees and operates in 15 locations:

- 6 warehouse locations with business offices (~30 - 50 employees each)

- 1 small warehouse (5 employees)

- 2 business offices (~10 employees each)

- 7 small stores (3-4 employees each) - 2 share space with warehouse locations

You also have some outside sale folks that work from home most of the time.

Currently you run several disconnected phone systems and some Centrex (store locations). You'd like to standardize on one platform with integrated voicemail for the company. The plan is to do this in the next 1-2 years, whether or not you move to a new building.

All of these facilities are connected data-wise via a private routed network served by a Tier 1 carrier. Your headquarters is the hub for these locations and currently hosts all of the data servers.

When and if you move to a new facility your boss is considering outsourcing the mainframe and server systems such that all of the equipment is hosted by a separate company. This would relieve you of the considerations of building a server room in the new place. You do currently have a raised-floor server room, where your current phone system is located.

Of course with no server room (if you go that route), this limits your ability to host a PBX (you currently use a ROLM 9751).

Here's the questions you should like ask....and ensure answers for:

1. In a hosted PBX or VoIP solution, or even with a centralized on-site PBX can you still keep local numbers for each location?

2. If your equipment is centrally located, how do local calls work? e.g. - if your phone system is located in Maryland and someone in New Jersey needs to make a local call, is that really a long-distance call since the equipment is in Maryland? How is this typically handled?

3. What about DID numbers? Can you keep these? How are they routed?

4. What would a company do in terms of having a local operator at larger locations? Is there a sort of gatekeeper in place at these locations, or would it all be centralized at one site?

5. Currently you use a different automated attendant setup at a few of your locations. Would this still be possible or even recommended?

6. What is the usual way of connecting multiple sites to a centralized telephone system? What type of backup links are typically used?

7. You figure moving to a completely new system would cost around $1,000 per user (phone equipment, initial setup, new phones, training). Much less for a hosted system, but a high MRC you suppose. Is this estimate in the ballpark?

8. What recommendations can you expect on what type of systems may "fit the bill"? Some features you're looking for are below:

- Outside sales would like to be able to forward their lines to a home/cell phone.

- Internet access to change user settings would be nice (web-based user management).

- You have several Inside Sales queues, so you'd need good ACD capabilities.

- Ability to dial by extension to anyone at another location.

- Distribution lists for voicemail.

- Custom on-hold messages by location (different or store locations).

- Local paging at your warehouse locations (page over intercom).

- Local directions to your supplier truck drivers.

- After-hours/emergency messages need to be customized by location. (For example, if your Pittsburgh office is closed due to snow).

9. What about backup analog lines? Since you have a large inside sales presence, the ability to receive phone calls is critical. What is a good number of lines (percentage of total trunks, perhaps?) that are required and how are they usually setup?

Now there may be a number of choices to select a solution from...but in the interest of simplicity and brevity for this article we'll focus solely on Asterisk. You can apply others to the questions posed above on your own....if you're brave enough.

Asterisk an open source (free) soft-PBX type program, that can do just about anything. If you choose a proprietary vendor's product, some or all of this may not apply, as the following reflects how I'd suggest set up using Asterisk.

I am going to assume your system is all easily routed (no NAT) and at least the server can get on the Internet from your main datacenter. Also, how much bandwidth does this provide you? At full quality (G.711 ulaw codec) a call takes about 80kbit/sec including overhead. When highly compressed (gsm, iLBC, g.729) it can be as low as 10-15kbit/sec.

Plus....stop thinking about this as many small systems and start thinking one big system. Additionally....with IP lines there is often not a channel limit, you are only limited by your bandwidth.

With 300 users, you won't need THAT much to get on asterisk, in certain situations. A good-size box running Asterisk should be able to handle 300 concurrent calls without too much of a problem. If you do "difficult things" (codec translating, conferencing, etc) this number goes down. The point is you may very well be able to fit much/all of what is required into your existing datacenter. If you require "large things" (channel banks, large PSTN interfaces, etc) this may not apply. Wiki for a page called Asterisk Dimensioning for info about who is using what hardware and what it can handle.

Set up your Asterisk server(s). Standardize on a few models of IP phones (make sure 1 is of the more reputable and capable). Configure DHCP for your network to provide a tftp-server. Probably also set up some kind of database for phone configurations. Use this to make files for the TFTP so the phones will configure themselves. Takes a bit of doing but makes setting the phone itself up VERY VERY VERY easy, just plug it in (assuming its provisioned in the server first).

You plug in the new phone. DHCP provides it with a TFTP server, from which it fetches a config file based on its manufacturer or model and another based on its MAC address. It also downloads new firmware if your server provides it. It then reboots if needed and the settings take effect.

The two files let you set settings for everybody (what server to use, etc) while defining individual settings (SIP login, softkeys, etc).

You can also distribute things more. Set up small regional or local Asterisk boxes that handle certain areas.

Lastly, keep in mind that how you terminate your calls does not have to be VoIP even if your PBX is.

Now to your questions.

1. You can almost certainly keep all your local numbers, although this depends on what VoIP provider you get. Often one provider can port a number while another can't. If you have PRIs or something in an area and want to keep them, you can. Asterisk will handle this fine and I'm sure so will other packages. You just need an appropriate interface board.

2. Again, depends on providers. Often you can work out a deal whereby local calls will be free. Even so, VoIP minutes are not expensive, usually 1-2c/min tops and you can negotiate a better rate if you use a lot.

3. See above. DIDs are easy, they will be routed to your central PBX and from there to your sites/phones. If you have local PBX's they can register directly to the provider if you have different accounts. If you mean real DID numbers (call number, dial extension, get person) that can also be done.

4. You can have an operator on VoIP. IP phones are available with a lot of buttons if you need them (Cisco, Snom 360, and Grandstream 2000 all support sidecar modules). Calls can ring the operator and/or go to wherever you wish based on whatever criteria (time, operator logged in, etc).

5. Sure it is. You can route a call based on what number it came in on, what caller ID was provided, what day/date/time it is, what setting is set to what, or any combination of the above / almost any other criteria you can think of.

6. As above, you can super-centralize or you can spread out with smaller, local servers. Asterisk servers can trunk calls to each other via SIP or IAX2 (inter-Asterisk exchange) protocols. You can route calls based on extension range (2xxx is NYC, 3xxx is Boston, etc) or simply by which server has it (Wiki for DUNDi). All the transport will be across your chosen network provider. Installing backup links is the same as backup Internet links.

7. A bit high but not a bad estimate. Running financials, say $3000 for the main server (assuming you centralize), $300 or less per phone (user), plus man-hours, training, etc. If you need to upgrade your network provider links or switching capacity this goes up.

8. Asterisk can do all of the stuff you mention. Few gotchas...

- call forwarding requires some setup, this can be done by making an Agent for each user or with a call forward script. It is quite possible though.

- web based admin - Asterisk itself can be configured from flat config files or through a MySQL database. There are however packages (asterisk+stuff) that provide a web front end. For example: Trixbox.

- Dial by extension will not be a problem as long as you have the bandwidth to handle all the calls.

- Voicemail distro lists are easy. Make an extension that dials like VoiceMail (mailbox1&mailbox2&mailbox3) etc. Asterisk supports MOH from mp3 files or other audio files. You can change MOH classes per-channel, per-user, or per anything else. Each MOH class is a folder with file(s) in it. You can make as many classes as you want.

- Paging is also easy. If you have an Asterisk server onsite, hook it's sound card up to the paging system. Otherwise you can page through phones (most phones support intercom/paging). You can page through an overhead system using either the sound card, or something more specialized - you can get paging controllers with a POTS interface (hook it up to an ATA (analog telephony adapter, ethernet on one side, FXS (station) POTS port on the other), or you can also use a VoIP phone to interface a paging system. Grandstream GXP2000 phones for example have a 3.5mm jack which can be easily wired up to a paging system.

- Afterhours is easy. Have an audio file which contains the after hours message for a location. Dialing a certain extension records or lets you change this file or turn it on/off (you can script this)

- For a backup, use a PRI (T1). Probably run this to your central place. Alternatively, you can get PRIs to local servers, and local calls would go out and incoming come in this way, with LD calls going out via VoIP. Remember, VoIP PBX doesn't necessarily mean VoIP phone service.

9. A T1 carries 28 lines. With that would be something you would have to sit down and talk about and go over call volume in a pre-sales meeting. Base your decison on that input.

If it were me, I would go with a more integrated approach. Install hybrid systems at each location and network them together with VoIP. If the PRI is down between a warehouse and your main office, you're not totally dead. The warehouse still has local lines and can make and receive calls.

Bottom line....despite the Asterisk slant provided may simplify the direction the answers come from to this:

1) Forget about a hosted solution.

2) Make sure your purchase a PBX that has robust ARS.

3) Find a dealer that's experienced with networked systems.

Now you have a plan to follow that makes both technical and business sense.....albeit based on an Asterisk solution. I strongly suggest that if you are ever faced with a similar situation.....and are considering a higher order solution offered by one of the reputable enterprise VoIP providers.....that you make use of the free consultant services found at Business VoIP to map a solution BEFORE you choose a provider and place your order. This will eliminate most of the potential frustrations you may encounter in this scenario.

Labels: , ,

Monday, January 15, 2007

How Do You Turn A DS3 Circuit Into 28 T-1 Lines

Here's the story.....

You ordered a DS3 circuit to replace 20 T-1 lines you have. It is cheaper on the network side and everybody at the local long distance carrier said it will work exactly the same as T-1's. Now you're being told it will not (big surprise) and it is due to be installed in a few days.

The signaling you need is d4-AMI. The carrier wants to know if it will be either ss7 or PRI. Your equipment is too old for both.

How do you make this work?

You've heard about using a multiplexor or a mux. But how do you know if you are getting the right one and if it will work? Your equipment is based off of the D240sc t-1 rev1 dialogic boards. Plus you also use a 1980's phone system ( surprise for many businesses unfortunately). Ultimately, you need to have 28 T-1 lines from the DS3 circuit.

What equipment do you need? How should the carrier set up the DS3 circuit for you?

Okay here we go....

The first thing you need is to get the proper equipment.

Any M13 mux will break out the individual T1 lines from the DS3 circuit. The Adtran MX2800 should be okay but it will need the proper configuration. Unless you have a DC power plant you will want the AC power model. I would suggest you put it on an UPS also. Plus you'll want to get the M13 control card not the STS-1.

You will be using M13 framing on the DS3 circuit not C-bit. The DS3 bandwidth side of the circuit is referred to as the high-speed side. The T1 bandwidth side is referred to as the low-speed side. On the T1 side you will need to physically breakout the T1 lines.

For the MX2800 it appears you will need a couple of accessories. It looks like you will want to get the 64-pin amp cable to the RJ48 patch panel. Your T1 lines will appear on the patch panel in order, DSX-1 channels 1-28.

The T1 lines are individuals and need their framing and coding set for the type of T1 on a particular channel. For instance; channel 1 on the DS3 circuit is an SF/AMI T1 so you set the mux channel 1 for SF/AMI. Channel 2 is ESF/B8ZS so you set channel 2 for ESF/B8ZS, etc.

TL1 commands are pretty basic but can get complicated very quickly. Not all mux's use TL1 but it looks like the MX2800 does. The Manual with the mux should have the commands in it for you to follow for set up..

Basically it's fairly simple. You have a DS3 signal on two coax cables, TX and RX. Those cables will plug in to the DS3 mux. The mux will break out the T1?s respectively to the DSX-1 panel.

In general.....the T1 configuration is separate from the DS3 configuration. You can order a Muxed DS3 and request the T1s be optioned as ESF/B8ZS or D4/AMI. The company you order the circuit from should be able to configure the T1s either way.

DPC is short for Destination Point Code. It identifies your switch from other SS7 switches and is used to route calls to you as well as establish SS7 service to your switch.

One very simplistic way to think of SS7 is as if you were looking right at a person, face to face.

You see the person (T1 circuit) and you can talk to the person (SS7). If SS7 goes down you can still see each other, but you can't communicate with each other.

In most cases ISDN service or even standard T1E&M is the way to go, unless you are running a Central Office type switch (Lucent 5E or Nortel DMS-100).

If the provider can give you ISDN (PRI) service and your equipment has the capability to work with ISDN service, that would be the way to go only if your equipment can handle ESF/B8ZS circuits.

Afterall this is a DS3 not a bunch of T1 lines. Remember, your T1 orders are ordered to arrive to you on the DS3. When you order a T1, it's CFA (carrier facility assignment) is ordered on your DS3 and mapped on the DLR (design layout record).

Now you have a plan to follow that makes both technical and business sense. I strongly suggest that if you are ever faced with a similar situation..... that you make use of the free consultant services of to map a solution BEFORE you choose a provider and place your order. This will eliminate most of the potential frustrations encountered in this scenario.

Labels: , , ,

Thursday, January 11, 2007

Network Security Hits Home Run For Detroit Tigers

Since I'm a dedicated, fanatical, and life long Detroit Tiger baseball fan (AND a techie at heart)....I thought this article was way too cool not to share here. Baseball....TIGER baseball....and broadband technology application (DS3 bandwidth network to be exact). What a combination!

Network Security Hits Home Run For Detroit Tigers

By Andrew R. Hickey, Senior News Writer

The Detroit Tigers may have lost the World Series in a less-than-stellar five game run against the St. Louis Cardinals, but their loss on the field bears no resemblance to how their network performed in the postseason.

Actually, as clichéd as it may seem, the network at Comerica Park hit a home run. And that was no simple feat, considering that the network is designed not only to support corporate team operations but also to be at the ready for journalists, concessions, ticketing, baseball operations and a host of other users.

According to Scott Wruble, IT director for the Tigers, prepping for the increased traffic of the playoffs was a bit stressful. He said that the playoff run added to the network roughly 600 media users and about 80 corporate users, many of them sending and receiving rich media files. Essentially, he said, bandwidth had to be upped to accommodate the additional traffic.

Wruble and his team worried about internal and external risks that the added traffic could bring into the network. Worms, viruses and other malware were certainly a potential threat, he said.

"We needed some assistance getting proper monitoring in place," Wruble said, adding that the Tigers' IT squad wanted something that could shut down a user that was over-utilizing the network or introducing problems. In 2005, the Tigers hosted the All-Star Game and had added more bandwidth, but they weren't able to stop security threats in their tracks.

"Last year, we had to manually shut down problems," he said. "We couldn't trace the problem to a specific machine. We learned from that for the playoffs."

For the 2006 playoffs, IT needed to plan for four times the number of users.

Learning from the All-Star game, the Tigers rolled out DS3 capacity just before the postseason to accommodate the expected spike in traffic, Wruble said. The Tigers also wanted to avoid network downtime from online threats, viruses, worms or misuse that could be caused by such a large number of people from different environments accessing the network.

The team deployed StealthWatch, a network behavior analysis tool from Lancope, to monitor and protect the network. Wruble said the tool was up and running quickly and freed up the staff to pay closer attention to other potential problems. Alarms were set to alert IT to any problems that arose.

According to Lancope, StealthWatch collects NetFlow and sflow data while also collecting native flow data to provide more detailed coverage and packet inspection for sensitive areas of the network. It captures and summarizes transaction records for all network communications for forensic analysis and incident investigation and remediation.

"We found that we'd come across worms, viruses and other threats on the network and we could shut them down," Wruble said. "We captured things we didn't want in our systems. We shut down a handful of systems and helped the users figure out what the problem was."

IT would plan for spikes just prior to games and near the end of games, Wruble said. Immediately after the games, traffic would rise significantly.

"Lancope helped us identify these specific threats and shut them down," he said.

Now, with the DS3 in place, bandwidth can be increased or decreased as needed without changing the system infrastructure, Wruble said. If Detroit makes the playoffs again next year, bandwidth can be turned up. If there is a concert at Comerica Park, bandwidth can be boosted.


Hmmmmm......wonder where you could get a DS3 bandwidth solution just like the Detroit Tigers?

For assistance in finding just the right solution for your DS3 bandwidth application(s)....comparing over 20 top tier providers available in your specific area....we highly recommend the no cost consulting services from:

"DS3 Bandwidth Solution"

Labels: , ,

Monday, January 08, 2007

T1 Connections Provide Unparalleled Data Transfer Speeds For Businesses

Before we get into T1 internet connections, let’s examine some of the main connection types that are commonly available through which to access the internet. There are dial-up modems that typically can only transfer up to 56 kilobits per second. While this is the original and main way that people connected to the internet during the birth of the information age, the advent of broadband has continued to sweep the world in popularity for its dramatic increase in data transfer rates. Another drawback to using dial-up modems and internet connections is that they require the use of a phone line. This presents a problem for many people that need to use their existing phone line for voice calls and do not want to purchase a second phone line.

As far as broadband, also known as high speed internet, is concerned, there are three types of access. There are DSL, cable and T1 types of high speed internet access. One of the main benefits to using high speed internet access is that these types of connections are ‘always on’ and do not tie up a phone line.

DSL stands for digital line subscriber and is the more commonly available type of broadband internet access. One of the reasons that DSL is more popular than cable internet is that the DSL signal travels over regular phone lines without tying up the voice portion of the line. DSL requires the use of a DSL modem and offers data transfer speed up to one hundred times faster than dial-up internet connections. One of the disadvantages of DSL, contrasted to cable internet, is that distance from the hub can pose a problem. If the distance between the DSL center and the end user is too great, the performance of the connection will begin to suffer or quit working altogether.

According to some sources, there are twice as many cable internet subscribers than DSL users. Cable internet subscribers receive comparable performance to that of DSL users in terms of rate of data transmission and similar pricing structures. Instead of traveling over the phone lines, cable internet signals travel along coaxial cable exactly like cable television does. One of the main differences between cable internet and DSL is that many users utilize the same cable with cable internet access. This means that if your cable internet provider has too many subscribers on one line, you will notice slower connection speeds. So, with DSL the main issue is distance from the central office and with cable internet the issue is with how many subscribers share the same line.

T1 connections are most commonly used by large and medium sized business. Most smaller organizations simply cannot afford this type of connection. Typically, a T1 line is split into 24 56 or 64 kilobits per second channels to carry voice and data. While cable internet and DSL theoretically can reach the same speeds as a T1 line, they really never do in practical applications. With a T1 line, you don’t’ have to share the line with any other subscribers. This means that you can count on receiving a true 1.5 Megabits per second rate of data transfer.

For assistance in finding just the right solution for your business T1 bandwidth application(s)....comparing multiple providers available in your specific area....we highly recommend the no cost consulting services from:

"T1 Bandwidth Solution"

For assistance in finding the best fit for cable, DSL, or satellite service for residential use....comparing multiple providers available in your specific area....we highly recommend this free online tool:

"Shop For DSL"

Labels: , ,

Thursday, January 04, 2007

Insights on IP PBX

An IP PBX is great if you have the luxury of designing your system from the ground up. They are complete phone systems, usually with options that include many of the IP telephony applications, such as managing your phone from your desktop PC, multi-line call control and automatic call distribution.

IP PBXs are usually NT servers with telephony software and voice cards. Some disadvantages are the ability to scale the system and a dial tone that's dependent on NT, which doesn't offer the same uptime as a switched phone network.

Until recently IP PBXs have been targeted at offices with 100 users or less, but Alcatel recently announced a system that incorporates gateway and call processing in a single device and can accommodate up to 50,000 users. 3Com, Lucent and Cisco have all announced plans to provide the same type of product.

The beauty of an IP PBX is being able to create a distributed system. For example, allowing you to distribute your phone system throughout an IP network, so geographically separated phones with features such as direct dial, call forwarding, conferencing and voice mail provide the appearance of being connected directly to the local PBX.

For more information on IP PBX business applications we suggest you read the article: VoIP PBX Solutions For Businesses....What To Look For

For no cost assistance in finding the right IP PBX solution for your business we recommend the services at: IP PBX Equipment & Installation

Labels: , ,

Monday, January 01, 2007

How Do You Connect To A WiFi Hotspot?

A hotspot is a place where you can access Wi-Fi service, for free or for a fee. Hotspots can be found in airport lounges, coffee shops, corporate cafeterias or any other meeting area within range of a wireless LAN base station. More and more hotspot locations are popping up each day.

A single Access Point can be reached from a distance of no more than 100-200 meters (300-600 ft.), but there also exist Hotspots consisting of hundreds of Access Points which cover entire Airports, Hotels, or even Cities.

The first step is locating and connecting to the hotspot access point [see "How To Find A WiFi Hotspot" and "Wi-Fi HotSpot/Hot Zone Locator"]. In a wireless network, connecting to the access point is the same as plugging a cable into a hub or switch in a wired network. Wireless networks are identified by their SSID, which is the identifier for the network. Most wireless network clients will allow you to see a list of the networks available in an area. If you aren't able to see such a list, you might be able to tell your wireless card to connect to any available network.

In order to connect to a hotspot, you will need to get an IP address. In nearly every situation, your computer will do this for you automatically with DHCP. If you switch between different networks (wireless or otherwise), sometimes your computer may continue to use an IP lease from the previous network. In that case, you have to manually release and renew the lease. With Windows, you can use the ipconfig and winipcfg commands to interact with DHCP.

If you connect to a hotspot and get an IP address, but you are not able to reach other sites on the Internet, you may need to register with the provider. To log in, you need to open a new web browser window. Once you try to visit a website on the Internet, your HTTP request should be redirected to a page where you can log in. If you're not already a member of the specific hotspot provider you will have the opportunity to sign up.

Once you have signed up and logged in you are all set to utilize the hotspot!

For those interested in becoming a WiFi Hotspot themselves [nice little business opportunity] we suggest reading this article for tips and insights:

"How Do You Become A WiFi Hotspot?"

Labels: , , ,