dslreports logo
site
spacer

spacer
 
    «« DSL Hurdles Share Tool
spc

spacer




how-to block ads




6.1 Internet Connection and ISP

The following is taken from www.testyourvoip.com/faq.html
(Another explanation here)

Once a call has successfully been setup, latency, jitter, and packet loss effects are important predictors of overall call quality.

Latency
A measure of the delay in a call. We measure both the round-trip delay between when information leaves point A and when a response is returned from point B, and the one-way delay between when something was spoken and when it was heard. The largest contributor to latency is caused by network transmission delay. Round-trip latency affects dynamics of conversation and is used in our MOS calculations. One-way latency is used for diagnosing network problems.

With round trip latencies above 300 msec or so, users may experience annoying talk-over effects.

Jitter
Jitter refers to how variable latency is in a network. High jitter, greater than approximately 50 msec, can result in both increased latency and packet loss. Let's see how.

When talking to someone it's important that they hear what you say in the same order that you say it, otherwise they won't understand what you're telling them. Unfortunately, jitter causes packets to arrive at their destination with different timing and possibly in a different order than they were sent (spoken), with some arriving faster and some slower than they should.

To correct the effects of jitter, VoIP endpoints collect packets in a buffer and put them back together in the proper timing and order before the receiver hears them. This works, but it's a balancing act. Processing that buffer adds delay to the call, so the bigger the buffer, the longer the delay. Remember the effects of latency? Keep in mind, no matter how big the buffer is, it is finite in size. If voice packets arrive when the buffer is full then packets are dropped and the receiver will never hear them. These are called discarded packets.

Packet Loss
Just as it's important to hear what someone says in the order they say it, it's also important to hear all of what they're saying. If you miss one out of every 10 words or 10 words all at once, chances are you're not going to understand much of the conversation. This is packet loss some of the voice packets are dropped by network routers or switches that become congested (lost packets), or discarded by the jitter buffer (discarded packets).

Knowing the average packet loss for a call gives you an overall sense for the quality of the call. A call with less than 1 percent average packet loss will always sound better than a call with 10 percent loss. But average loss doesn't tell the whole story. You need to know what type of packet loss you encountered.

There are two kinds of packet loss: "random" and "bursty". Think about two calls each with average 1 percent packet loss. Call A loses one in every 100 packets over the entire call (random loss) while Call B loses 100 packets in two clumps at the beginning and the end of the call (bursty loss). Which call would you rather have? That's why we report not just the average packet loss but also the type of loss and information on any bursts of packet loss during your call (reported as loss periods). It matters.

When you have choppy voice on your line, you should immediately Determine the JITTER on your ISP connection.


NOTE: Try and isolate the problem even further by testing your ATA on another BroadBand connection.



by Styvas See Profile edited by canoe See Profile
last modified: 2006-04-19 20:02:29

Apart from routers (if you have one) and where they are located, where the DVG ATA plugs in, what ISP you are using, or the QoS test on Primus' website, there is an important point to understand:

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:
voip-info: »www.voip-info.org/wiki-QoS
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.


NOTE: Try and isolate the problem even further by testing your ATA on another BroadBand connection.



by canoe See Profile
last modified: 2006-04-17 19:54:21

When you have choppy voice on your line, you should immediately determine the 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.)

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.

•Select Montreal as the Call Destination and press "Go".

•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:
  • It might help if you arm yourself with some information when you call into your ISP. You can track your Internet jitter, latency, and packet loss with www.voipspear.com. Do this for a while before you call in and then you can give them information that shows the probvlem.

    2009-08-15 12:49:29 (31366302 See Profile)

  • Hi, I just read your comments regarding high jitters and I've been experiencing this exact same problem for a few weeks already on my VOIP. My ISP is DSL (AT&T). What do you suggest that I can do?

    2009-06-23 20:36:57

  • Hello - I have recently been having issues with my (ISP)service as well as my (VOIP)service "two different co" and have spent quite a bit time trying to resolve QoS issue - Through out this communication with both companies I have realized what a dissadvantage the customer is at unless they can complain with real data and thats where your thread comes in "thanks" - I am posting an addition to your tread I hope you approve http://www.vonage-forum.com/ftopic13039.html this link gets right down to doing there job for them and has a really good Howto link on it with some GNU software "Wireshark" for getting hold of the proof.

    2009-02-04 21:19:47 (thomas007 See Profile)



by canoe See Profile edited by Styvas See Profile
last modified: 2008-02-03 20:23:03

Please LIMIT pings as this generates extra traffic in the network and can sometimes affect VoIP traffic; including the 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...
================================================================================

by canoe See Profile
last modified: 2005-07-17 21:30:27

You can sometimes use 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.

by canoe See Profile
last modified: 2005-07-17 21:29:40

Your ATA is configured, by Primus, with the VoIP server IP address that it connects to. This is identified as the Call Agent IP Address -- Notify Entity. For those users with a D-Link DVG-1120M gateway, the Call Agent IP address is displayed near the bottom of the first page that loads after you 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. 216.1.2.3)

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.

by Styvas See Profile
last modified: 2007-02-11 22:40:43

If you are using DSL, and 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 See Profile, assumes the following:
    •you are using the Linksys SPA gateway
    •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:
    •open a browser
    •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"


by devkat See Profile edited by Styvas See Profile
last modified: 2008-03-28 19:12:22