how-to block ads
6.1 Internet Connection and ISP
(Another explanation here)
Once a call has successfully been setup, latency, jitter, and packet loss effects are important predictors of overall call quality.
When you have choppy voice on your line, you should immediately Determine the JITTER on your ISP connection.
What is the Latency, Jitter, & Packet Loss between your DVG ATA and Primus' TBB servers ? And for a VOIP call, to the last network hop?
1) If Latency is large, it may not affect your file downloads; but it will very likely affect VOIP in terms of a perceived "delay" or LAG.
You need to consider the Latency not just from the DVG ATA to the TBB Server, but also through the network to the last hop before connecting to a VOIP or PSTN phone. So a High Latency in a TBB server ping may provide some clues to such a LAG problem, but not always.
The max acceptable round trip delay for conversations is about 350ms... beyond which we humans become irritated with the LAG and interruptions.....
2) Network Latency is variable depending on the time of day; ie the ISP network and Primus' network (the Internet for that matter) are not static; things are always happenning. This can be more prevalent on cablemodem due to shared lines/network, but this can also occur on DSL because "the network" is always shared at some point.
Furthermore, at a given time, the Latency should be fairly consistent, with a slight variance (JITTER) around the average. This means packets including VOIP packets are being routed somewhat the same through the network.. you are probably getting good QOS.
However if the Latency varies considerably (Large JITTER) at a given time (within a few minutes..), then this can mean that packets are being held up somewhere in the network due to congestion or network topology (load-balancing, packets take different routes, etc). These will most certainly cause VOIP choppiness.
See these and other links for more info:
quality issues: »www.freeway.com/voipqualityissues.htm
The results of "ping" and "traceroute" MAY help to determine where a problem may lie. However, CAUTION, other factors need to be taken into account before pointing a finger at any particular node (server, router).
When you have choppy voice on your line, you should immediately Determine the JITTER on your ISP connection.
JITTER of your ISP connection to help you in understanding whether it is your LAN or modem that is the problem, your ISP connection, the ISP Network/Backbone, the Primus Network/Backbone, or a general TBB issue. No Jitter may imply that you have a bad phone, bad house wiring (loose cable), or faulty ATA or modem.
The test below will provide your JITTER between your computer and the testyourvoip.com servers - at the particular instance you run the test.
•Bad results mean that there is definitely a problem with your ISP connection, and NOT with TBB. This is because this particular test does not interact with the Primus Network or TBB Gateways at all!
•Good results imply good quality TBB calls; and should reflect the typical JITTER you will encounter on an actual VoIP call through the ATA to the TBB servers.
•In some cases, you may have great results from this test, but you still have terrible TBB Call Quality. This implies that there may be an interconnection problem between your ISP and Primus TBB Gateways, which this test cannot show. You can try and run another test directly to Primus servers as described in Testing your BroadBand connection for TBB. The TBB test does not provide JITTER results, but may help you (and Tech Support) narrow down the issues with your connection.
Simple Steps using your favorite browser to determine the JITTER on your ISP connection:Note that you should repeat this test a few times when you have problems, and also when you do not. The average of each of the results is a better indicator of your connection JITTER as these values fluctuate every second depending on the traffic on your ISP connection, the Internet in general, and the testyourvoip.com servers! For a comparison over time you can register for free with the testyourvoip.com website and keep ongoing records of your VoIP tests. Registration also allows you to compare your results to those of other users in your area or those using the same ISP (or others). The site caters to American customers and is missing some of the Canadian ISPs.
•Go to URL http://www.testyourvoip.com (Please note that this site appears to currently be offline with no indication if and when there will be a resumption of service.)
•Select Montreal as the Call Destination and press "Go".
Macintosh users should note that the Java compatibility with this site is spotty depending upon which browser you are using to access the website. The Java Embedding Plugin (available through Version Tracker) may solve this problem, but it's a bit complicated to install. It may also introduce minor browser bugs after each use (in my case it messed up typing until I switched to another application and typed something and switched back). Hopefully Apple will update the OS soon to allow the latest versions of Java to be used with browsers other than Safari.
•You can run the test with "Preserve Speech Quality" or "Conserve Bandwidth" or both.
NOTE: Your MOS score cannot be greater than 4.4. See the TestYourVoip FAQ for further info on MOS and other aspects of this test.
•Once the test has completed, select "See Detailed Results" to display the JITTER on your ISP connection. JITTER is listed for each of the Incoming and Outgoing signals with the min, avg, and max millisecond (ms) values.
In general, the max JITTER should be under 50ms. JITTER beyond this will provide progressively worse degradation - choppy VoIP. HIGH JITTER approaching 100ms may make the VoIP service unusable.
There are too many possible variations in results to discuss the issues here, so please post your JITTER results in the MyTBB Forums where someone can help you further.
See Troubleshooting your Internet Connection and ISP on how to sometimes resolve this. Ping and traceroute as described there **may** help show where the problem lies.
If and when you report a JITTER problem to your ISP, they will usually insist that you have a great connection, good signal, and great bandwidth. However, the real issue is congestion which creates high JITTER - the first level rep (CSR) usually does not understand what JITTER is. You may have to call a few times before your link/segment can be upgraded.
In other words, in the case of Cable, they will have to upgrade your neighbourhood network by moving customers to different (new?) cables to spread out the usage. This can take a few months (3-6), and may also depend on how many other customers report the problem!
Similarly, with DSL, they need to add more DSLAM equipment to handle the bottleneck at that point (although this rarely occurs).
Feedback received on this FAQ entry:
Primus TBB servers.
Ping the Primus TBB server to determine the (roundtrip) latency from your DVG ATA to it - you can get the IP address from the "Notify Entity" line when you login to the DLINK DVG ATA.
(For Windows users: from a "Command Prompt" in Start->Accesories)
ping -n 10 [fill in your DVG`s "Notify Entity" IP address here]
(For Macintosh OS X users: from a Terminal prompt in Applications/Utilities)
ping -c 10 [fill in your DVG`s "Notify Entity" IP address here] You may also yuse the Network Utility instead of the Terminal application.
You will get 10 lines of response with ..32 bytes (64 for Macintosh), a time and TTL. The avg, min, max times are displayed on the last line.
The round trip latency to the TBB server should be 50-60ms for a decent connection. This is not an *absolute* figure, since it also depends on the rest of the "path"... including where the call is terminating, amongst other factors.
You should use a wired connection when using ping, to minimize any artificial LAN delays in the results. Using a WiFi connection will introduce variable delays which may be erroneously interpreted as jitter.
If you are having periodic short "half-second" problems (chops voice for a split second) every now and then, then using ping is difficult as standard pings run every 1 sec. The ping would have to run almost in sync with the other packets generating the congestion within that half second.. to show a latency/jitter problem. In other words, the ping packets may come just before or after the half second congestion, and so they do not have/show any delay.
If you have continuous VoIP problems (ex choppy for 5 seconds straight) then the pings will most likely show the latency/jitter; since the traffic causing the congestion is there during four pings in this example; the ping packets are going to get held up and this will be reflected in the results output...
traceroute to HELP resolve a problem.
Traceroute shows the "path" (via hops & nodes) taken to the destination. It also shows individual "latency" to each node. This MAY help to determine where the problem may lie: need to consider many factors first.
The route to the Primus TBB server consists of the part within your LAN (the DVG ATA to the MODEM in the simplest case), the ISP's network, the interconnection to Primus' network, and Primus' network itself including the path to the TBB server(s).
The VOIP call itself does not include the TBB server, but includes hops through Primus' network and then the nodes to connect either to a phone on TBB, the PSTN, or another VOIP provider. For VoIP to VoIP calls, the voice packets may never travel on Primus' network.
Run traceroute to the Primus TBB server until it times out. The default is to try for 24-30 hops before quitting, so if you let it continue, it should show all nodes in the path. However, if traceroute is throttled, the results may be misleading. If traceroute is blocked, it simply shows nodes with * * * .
You should use a wired connection when using traceroute, to minimize any artificial LAN delays in the results. Using a WiFi connection will introduce variable delays which may be erroneously interpreted as jitter.
Mac and Unix users may have difficulty doing a traceroute. Unlike Windows, which uses ICMP to perform a traceroute, UNIX systems use UDP (although that's a really simplified explanation). On Linux you can add the -i option to the command to force it to use ICMP instead of UDP, but Panther unfortunately doesn't support that switch. There is a freeware application for the Mac platform called WhatRoute that will perform an ICMP traceroute. It also defaults to UDP, but this can be turned off under Preferences or Traceroute Options. I am not aware of a similar Unix application.
There is an extensive traceroute primer available here.
login to the DVG ATA.
NOTE: The IP address is the 4 numbers separated by periods. The colon and the number after the colon refers to the port number and should not be used when pinging (i.e. 184.108.40.206)
Default INVALID addresses start with 10 or 192 and should be modified to a VALID IP address or the ATA will not provide any VoIP or Internet service.
A VALID IP address starts with 216, but for security reasons, because this is a public FAQ, the full IP addresses are not listed here. You can obtain a VALID IP address from the MyTBB Forums or Primus TBB Technical Support.
By inserting a VALID IP address and save/restarting the DVG, it will automatically update with the correct Call Agent IP Address assigned to your account.
your ATA is using PPPoE, then you need to ensure that your ATA's WAN Settings are configured to use your ISP username and password and not the default TBB values.
If your broadband connection is DSL and your ATA is setup with DHCP behind a router, you may still have disconnection issues and call drops. See here as to why you must use PPPoE on your ATA's WAN settings to usually resolve this.
The description below, contributed by devkat , assumes the following:
•the connection drops every 2 minutes to every 2 hours
•your internet connection is working fine (by testing it for a sufficient length of time with your computer connected directly to the modem)
•that you are using the Basic High Speed service of Bell Sympatico (no fixed IP, no bells and whistles)
•your Primus TBB service is active and working fine
•you are connected this way: wall phone jack -> Sympatico Modem -> Linksys SPA 2100 -> Computer
A. Simple Solution: make sure your Bell Sympatico username and password are setup in the SPA device.
B. Technical Solution:
•enter the IP address of your SPA device and browse to it
•at the login screen, enter your SPA device basic username and password (provided to you in your Primus TBB package or obtainable from Primus TBB technical support)
•under the "Router" tab, click on "WAN Setup"
•under "Internet Connection Settings", under "Connection Type:", select "PPPoE,DHCP"
•under "PPPoE Settings", under "PPPoE Login Name:", enter your Bell Sympatico username
•under "PPPoE Settings", under "PPPoE Login Password:", enter your Bell Sympatico password
•click on "Submit All Changes"