Bandwith for VoIP sets

[gm85]

Hi Everyone,

I am currently in the process for setting up our teleworkers with IP phones. Now this may be more of a networking-related problem, but I thought I'd see what you guys think

We have our BCM connenected to a VPN router, which is connected to a cable connection (6MB down, 800K up) that is used ONLY by the BCM for VoIP traffic.

Our telewokers also have a VPN router with their cable connections (7MB down, 512K up), with QoS enabled to provide 160K LLQ upload for VoIP traffic (looks for EF voice and CS5 signaling traffic). We are all on the same ISP; therefore we're only 1-2 hops away and have 20ms latency between sites.

With the way it is set up, this should mean that we should have at least 160kbps bandwidth for traffic between the BCM and ip phones.

Now when we have 2 teleworker phones connected, the phones are stable and there are no problems with voice quality whatsoever. However, when I add the 3rd phone, we begin to see the phones randomly reset (a sign that signaling packets are being dropped) about once a day, plus one of our teleworkers complain of poor voice quality.

from my calculations, we should be able to support 4 phones without any problems (the BCM cable upload is 800kbps / 4 phones = 200kbs per phone). Does that seem right? or am I losing my mind?

I have done speed tests at all the sites to make sure we are getting the "claimed" speed. currently, my only option seems to bump the BCM's cable connection up to a 8MB/1MB connection and see if that helps.

Thanks

 

[Dasheen]

what codec are using?

 

[gm85]

G.711ulaw, 30ms payload, small jitter buffer,
BCM Monitor estimates bandwidth of 158.9kbps.

I've checked the QOS logs on the teleworker routers and they indicate that no voice packets are dropped.

My guess is that it is with the connection to the BCM, since problems begin to occur with all sets, when adding a 3rd set (whereas if the problem was at the teleworker site, the teleworker would have intermittent problems with their phone, regardless if it was 1, 2 or 3 sets attached to the system)

However, wouldn't 800kbps for the BCM would be more than enough for 3-4 sets?

 

[CyberX666]

I would have a go at setting your BCM IP phones at the remote sites to G.729 codec, under IP terminal details.

 

[pronei]

is 800K the actual throughput or is that advertised speed?

 

[Crowtalks]

I would set the default codec in the BCM at G.729 with G.711 as secondary.

It sounds like your upload isn't getting anywhere close to the advertised settings and your reserved QoS is gobbling up the available bandwidth.

I run several IP terminal across WAN connections to different ISP and use G.729 for each with no problems. The compression for 729 even using ATM overhead comes up to less than 40 kpbs per phone

NCSS NCTS NCTE

 

[gm85]

Thanks everyone for the responses.

I may try some testing with G.729 and see what the voice quality is like, however I'm beginning to think my problem is not a bandwidth issue. I tested the BCM connection and found it was 5917kbps / 797kbps (and the advertised speed was 6000/800)... however I'm wondering if my issue is related to packet loss (which really concerns me).

What triggered this concern is that the phones would reboot at random times during the day/night, with the majority of times being when there is no call traffic (so there would be plenty of bandwidth available for signaling traffic). As such, there are 3 possible problems / solutions I am investigating.

1: One of the telewokers has kids, who use P2P applications heavily and I think it is "overloading" my QoS setup. Although this should only affect that one teleworker; I'm going to look into throttling excessive data on their router during the workday, so that it won't affect the phones (hey if they want to swamp their connection after hours.... be my guest, the phones aren't used then anyways). I have informed them, however, that if this continues, they will have to upgrade to the next speed package (which fortunately doubles their upload speed to 1mbps)

2: In the Nortel Converging Voip and Data Network / Voice Quality Management documentation, it states that voice traffic should be assigned LLQ and call signaling should be assigned its own queue for connections under 768k. While this doesn't make sense to me (I currently have both signaling and voice assigned to LLQ, so both protocols are assigned priority over everything else), there is no harm in trying out that setup.

3: [small](and I hope this is not the issue... but I'm beginning to think it may be)[/small]. When we had our Cable connection installed for the BCM, we had major signal problems, resulting in packet loss and the modem continuously re-synching. The ISP came out and ran us a temp line and everything worked flawlessly. However, 2 weeks ago, they came and buried the permanent line for us, which is I THINK around the same time these issues began to appear. The problem is I've been monitoring the cable modem and the signal is strong and has been stable. I've also been performing numerous ping tests and everything has been successful, with no packet loss and stable round-trip times.

So I really don't know, this is a HUGE head scratcher for me, but I'll keep you guys informed what I try / figure out.

Thanks!

 

[Crowtalks]

Try a continuous ping back to the BCM from the sites and see if you're having latency or loss problems.

ping xxx.xxx.xxx.xxx -t

Use Crtl C to stop it.

NCSS NCTS NCTE

 

[gm85]

UPDATE: Well, I found out the problem was due to packet loss. It was VERY intermittant (3 packets out of 2000-attempt ping) however when it occured, data stopped transmitting / receiving for about 6 seconds.

On Monday, we had a service outage and found out it was due to maintenance. Since the outage, everything has been stable and working great. We've had no call quality problems and the phones have even been online since the outage.

I decided to kept call signaling packets in their own queue. Although I'm aware that the call problems were due to the outage, it just seems better to have them in their own queue.

I'm really happy that now I got this weight off my shoulder and that the problem was fixed. Thanks to everyone who provided suggestions!