|
Joined: Mar 2006
Posts: 6
Member
|
Member
Joined: Mar 2006
Posts: 6 |
Hi folks, I've been lurking here for the past year since our main office put in a new Axxess phone system. Main office is located in New York, but I work remotely from Iceland - yes, Iceland I have an Intertel VOIP endpoint with which I can connect to the main office no problem. Unfortunately, I've never been able to get the quality to be satisfactory - just too many drop outs and garbles. Plenty of bandwidth at both ends. I've gotten lots of conflicting information - the Intertel tech said that the IP packets are traversing too many hops - 18 - and that they don't recommend anything above 12-15. My ISP said it wasn't the hop count, but that there's no QoS on the network. Anyone have any ideas on what else I can try? It's really disappointing if this is never going to work right. Thanks, Lev.
|
|
|
Visit Atcom to get started with your new business VoIP phone system ASAP
Turn up is quick, painless, and can often be done same day.
Let us show you how to do VoIP right, resulting in crystal clear call quality and easy-to-use features that make everyone happy!
Proudly serving Canada from coast to coast.
|
|
|
Joined: Sep 2005
Posts: 840
Member
|
Member
Joined: Sep 2005
Posts: 840 |
If you cannot guarantee packet delivery, then you have a fundamental problem. The internet is geared towards IP traffic that can be re-sent if missing at the far end or if corrupt. Voice traffic cannot tolerate missing or corrupt packets or packets that arrive out of order at a high rate (jitter), that's why voice traffic uses UDP which does not care whether or not packets get to the destination to which they are addressed.
That being said, make sure your voice packets are using g.729 compression codec. Increase your frames per packet to 5. Increase your jitter buffer to 100.
While on a fone call, continuous ping the IPRC and monitor latency. Hang up and see what kind of change there is. Do a tracert to the IPRC. 18 hops is probably way too many, but what is more important is where the hops go.
Bandwidth is important but QOS is king. I have many sites w/ 256 frame relay circuits supporting 5 + IP fones and all the data needs for that location and voice quality is great, because I can guarantee packet delivery.
|
|
|
|
Joined: Mar 2006
Posts: 6
Member
|
Member
Joined: Mar 2006
Posts: 6 |
Thanks, superfoneguy.
Can you tell me how to check the compression codec, inrease frames per packet, and change jitter buffer? I can http/telnet into the IPRC where one can see info, but there are not a lot of options to change.
I did continuously ping during and after a call, and didn't really notice any changes - consistently around 180ms - though earlier in the day they tend to be around 100ms.
Thanks, Lev.
|
|
|
|
Joined: Sep 2005
Posts: 840
Member
|
Member
Joined: Sep 2005
Posts: 840 |
You need to use DB Studio to change those settings. The settings are located under System\IP Related Info\Call Config Groups
180 ms is on the very upper edge of acceptable, in fact it's probably unacceptable. The manufacturer recommends no more than 250 ms latency, which is silly slow. If you came to me ahead of time and asked if 180 ms latency would permit good VOIP, I'd say no.
BTW, what ver. is yer fone and yer IPRC?
|
|
|
|
Joined: Mar 2006
Posts: 7
Member
|
Member
Joined: Mar 2006
Posts: 7 |
I use a bunch of different versions of the IP phones, many of them at ~300ms round trip latency. The biggest problem with quality I experience is normally bandwith saturation. With a business line or DSL lines you can be hitting close to 95% utilization and "normal" web traffic will not be impacted to the point of people complaining, however with VOIP, anything more then 50% utlization and you will start to get breakups. This mirrors the QoS comment, as QoS will get you that extra 40% of usage without things being impacted to severly. With QoS in service, packets that are VOIP based (at least that you are sending) will be pushed to the front of the que. If you are using >90% of your line, no matter what you do the quality will suffer.
After bandwidth the biggest offender has been users running PtP sharing software (napster, bittorrent, donkey, etc). This makes many thousands of connections with normally small packets that will both mess with your QoS (if done by size) or overload the CPU / State tables of many Soho routers. Once again, it may not be noticed with web browsing but impacts Voip severely.
If you are using older firmware on the IPRC or Phones (earlier then 2003), I have noticed signifigant improvement after upgrading. Before I went and made sure every phone was on the same version I could have two people sitting beside each other in the same remote office, and only one having a problem.
|
|
|
|
Joined: Mar 2006
Posts: 6
Member
|
Member
Joined: Mar 2006
Posts: 6 |
Phone is an 8662, and IPRC is running firmware 9.0.0
Following are the previous settings, and in parentheses are the new values I put in. With the new values, the quality is actually better, but the phone seems to lose its connection every few minutes, and during the call I got a "insufficient bandwidth" message on the phone.
Audio Frames/IP Packet: 3 (new: 5)
Average In Time Frame Percentage Threshold: 60 (new:100)
Average In Time Framer Timer: 3 (new: 5) Echo Suppression Sensitivity Level (%): 60 (new: 100)
Minimum Playback Time: 80 (new: 100)
Transmit DTMF Level USA: USA -9 -7 DTMF Decoding Setting: G.7-11(new: G.729) Speech Encoding Setting: G.729 Echo Saturation Blocker: Yes Echo Suppression: Yes Thanks for your help superfoneguy. I'd really like to get this as good as I can before I throw in the towel. Lev.
|
|
|
|
Joined: Sep 2005
Posts: 840
Member
|
Member
Joined: Sep 2005
Posts: 840 |
If you browse to the fone you can retrieve the F/W level.
I would put yer echo suppresion back to 60 unless you get alot of echo on calls. The DTMF Decoding setting should be RFC 2833. I also disable the Echo Saturation Blocker.
I gave you bad advice on the Average In Time % and Average In Time Frame Timer. Set the % to 40, put the other to it's default value. That's why it's resetting more.
|
|
|
|
Joined: Mar 2006
Posts: 6
Member
|
Member
Joined: Mar 2006
Posts: 6 |
F/W for the phone appears to be 1.1.5, though I can't browse to it.
Thanks, made those changes. Connection isn't getting broken now, but the quality seems to be back to where it was before. Here are the settings: Audio Frames/IP Packet: 5 Average In Time Frame Percentage Threshold: 40 Average In Time Framer Timer: 3 Echo Suppression Sensitivity Level (%): 60 Minimum Playback Time: 100 Transmit DTMF Level USA: USA -9 -7 DTMF Decoding Setting: RFC 2833 Speech Encoding Setting: G.729 Echo Saturation Blocker: NO Echo Suppression: Yes
|
|
|
Forums84
Topics94,530
Posts640,036
Members49,852
|
Most Online5,661 May 23rd, 2018
|
|
|
|