[lug] Business VOIP Advice...

Ferdinand Schmid fschmid at archenergy.com
Wed Sep 2 10:18:04 MDT 2009


Hello Ryan,
 
Your ISP and VOIP provider should take care of all QOS requirements.  If they don't then they aren't worth their money in my book.  I have worked with two Internet + VOIP providers for the past 8 years and have never had QoS issues (CBeyond and XO communications, Tier 1 provider).  They both use a setup that takes bandwidth away per voice line in use.  This is implemented with Cisco gear designed for this application (on both ends).  In this case you don't have to worry about QoS at all because you split the bandwidth between voice and data.
 
Ferdinand
 
--
Ferdinand Schmid
IT Manager
Architectural Energy Corporation
Phone: 303-459-7431


>>> On 9/2/2009 at  8:52 AM, in message <Pine.LNX.4.21.0909020849440.9693-100000 at magellan.rkirkpat.net>, Ryan Kirkpatrick <linux at rkirkpat.net> wrote:

I am in need of some VOIP advice, and given the past discussions on VOIP
(including at least one meeting), I thought this would be the best place.

Briefly, how do you deal with inbound VOIP packets being dropped when the
telco refuses (for their own VOIP service) to put QoS on their end of the
T1/DSL/Cable? For more details, read on...

I am the sys-admin for a local company, and we recently upgraded our phone
(and Internet) service to VOIP. We previously had a T1 split (fixed)
between 12 phone lines and 768kbps Internet (data) from a certain major
telco I will call Flat11. After some support issues we learned that this
service was considered legacy and if we wanted better support we should
upgrade to their enterprise integrated VOIP and data service.

This new service was a T1 setup for all data, with the 12 phone lines
delivered via VOIP. We were provided with an Adtran 916 router that would
terminate the VOIP lines back into analog phone lines for our internal
phone systems (it has an AMP connector on the back for connecting to a 66
block). The Adtran came configured to do QoS for outbound data, making
sure the VOIP packets got priority over any data packets.

The problem we have encountered is that incoming VOIP packets are being
dropped, resulting in audio drop-outs that make our customers sound like
they are on really bad cell phones. Now, this same T1 also provides
Internet to about 14 users (most light users, a few moderate). Of course
the problem gets much worse when someone has to download a DVD image of
software needed for some piece of equipment (and of course they complain
the T1 is slow :).

Now, I have spoken at length with Flat11, explaining to them that they
need to do the same QoS on their end. That is, make sure inbound VOIP
packets get priority over data packets. At first they had no clue what I
was asking, then eventually a tech tried to do it and found that the Cisco
in the CO (at the other end of our T1) does not support QoS. Now they are
telling me QoS is not supported for this product!

So, what are my options? Is it expected for the telco to provide QoS for
VOIP, or am I asking for too much? What other options are there to resolve
this issue? Anyone have any experience with a similar situation that can
provide me with advice? Otherwise we are going to chuck this
"new-fangled VOIP thingy" and go back to copper lines! Thanks!

PS. If you look at 'Flat11' the right way, you can tell which company I am
talking about. :)

---------------------------------------------------------------------------
|   "For to me to live is Christ, and to die is gain."                    |
|                                            --- Philippians 1:21 (KJV)   |
---------------------------------------------------------------------------
|   Ryan Kirkpatrick  |  Boulder, Colorado  |  http://www.rkirkpat.net/   |
---------------------------------------------------------------------------



_______________________________________________
Web Page:  http://lug.boulder.co.us
Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
Join us on IRC: lug.boulder.co.us port=6667 channel=#hackingsociety
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lug.boulder.co.us/pipermail/lug/attachments/20090902/2bfd59dc/attachment.html>


More information about the LUG mailing list