I am using a VOIP softphone. When at my office this works fine, but when I am working from home I get massive jitter and delay in response.
I am wondering if my home wireless network 802.11G could be the cause. When I connect to my router directly with an ethernet cable, the IP Softphone seems to work much better with less jitter.
I don't really understand that as my laptop is only a couple of metres from the router in clear line of site and I have a solid 54MBPS connection on wireless.
I am not sure if I could also have a latency issue - I seem to have ping times of 120ms to the my companies' servers in the US which is where the IP phone exchange is located.
Is it normal to expect much worse performance on an IP softphone when going over a local wireless network?
I would say that it's normal to expect worse performance on wireless altogether. You have to remember, radio waves are susceptible to many things that wires arent. Honestly, 120ms on VoIP is a lot, and I'm surprised you're making calls that are decent at all.
warner snipped-for-privacy@hotmail.com hath wroth:
Maker and model number of softphone? Maker and model number of the wireless router you're using?
Assuming nothing is defective, your home system probably has either a weak signal, reflection problems, or interference. All of these result in packet loss (at the MAC layer) which shows up as latency variations. The few softphones I've tinkered with all have a built in ping utility. Fire up the utility, and ping your unspecified model wireless router utility. If your unspecified model (are you getting the hint?) softphone does not have a ping utility, ping the phones IP address from another PC on your network that is plugged directly into your unspecified model wireless router.
You should see *CONSISTENT* ping times with 1 or perhaps 2 msec latency. However, if you see something like this:
Reply from 192.168.1.50: bytes=32 time=6ms TTL=127 Reply from 192.168.1.50: bytes=32 time=12ms TTL=127 Request timed out. Reply from 192.168.1.50: bytes=32 time=66ms TTL=127 Reply from 192.168.1.50: bytes=32 time=1ms TTL=127 Reply from 192.168.1.50: bytes=32 time=1ms TTL=127 Reply from 192.168.1.50: bytes=32 time=5ms TTL=127
you have a problem. The normal latency on this wireless link is 1 msec. The other values are packet loss and retransmissions cause in this case by interference from another nearby network. I can usually guess the cause by watching the numbers. Do whatever is necessary to get it to always be 1msec (or less).
If you get fairly consistent ping times, then something else is the problem. Usually its someone else using your broadband network and hogging all the outgoing bandwidth. This is why most current routers have a QoS feature, that will allow prioritization of packets. VoIP packets come first. File sharing and Peer to Peer networking comes last. You may also have a worm or trojan horse running on a local PC that's hogging all the outgoing bandwidth. Try the softphone with all the other computers in the house turned off and see if that helps.
Sorta kinda maybe. 120msec latency is no problem as long as it's a consistent 120msec latency. For example, I have a customer that uses Skype and other VoIP phone systems over a DirecWay satellite link. Latency is typically 800msec. When traffic is minimal and the latency is consistently 800msec, there's no problem using the satellite link (except for having to say "over" at the end of each phrase). Admittedly, that's not very often, but it does work. Similarly, Skype VoIP works just fine over a dialup connection, which usually has 120 to 200msec latency. The point is that if the latency does not vary, VoIP will work fine.
In the case of wireless, the minimal latency is basically the processing time of the devices at each end. Flight time is at the speed-o-light which is negligible unless you try for long distance (over 5 mile) links. The effect is the same. Consistent latency will cause a delay or echo, but not garble the voice. Varying latency will sound like gargling ball bearing.
802.11 uses a CSMA/CA MAC protocol with a exponential backoff contention window. So, in case of your wireless channel is shared with other devices (802.11, bluetooth, home devices like microwave ovens, TV transmiters, etc.) at the same band, then you are making use of the backoff contention window and then you are using a random time to access channel. So your jitter can be cancelled by means of buffers. The greater the buffer the greater delay. But if the buffer is too short you con run out of it.
Also if you generate packets at a high rate, you can force yourself to make use of contention window although your wireless networks is made of one wireless station.
Maybe a first simple solution be a change in transmission channel.
On Tue, 07 Nov 2006 09:52:55 -0800, Jeff Liebermann wrote in :
Dialup with a good modem should add less than 120 ms latency. If it adds more than that, either the modem is crappy, or something else is wrong (e.g., crappy ISP).
On Tue, 07 Nov 2006 09:39:52 -0800, Jeff Liebermann wrote in :
Another likely cause of high/inconsistent latency is saturation of broadband uplink, which isn't addressed by the QoS in most low-end routers. No matter what the packet priority, saturation of the uplink on typical consumer (asymmetric) broadband results in severe downlink speed degradation and big latency spikes. The only way to resolve that is with uplink throttling, either in the client computer or in the router.
BT Homehub (I am in the UK and this is the router supplied by BT who are my ISP).
When you say ping the phone's IP address, you mean ping the computer that the phone is running on?
First, I pinged my router from the computer where the softphone is running 72 times and got 2 long response times out of 72 - the rest were 1ms.
However a few minutes later I tried again and got the following:
Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=150ms TTL=64 Reply from 192.168.1.254: bytes=32 time=38ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=2ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=150ms TTL=64 Reply from 192.168.1.254: bytes=32 time=140ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=150ms TTL=64 Reply from 192.168.1.254: bytes=32 time=140ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=150ms TTL=64 Reply from 192.168.1.254: bytes=32 time=33ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64 Reply from 192.168.1.254: bytes=32 time=1ms TTL=64
So it looks like I have an issue but it's intermittent?
When you say you can guess the cause by watching the numbers, do you mean that there is some pattern in the dropouts that is consistent with some other device in the area or what?
Thanks for you input on that. This QoS feature - if I have it will it work automatically or do I need to configure it?
I stand corrected. I couldn't remember the latency I was getting for a dialup modem. Worse, I couldn't find a dilaup modem to even try it. None of my desktops or laptops have an internal modem. So, I did the Google thing, found someone expounding on dialup latency, and used their numbers. Try a Google search for "dialup latency msec" and notice the rather large numbers it returns.
Looking on the shelf, I see several large boxes full of assorted ISA and PCI modems. Maybe this is a clue about dialup.
Wow. I also just found a box of Microchannel boards. I wonder what else is buried behind all the modem boards.
Yep. That what I said in my previous rant. "You may also have a worm or trojan horse running on a local PC that's hogging all the outgoing bandwidth. Try the softphone with all the other computers in the house turned off and see if that helps."
Incidentally, I did some testing with various VoIP products using DummyNet to simulate a line imparement problem.
formatting link
have it loaded on an old desktop using a CF card for boot. Makes a nice piece of test equipment. As I recall, a consipated uplink had a horrible effect on downlink latency and thus VoIP quality.
Ok, I goofed. I assumed that you mean't a real 802.11 phone, where the wireless link is built into the phone. That's just VoIP software running on a PC. Most of what I mumbled still applies, except the references should be to the wireless connected computer, not to a Wi-Fi VoIP handset.
I couldn't find much on this device on the the internet. Duz it have QoS features in the firmware?
Correct. However, since you have a PC, it's easy enough to just ping the wireless router from the PC running the Cisco VoIP software.
Yep. There's your problem. One hit every 10 seconds.
It's difficult to guess what it might be. Something that periodic and regular could easily be an application running on the PC that's hogging enough CPU cycles to slow down the networking. Something like an early version of Symantec Live Update that checks to see if it's connected to the internet every few seconds. Programs that poll for activity and connectivity can also do the same thing. Try disabling any network applications that you have running in the background.
Another possibility is a local source of RF interference. Anything that regular is probably an appliance or power supply with a thermostat or regulator of some sorts that samples exactly 10 seconds. I don't have a clue what it might be but my guess is that you can also hear it with an AM or FM portable radio. Try sniffing around the area and see if you hear anything.
Duh.... some 2.4GHz phones have a system where they check to see if there are handsets within range. Siemens 2.4GHz phones do this. The base "probes" for handsets every 10 seconds. If you have a cordless phone, I would unplug it and see if the problem goes away.
Exactly. For example, microwave ovens tend to operate only during typical eating times. Cordless phones tend to interfere for a few minutes, followed by hours of few problems (unless owned by a teenager). Muncipal networks tend to be on all the time but decrease late at night. Each source has a pattern.
You need to configure it. I'm not sure if your BT box has it. However, it won't help this problem. Find the source of the glitches and your problem will go away. Good luck.
On Tue, 07 Nov 2006 21:40:47 GMT, Jeff Liebermann wrote in :
What I Guess(sm):
Many of these folks are looking at end-to-end latency, rather than just the dialup portion.
Folks are much more likely to post when they are having problems, rather than when things are working properly.
Many (most?) computers aren't configured properly (e.g., too low port speed, which increases latency).
There's a lot of crap hardware out there.
There's a lot of just plain crap info on the Internet.
Data I Know To Be Good(sm):
Maybe. I've personally migrated to wireless cellular, which is much faster, cheaper (on my data package at least), and far more ubiquitous than dialup.
OK I have been investigating this further and the mystery deepens.....
The interference I was getting every 10 seconds has gone now - I was getting it earlier this week in the evening like clockwork. Since then I have tried switching off a lot of appliances, and I have also changed the channel on the router to channel 11. I have not seen any interference cycling at 10 second intervals since Tuesday evening, even though I have switched pretty much everything back on, so I'm baffled at that one.
However, I do now see long ping times or time outs on wireless approximately every 65 to 70 secs, and I have been able to sync these exactly with periods of poor reception on my softphone, so I have isolated these as the cause as you suspected.
But I have not been able to find the cause of these dropouts every 65 to 70 seconds so far. I have yet to try disabling services and programs on my computer so I will try that, but since I am seeing a similar issue on another computer in the house that has a totally different configuration I'm not convinced that it's a local PC issue yet.
One other theory I had - I am using WPA-PSK encryption. Could it be the recylcing of the encryption key that's causing this? I may try reverting temporarily to WEP in order to check that. In think that in some routers you can change the time between recycling of the key, but in this BT Homehub I can't find an option to do that.
warner snipped-for-privacy@hotmail.com hath wroth:
I just hate it when that happens.
The problem with intermittants is that they tend to return.
For how long do these last? Try pinging at a faster rate to get a clue as to the length of time between noise hits. Windoze ping will not allow this, so I suggest you download fping 2.16 from:
formatting link
it at about 4 pings per second and try to estimate the length of the outage. For example on my link:
fping 192.168.1.50 -t 250 -c
Fast pinger version 2.16 (c) Wouter Dhondt
formatting link
Pinging 192.168.1.50 with 32 bytes of data every 250 ms:
Reply[1] from 192.168.1.50: bytes=32 time=2.8 ms TTL=127 Reply[2] from 192.168.1.50: bytes=32 time=2.4 ms TTL=127 Reply[3] from 192.168.1.50: bytes=32 time=2.5 ms TTL=127 Reply[4] from 192.168.1.50: bytes=32 time=2.3 ms TTL=127 Reply[5] from 192.168.1.50: bytes=32 time=2.3 ms TTL=127 Reply[6] from 192.168.1.50: bytes=32 time=2.4 ms TTL=127 (...etc...)
I have some guesses as to the culprit, but wanna know the length of time to cut down on the possibilities. There are a huge number of "once per minute" devices possible, such as anything with a digital clock inside, remote weather sensors, RF intrusion detectors, printers with power save options, etc.
Good plan. If it happens on any computer, then it's probably not anything running on the PC unless they're running the same software. I once had a similar problem with periodic glitches and traced it down to the FreePing program I was using to check if my clients servers were up or down.
formatting link
time it would check, the whole computah would almost stop dead. I recently repeated the effect by installing the Accuweather watch plug-in for the Firefox browser. Every time it would check Accuweather for updates, it would freeze the browser and slow down the computah. Anyway, look for such programs that periodicially check for updates.
Yes, it could. The usual default re-key interval is 3600 seconds or 6 minutes. If it had been lowered to 60 seconds, this might be the problem. Check the BT HomeHub WPA-PSK settings.
No, I haven't and previously noted that it was improbable. However, I'm open to new and wonderful bugs. Testing is easy enough and more interesting than the usual broken Windoze problems. I like to test my assumptions first, to be sure I'm not missing something obvious, especially if they're easily checked.
I'm betting on a nearby device with a power save feature that's spewing RFI. I once spent a miserable afternoon in a lab trying to find the source of periodic 1 second RF bursts. Eventually someone noticed that it only happened when I was in the room. After the requisite sick humor, I turned off my pager and the problem went away. (The pager has a battery saver circuit and we were hearing the local oscillator going on and off). I have some guesses as to the 1 minute interval source, but I wanna know the approximate duration first.
When you have eliminated the impossible, whatever remains, however improbable, is the culprit. When that's been eliminated, we're left with the ridiculous. (Apologies to Arthur K. Doyle).
Hereby follows 3 sections of output showing the time profile of the dropouts - each section occurs 60 to 70 seconds apart using the same parameters you used above:
Reply[326] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[327] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[328] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[329] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[330] from 192.168.1.254: bytes=32 time=2.1 ms TTL=64 Reply[331] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[332] from 192.168.1.254: bytes=32 time=13.2 ms TTL=64 Reply[333] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[334] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[335] from 192.168.1.254: bytes=32 time=180.8 ms TTL=64 Reply[336] from 192.168.1.254: bytes=32 time=88.8 ms TTL=64 Reply[337] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64 Reply[338] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64 Reply[339] from 192.168.1.254: bytes=32 time=2.2 ms TTL=64 Reply[340] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[341] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[342] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[343] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[344] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[345] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[346] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[326] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[327] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[328] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[329] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[330] from 192.168.1.254: bytes=32 time=2.1 ms TTL=64 Reply[331] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[332] from 192.168.1.254: bytes=32 time=13.2 ms TTL=64 Reply[333] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[334] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[335] from 192.168.1.254: bytes=32 time=180.8 ms TTL=64 Reply[336] from 192.168.1.254: bytes=32 time=88.8 ms TTL=64 Reply[337] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64 Reply[338] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64 Reply[339] from 192.168.1.254: bytes=32 time=2.2 ms TTL=64 Reply[340] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[341] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[342] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[343] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[344] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[345] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[346] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
Reply[326] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[327] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[328] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[329] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[330] from 192.168.1.254: bytes=32 time=2.1 ms TTL=64 Reply[331] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[332] from 192.168.1.254: bytes=32 time=13.2 ms TTL=64 Reply[333] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[334] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[335] from 192.168.1.254: bytes=32 time=180.8 ms TTL=64 Reply[336] from 192.168.1.254: bytes=32 time=88.8 ms TTL=64 Reply[337] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64 Reply[338] from 192.168.1.254: bytes=32 time=191.0 ms TTL=64 Reply[339] from 192.168.1.254: bytes=32 time=2.2 ms TTL=64 Reply[340] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[341] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[342] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[343] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[344] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[345] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64 Reply[346] from 192.168.1.254: bytes=32 time=1.8 ms TTL=64
I also noticed that using this fping program my ping times are always at least 1.9 ms and there is more variance - using normal windows ping it was almost always just 1ms except during the outages - maybe windoes ping always rounds down?
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.