Category Archives: VoIP

Unified Communications, VoIP

VoIP Implementation – Why Won’t the Audio Work?

I recently worked on a project that ended up being a success but looked at first like it could end up being a failure. We were doing a Voice over IP implementation and were putting in a new switch network for a client that had 8 sites. When the time came for implementation we ran into some difficulty with getting audio working out of the local branches. At first, we were stumped, but it ended up being an issue with a 3rd party provider. In the video, I discuss what the issue was, how we found it, and how we remedied it. I also provide some tips on how to avoid similar challenges. Hope you enjoy!

 

VoIP Implementation – Why Won’t the Audio Work?

Watch the video on GreenPages’ YouTube Channel.

 

If you have any questions around unified communications, please reach out!

 

 

By Ralph Kindred, Practice Director, Unified Communications

Disaster Recovery, Featured, Network, Network Infrastructure, Storage, Unified Communications, VoIP

Huh? What’s the Network Have to Do with It?

By Nate Schnable, Sr. Solutions Architect

Having been in this field for 17 years it still amazes me that people always tend to forget about the network.  Everything a user accesses on their device that isn’t installed or stored locally, depends on the network more than any other element of the environment.   It’s responsible for the quick and reliable transport of data. That means the user experience while working with remote files and applications, almost completely depends on the network.

However, this isn’t always obvious to everyone.  Therefore, they will rarely ask for network related services as they aren’t aware the network is the cause of their problems.  Whether it is a storage, compute, virtualization or IP Telephony initiative – all of these types of projects rely heavily on the network to function properly.  In fact, the network is the only element of a customer’s environment that touches every other component. Its stability can make or break the success and all important user experience.

In a VoIP initiative we have to consider, amongst many things, that proper QoS policies be setup –  so let’s hope you are not running on some dumb hubs.  Power over Ethernet (PoE) for the phones should be available unless you want to use bricks of some type of mid-span device (yuck).  I used to work for a Fortune 50 Insurance Company and one day an employee decided to plug both of the ports on their phone into the network because it would make the experience even better – not so much.  They brought down that whole environment.  Made some changes after that to avoid that happening again!

In a Disaster Recovery project we have to take a look at distances and subsequent latencies between locations.  What is the bandwidth and how much data do you need to back up?   Do we have Layer 2 handoffs between sites or is it more of a traditional L3 site to site connection?

If we are implementing a new iSCSI SAN do we need ten gig or one gig?  Do your switches support Jumbo Frames and flow control?  Hope that your iSCSI switches are truly stackable because spanning-tree could cause some of those paths to be redundant, but not active.

I was reading the other day that the sales of smart phones and tablets would reach approximately 1.2 billiion in 2013.  Some of these will most certainly end up on your wireless networks.  How to manage that is definitely a topic for another day.

In the end it just makes sense that you really need to consider the network implications before jumping into almost any type of IT initiative.  Just because those green lights are flickering doesn’t mean it’s all good.

 

To learn more about how GreenPages Networking Practice can help your organization, fill out this form and someone will be in touch with you shortly.

Network Infrastructure, Networking, Virtualization, VoIP

Virtual Appliances and the Networking Team

Over the last few years there has been a lot of progress made towards virtualizing a decent amount of the traditional, network-centric appliances that used to be just hardware based. Why are some companies still resistant to this software-based approach?  Is it because that’s the way it has always been, or is it inherent to the networking geeks who may be less virtualization-savvy than some of their cohorts in the other technology silos?  It reminds me of the days when VoIP was first being introduced and the subsequent lack of acceptance that some of the old-school, traditional telephony engineers fueled.  Some of them accepted it and others retired.  The point is though that it makes sense and those who accept it will be much the better for it.

With the dynamic today moving towards private and public cloud offerings, the virtual appliance marketplace will most certainly continue to grow and mature.  There are many reasons why this makes a lot of sense.

Take a look at the time it takes to implement a physical network appliance.  Let’s use an application delivery controller – or load-balancer if you prefer that term.  How long does it take to implement a physical box into an existing environment?  Between ordering the unit(s) which usually come in pairs, shipping, and installing, it takes some time.  The cables need to be run, the box racked and stacked and then physically powered on and provisioned.  We have been doing this for years and this used to be standard operating procedure. Now that works well and good, kinda, in your own data center.  What about a public cloud offering?  Sorry, you don’t own that infrastructure. How about downloading a virtual appliance, spinning up a VM and you are off to the races. Again, this happens after provisioning the unit, but there is a lot less moving parts going that route.  Cloud or not – either way it still makes sense.  There will be less infrastructure requirements: power, rack space, cabling etc.

There are some other tangible benefits as well.  From a refresh perspective it just makes sense to upgrade a virtual appliance with a newer image – or adding memory –rather than a hardware-based forklift upgrade every five years (with potentially more downtime required).  The ability to shrink or grow a virtual appliance is one of the things that set it apart.  We don’t have to repurchase anything – other than license keys and annual service contracts.  Regrettably, those won’t go away.  But coupled all together with the flexibility to move your virtual appliances along with your data from one environment to another is key.  We will see more and more network-centric appliances become virtualized.  There will most assuredly always be some physical boxes that the network folks can get their hands on, but that will be for access purposes only.

The companies/manufacturers/network-engineers who don’t embrace this trend could quickly find themselves behind the eight ball. Analog phones anyone?