atcomsystems.ca/forum Forums VOIP Phones & IP PBX VoIP & Cloud Phones, Hosted PBX, General IP Phones voip quality and dropped calls

Thanks Whity, we have performed the tests and the system was upgraded about a year and a half ago. Our problems are not constant. Tests sometimes show almost no errors. The problems and no explanition such as storms etc. Real frustration.

Have you looked at clocking problems? If you have point-to-point T1s one end has to provide the clocking for the other end.

Volguy:

You said:
"We have two seperate systems. One for Chattanooga, Nashville and Denver. The other is Lakeland and Ft Lauderdale Fl."

In an ideal situation, with 5 locations, you should have 5 seperate systems or 5 independent gateways. I represent a manufacturer that would have "gateways" at each location. These gateways would have local phone lines for making calls and a WAN connection to network the different locations for inter-office calls and "least cost routing".

Please explain only 2 seperate systems.

As you have a lot of things going on in your network, you will need to start some place as a base line.
Not only do you need to have QoS on the routers, it is also required on any data switch’s the VoIP network’s pass through.
As for MPLS this would be a good place to start for base line. I would set up something like Ether-real at each site to monitor packets to compare what is being sent and when/if it is being received at the other end.
If a smart data switch is installed you may be able to do port mirroring, this allows you to monitor both way traffic from another port. Or install a hub just for test.
I had a site with MPLS 2 miles apart (in FL), after vendor set up above monitoring, the provider admitted to porting some traffic to Texas then back exceeding 150ms.
This is just a starting point, with a network your size it will take time to isolate all issues.
Good luck!

Thanks guys for your suggestions. I will get to work checking these items and will be back. Thanks again.
Volguy

I'm a Telrad guy and SSphones is too. Are you TVSE to TVSE to the two systems or t-1 card to t-1 card. What version on the IPex or MPD2 or MPD400 and the TVSE. To fine this info on the TVSE card, you need to web broses into the TVSE card. On the MPD2 or IPEX card you need the programing software. On the MPD400 you can look at the card. You say you upgrade about a year ago. There have been software upgrades since then the latest on the TVSE (witch is the Voip sever)is 3.43. But you need to have an mpd2 or ipex. If you have an MPD400 I think the latest is 2.07.
Internet connection: T1 point to point Chattanooga to Nahsville and T1 point to point Chattanooga to Denver. Is this connected by t-1 cards or TVSE cards.

I can tell you I have first hand knowledge of the system here in Lakeland. I have been there to cut over from Verizon to USLec on the PRI. But none of the problems listed above have ever been passed on down to me. This is a Signal V&D customer, Signal sent there head installer and CSR here to Lakeland to install the system. I just did the above call. I would think the guys at Signal would want to know about this so I will email them to give them the heads up. If they cant fix the issue contact Telrad.

And I have to say sorry for not seeing this sooner. To bad this didnt get into the Telrad section.

Here are some general parameters I use when designing VoIP networks. ALWAYS no matter what anyone might tell you (and I understand people are probably going to get angry with me) PUT THE VOICE ON A SEPERATE SUBNET!!! There is a myriad of reasons to do this but let me state just a few.

1. Varying natures of voice and data traffic.
Data traffic tends to be bursty but inconsistent. Voice traffic (assuming you are running g729) is consistent but has a small payload. The differing natures require separate strategies to manage traffic.

2. QoS - It is so much easier to "trust" traffic from a specific subnet then to try to determine what L4 port is being triggered.

3. Segregation keeps local problems local. It is sort of like a quarantine fish tank. Say for instance a NIC is causing a broadcast storm; this problem will by nature propagate into your voice network since you are running a flat topology.

Regardless if I am putting in a small network for a customer or I am designing a network for a large enterprise I always create separate VLANs for Voice, Video, Data, Servers and Management. Therefore when they DO decide to deploy Voice or Video, the IP addressing and network infrastructure is already in place. I advertise the network as a supernetted network and subnet the VLANs down at the LAN level. That way I am not advertising 5 networks into OSPF or EIGRP I am advertising one.

My question to you is where are you doing QoS? QoS must be approached comprehensibly. You must do QoS at L2 and L3 and it should be end to end. Anywhere you are ignoring this will become the Achilles heal of your design.

Another question I have for you is have you setup a SPAN session on your switch to monitor your WAN traffic? You should put a sniffer on your WAN and determine what protocols you are running. Based on a good study of this you can make a determination of what is causing the problems.

Lot's of good info posted here. Some times it's something simple that will cuase VOip problems. I would definately put a packet sniffer on the LAN and see what kind of traffic is going on during the tmie of lost calls. If the Qos isn't set up properly and at the right levels things can slip by and defeat the Qos. Could be some one on their lunch break streaming some audo and video to thier pc or a number of people listening to an internet radio station. These will all suck up the pipe and damage the throughput. A packet sniffer might give a hint to see if this is the issue.