Hi all this is my first thread but I enjoy all of the knowledge and helpful information in here all the time. I hope someone here can help me with an issue I am having. I have 7 2000 ips's in a network. We recently changed all of our ccis to ip ccis in preperation to us moving to a metro ethernet. Right now all of our sites are connected via point to point t1's. We have cisco 3560's everywhere and have implemented qos on the PBX's and the cisco equipment. I am pretty sure we are experiencing problems because of the bandwidth issue of the t1's but im wondering if anyone knows any tricks to help us clean up the voice until we convert to the metro ethernet. Some calls go without a hitch and some are terrible. We have adtran ta 850's on the ends of the t1's and i know they dont support qos. Thanks for any help.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chris Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
VOIP Quality issues
- Thread starter sameyeam
- Start date
belevedere
Instructor
Make sure that CMD 0A22>xx>0 for linear process control is provided. It is not at default. Also CMD 0A29>xx>55 presidence, is suggested that this be hard coded and not left at default. You do not mention if you are using IP phones or just IP trunking. In either case you should have a voice VLAN set up. Any change to CMD 0A requires a PAD card reset. Aside from that, the rev levels of the PAD cards should be the latest and the same throughout the network. These suggestions refer to peer to peer IP CCIS and not the IP trunk card method.
a. Check the port where the phone system is connected in the 3650 for errors. Are there any?
b. Put a sniffer and see if the priority is passing off from site a to site b.
c. The QoS needs to implemented on the carrier side too. In other words, say you were at the beach in Indonesia and you controlled all the water going out to the sea but you have no protection for the water coming in. A tsunami would wipe you off your feet or more. The same goes for QoS. If you control the stuff coming in but at the gateway i.e. the Adtran you do not have protection, then the water comes into the beach already and whatever kind of QoS you try it is too late. Your bandwidth for the T1 is 1.544mb and that can get filled up easily. Even the metro Ethernet is not full protection unless your carrier will implement QoS on their side too. The analogy would be the size of the beach offers no help. But breakers in the see may stop the water from flooding you.
There is more to the story. Lets hear where you are up to.
b. Put a sniffer and see if the priority is passing off from site a to site b.
c. The QoS needs to implemented on the carrier side too. In other words, say you were at the beach in Indonesia and you controlled all the water going out to the sea but you have no protection for the water coming in. A tsunami would wipe you off your feet or more. The same goes for QoS. If you control the stuff coming in but at the gateway i.e. the Adtran you do not have protection, then the water comes into the beach already and whatever kind of QoS you try it is too late. Your bandwidth for the T1 is 1.544mb and that can get filled up easily. Even the metro Ethernet is not full protection unless your carrier will implement QoS on their side too. The analogy would be the size of the beach offers no help. But breakers in the see may stop the water from flooding you.
There is more to the story. Lets hear where you are up to.
You MUST have QOS support on the router at both ends of the T1. Without this you are wasting your time. The horrible sounding calls are packet loss as you are attemptiing to pass more data over the WAN than you have bandwidth to support. As there is not adaquate room for all the data and voice to travel at the same time the packets start getting into a queue in the router. If the voice packet queues and does not get to the other side within 150ms the jitter buffer at the far end will never process the packet so small pieces of voice will be dropped giving the choppy, sometimes robotic voice. One option would be to try dropping down to the G729 codec which will require less bandwidth due to the voice compression done by the IPLA card. Otherwise without layer 3 equipment that supports some form of QOS you will not be able to defeat the issue.
- Status
Similar threads
- Locked
- Question
