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.
#66109 by jr2
Mon Oct 04, 2010 1:43 pm
Hello all,

I use Time Warner Cable (standard $53 a month cable only residential package), and I've been experiencing bad call quality occasionally, as well as a very persistent problem in which when I make an outgoing call and it is answered, I either cannot hear anything or there is a stuttering sound that continues until I hang up (nothing can be heard over this sound; the other party can hear me).

I tried resetting the OOMA device with no permanent success. This problem didn't occur at first with OOMA; it happened within the past few months. I used to use Vonage before I ported to OOMA with absolutely no problems. Then I used OOMA and was satisfied for a month or two, but now I don't know what to do.

Any help would be appreciated.

EDIT: Oh, and the whichvoip.com results ... well these ones say the jitter is ok, but the test I ran before that was horrible - I'll try to post back the results if I can find it when it's misbehaving.

whichvoip.com results:

VoIP test statistics
--------------------
Jitter: you --> server: 4.1 ms
Jitter: server --> you: 7.8 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: 3.9

Speed test statistics
---------------------
Download speed: 2741280 bps
Upload speed: 983120 bps
Download quality of service: 67 %
Upload quality of service: 98 %
Download test type: socket
Upload test type: socket
Maximum TCP delay: 492 ms
Average download pause: 13 ms
Minimum round trip time to server: 107 ms
Average round trip time to server: 111 ms
Estimated download bandwidth: 32000000bps
Route concurrency: 11.673379
Download TCP forced idle: 85 %
Maximum route speed: 4899808bps


ICSI Netalyzr results:

Result Summary +/– (help)
cpe-74-70-238-238.nycap.res.rr.com / 74.70.238.238
Recorded at 17:36 EDT (21:36 UTC), Oct 04 2010. Permalink. Client/server transcript.
Summary of Noteworthy Events –
Minor Aberrations
The measured packet loss was somewhat high
The network measured bursts of packet loss
Network packet buffering may be excessive
Your DNS resolver returns results even when no such server exists
Your computer's clock is slightly fast
Address-based Tests –
NAT detection (?): NAT Detected
Your global IP address is 74.70.238.238 while your local one is 192.168.1.3. You are behind a NAT. Your local address is in unroutable address space.

Your machine numbers TCP source ports sequentially. The following graph shows connection attempts on the X-axis and their corresponding source ports used by your computer on the Y-axis.


TCP ports are not renumbered by the network.

DNS-based host information (?): OK
You are not a Tor exit node for HTTP traffic.
You are listed on the Spamhaus Policy Based Blacklist, meaning that your provider has designated your address block as one that should only be sending authenticated email, email through the ISP's mail server, or using webmail.
The SORBS DUHL believes you are using a dynamically assigned IP address.
Reachability Tests –
TCP connectivity (?): OK
Direct TCP access to remote FTP servers (port 21) is allowed.
Direct TCP access to remote SSH servers (port 22) is allowed.
Direct TCP access to remote SMTP servers (port 25) is allowed.
Direct TCP access to remote DNS servers (port 53) is allowed.
Direct TCP access to remote HTTP servers (port 80) is allowed.
Direct TCP access to remote POP3 servers (port 110) is allowed.
Direct TCP access to remote RPC servers (port 135) is allowed.
Direct TCP access to remote NetBIOS servers (port 139) is allowed.
Direct TCP access to remote IMAP servers (port 143) is allowed.
Direct TCP access to remote SNMP servers (port 161) is allowed.
Direct TCP access to remote HTTPS servers (port 443) is allowed.
Direct TCP access to remote SMB servers (port 445) is allowed.
Direct TCP access to remote SMTP/SSL servers (port 465) is allowed.
Direct TCP access to remote secure IMAP servers (port 585) is allowed.
Direct TCP access to remote authenticated SMTP servers (port 587) is allowed.
Direct TCP access to remote IMAP/SSL servers (port 993) is allowed.
Direct TCP access to remote POP/SSL servers (port 995) is allowed.
Direct TCP access to remote OpenVPN servers (port 1194) is allowed.
Direct TCP access to remote PPTP Control servers (port 1723) is allowed.
Direct TCP access to remote SIP servers (port 5060) is allowed.
Direct TCP access to remote BitTorrent servers (port 6881) is allowed.
Direct TCP access to remote TOR servers (port 9001) is allowed.
UDP connectivity (?): OK
Basic UDP access is available.

The applet was able to send fragmented UDP traffic.

The applet was able to receive fragmented UDP traffic.

Direct UDP access to remote DNS servers (port 53) is allowed.
Direct UDP access to remote OpenVPN servers (port 1194) is allowed.
Direct UDP access to remote MSSQL servers (port 1434) is allowed.
Path MTU (?): OK
The path between your network and our system supports an MTU of at least 1500 bytes, and the path between our system and your network has an MTU of 1500 bytes.

Network Access Link Properties –
Network latency measurements (?): Latency: 34ms Loss: 11.0%
The round-trip time (RTT) between your computer and our server is 34 msec, which is good.
We recorded a packet loss of 11%. This loss is very significant and will lead to serious performance problems. It could be due either to very high load on our servers due to a large number of visitors, or problems in your network. Of the packet loss, at least 11.0% of the packets appear to have been lost on the path from your computer to our servers.
TCP connection setup latency (?): 44ms
The time it takes your computer to set up a TCP connection with our server is 44 msec, which is good.
Network background health measurement (?): 2 transient outages, longest: 3.0 seconds
During most of Netalyzr's execution, the applet continuously measures the state of the network in the background, looking for short outages. During testing, the applet observed 2 such outages. The longest outage lasted for 3.0 seconds. This suggests a general problem with the network where connectivity is intermittent. This loss might also cause some of Netalyzr's other tests to produce incorrect results.
Network bandwidth measurements (?): Upload 980 Kbit/sec, Download 3.0 Mbit/sec
Your Uplink: We measured your uplink's sending bandwidth at 980 Kbit/sec. This level of bandwidth works well for many users.
Your Downlink: We measured your downlink's receiving bandwidth at 3.0 Mbit/sec. This level of bandwidth works well for many users.
Network buffer measurements (?): Uplink 1000 ms, Downlink is good
We estimate your uplink as having 1000 msec of buffering. This is quite high, and you may experience substantial disruption to your network performance when performing interactive tasks such as web-surfing while simultaneously conducting large uploads. With such a buffer, real-time applications such as games or audio chat can work quite poorly when conducting large uploads at the same time.
We were not able to produce enough traffic to load the downlink buffer, or the downlink buffer is particularly small. You probably have excellent behavior when downloading files and attempting to do other tasks.
HTTP Tests –
Address-based HTTP proxy detection (?): OK
There is no explicit sign of HTTP proxy use based on IP address.
Header-based HTTP proxy detection (?): OK
No HTTP header or content changes hint at the presence of a proxy.
HTTP proxy detection via malformed requests (?): OK
Deliberately malformed HTTP requests arrive at our server unchanged. Thus, the proxies along your path are able to transparently forward invalid HTTP traffic.
Filetype-based filtering (?): OK
We did not detect file-content filtering.
HTTP caching behavior (?): OK
There is no suggestion that a transparent HTTP cache exists in your network.
JavaScript-based tests (?): OK
The applet was not run from within a frame.
Your web browser reports the following cookies for our web page:
netAlizEd = BaR (set by our server)
netalyzrStatus = running (set by our server)
Your web browser was unable to fetch an image using IPv6.
DNS Tests –
Restricted domain DNS lookup (?): OK
We are able to successfully lookup a name which resolves to the same IP address as our webserver. This means we are able to conduct many of the tests on your DNS server.
Unrestricted domain DNS lookup (?): OK
We are able to successfully lookup arbitrary names from within the Java applet. This means we are able to conduct all test on your DNS server.
Direct EDNS support (?): OK
EDNS-enabled requests for small responses are answered successfully.
EDNS-enabled requests for medium-sized responses are answered successfully.
EDNS-enabled requests for large responses are answered successfully.
DNS resolver address (?): OK
The IP address of your ISP's DNS Resolver is 208.67.217.10, which resolves to bld4.nyc.opendns.com.
DNS resolver properties (?): Lookup latency: 110ms
Your ISP's DNS resolver requires 110 msec to conduct an external lookup, and 31 msec to lookup an item in the cache. It takes 73 msec for your ISP's DNS resolver to lookup a name on our server.
Your resolver correctly uses TCP requests when necessary.
Your resolver is using QTYPE=A for default queries.
Your resolver is not automatically performing IPv6 queries.
Your DNS resolver does not use EDNS.
Your DNS resolver can successfully accept large responses.
Your resolver does not use 0x20 randomization, but will pass names in a case-sensitive manner.
Your ISP's DNS resolver respects a TTL of 0 seconds.
Your ISP's DNS resolver respects a TTL of 1 seconds.
Your NAT has a built in DNS proxy.
No transport issues were discovered which could affect the deployment of DNSSEC
DNS glue policy (?): OK
Your ISP's DNS resolver accepts generic glue records located in subdomains of the queried domain.
Your ISP's DNS resolver accepts additional (glue) records for nameservers located in subdomains of the queried domain.
Your ISP's DNS resolver follows CNAMEs when it is in a subdomain of the queried domain.
DNS resolver port randomization (?): OK
Your ISP's DNS resolver properly randomizes its local port number.
The following graph shows DNS requests on the x-axis and the detected source ports on the y-axis.

DNS lookups of popular domains (?): OK
77 of 77 popular names were resolved successfully. Show all names.
8 popular names have a mild anomaly. The ownership suggested by the reverse name lookup does not match our understanding of the original name. The most likely cause is the site's use of a Content Delivery Network. Show all names.
7 popular names have a mild anomaly: we are unable to find a reverse name associated with the IP address provided by your ISP's DNS server. This is most likely due to a slow responding DNS server or misconfiguration on the part of the domain owner. Show all names.
DNS external proxy (?): OK
Your host ignores external DNS requests.
DNS results wildcarding (?): OpenDNS
You appear to be using OpenDNS. OpenDNS, by default, deliberately returns addresses even for domain names which should not resolve. Instead of an error, the DNS server returns an address of 67.215.65.132, which resolves to hit-nxdomain.opendns.com. You can inspect the resulting HTML content here.

This is central to OpenDNS's business model. In order to support an otherwise free service, OpenDNS presents the users with advertisements whenever they make a typo in their web browser. You can disable this behavior through the OpenDNS Dashboard.

The big problem with this behavior is that it can potentially break any network application which relies on DNS properly returning an error when a name does not exist.

The following lists your DNS server's behavior in more detail.

www.{random}.com is mapped to 67.215.65.132.
www.{random}.org is mapped to 67.215.65.132.
fubar.{random}.com is mapped to 67.215.65.132.
http://www.yahoo.cmo [sic] is mapped to 67.215.65.132.
nxdomain.{random}.netalyzr.icsi.berkeley.edu is mapped to 67.215.65.132.
Another problem with the DNS server is its response to a server failure. Instead of properly returning an error when it can't contact the DNS authority, the DNS server returns an address of 67.215.66.132. Since transient failures are quite common this can be significantly disruptive, turning a transient failure into a wrong answer without any notification to the application doing the name lookup.

Host Properties –
System clock accuracy (?): Warning
Your computer's clock is 6 seconds fast.
Browser properties (?): OK
The following parameters are sent by your web browser to all web sites you visit:
User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.3 (KHTML, like Gecko) Chrome/6.0.472.63 Safari/534.3
Accept: application/xml,application/xhtml+xml,text/html; q=0.9,text/plain; q=0.8,image/png,*/*; q=0.5
Accept Language: en-US,en;q=0.8
Accept Encoding: gzip,deflate,sdch
Accept Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Java identifies your operating system as Windows XP.
Uploaded Data (?): OK
The following additional data was uploaded by the applet:
nxpage
raw_http_content
#66111 by lbmofo
Mon Oct 04, 2010 2:26 pm
Your cable modem is probably going bad. Intermittent problems point to that. If you rent, have cable company give you a new/different one.

Who is online

Users browsing this forum: No registered users and 12 guests