This forum includes tips for maintaining the best audio quality possible with the Ooma System. If your Ooma system is having issues with dropped calls, static audio or echo, look here for assistance.
#16947 by Aveamantium
Sun Aug 23, 2009 6:07 am
skowbuzz wrote:ok i just upgraded to 384k up and i think 2mb down. Here is my new chart consistently with QOS set to "0" in down and up and using the 130 default for calls. How can i improve tcp delay?

VoIP test statistics
--------------------
Jitter: you --> server: 0.8 ms
Jitter: server --> you: 3.6 ms
Packet loss: you --> server: 0.0 %
Packet loss: server --> you: 0.0 %
Packet discards: 0.0 %
Packets out of order: 0.0 %
Estimated MOS score: 4.0

Speed test statistics
---------------------
Download speed: 1857400 bps
Upload speed: 334232 bps
Download quality of service: 88 %
Upload quality of service: 91 %
Download test type: socket
Upload test type: socket
Maximum TCP delay: 257 ms
Average download pause: 16 ms
Minimum round trip time to server: 104 ms
Average round trip time to server: 106 ms
Estimated download bandwidth: 1857400bps
Route concurrency: 1.0
Download TCP forced idle: 0 %
Maximum route speed: 5041152bps

You can't improve delay with Qos, this is an ISP issue. Qos (from the standpoint of the Ooma) basically sets aside bandwidth (in your case this is disabled since you've entered a "0" for both) so the rest of your LAN doesn't use it all up causing calls to be choppy.
#16949 by skowbuzz
Sun Aug 23, 2009 6:52 am
ok i now changed my Qos in download to 1600 since i have 2000k minus 20% and still left the upload Qos at"0". Now tcp is lower since i changed my down QOS?
Should i just leave the Qos alone now? Does it look good now. Calls seem clear for now.
VoIP test statistics
--------------------
Jitter: you --> server: 2.2 ms
Jitter: server --> you: 4.2 ms
Packet loss: you --> server: 0.0 %
Packet loss: server --> you: 0.0 %
Packet discards: 0.0 %
Packets out of order: 0.0 %
Estimated MOS score: 4.0

Speed test statistics
---------------------
Download speed: 884288 bps
Upload speed: 333360 bps
Download quality of service: 99 %
Upload quality of service: 93 %
Download test type: socket
Upload test type: socket
Maximum TCP delay: 41 ms
Average download pause: 33 ms
Minimum round trip time to server: 108 ms
Average round trip time to server: 114 ms
Estimated download bandwidth: 884288bps
Route concurrency: --
Download TCP forced idle: --
Maximum route speed: 4854440bps
#16954 by dtalwar
Sun Aug 23, 2009 7:28 am
The numbers look a lot better ... sorry, I can't seem to remember (or find in the topic), is your Hub between Modem and Router. If so, you probably want to reserve some bandwidth for upstream as well, so the voice calls get priority over other packets.
#16955 by Aveamantium
Sun Aug 23, 2009 7:47 am
I would enter about 350 for your upload as that is the most limited aspect of your network. With this setting, when your on a call your phones will get 130 (assuming that you left the default) and your LAN will get the remaining 220 kbps.
#16971 by Aveamantium
Sun Aug 23, 2009 9:09 am
skowbuzz wrote:i am supposed to be doing the voip test while on a call right?

The VoIP test simulates a VoIP call, so no you should not be on a call when testing this.
#16975 by skowbuzz
Sun Aug 23, 2009 9:34 am
yes because i put 2000kb in Qos download from 0. My problem was hearing on my end and now is better. odd though that tcp is way better(48) when testing while on a call then when not on a call(285)?
#17040 by niknak
Sun Aug 23, 2009 5:57 pm
...odd though that tcp is way better(48) when testing while on a call then when not on a call(285)?..


your network has something to do when it's moving packets as opposed to just idling

Who is online

Users browsing this forum: Google [Bot] and 8 guests