[lug] Business VOIP Advice...

Nate Duehr nate at natetech.com
Wed Sep 2 11:30:49 MDT 2009


Agreed with another commenter.  The VoIP + Data provider NEEDS to
describe to YOU (the customer) how THEY are keeping the voice traffic
from being bothered by the data traffic. 

If they can't describe how they're handling this to your satisfaction,
you need to switch to a vendor-with-a-clue...

Sorry that's not more positive, but it's "not your problem"... they want
to play in telephony, they need to step up, or step off.

Ask them how they'll keep a large download from a user PC from blocking
audio on a 911 call.  That'll get their attention.  It'll also work to
get your boss's attention.

If they can't answer the question to your satisfaction, dump them.

--
  Nate Duehr
  nate at natetech.com

On Wed, 02 Sep 2009 08:52 -0600, "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



More information about the LUG mailing list