VoIP Voice Quality issues when streaming video over internet

[gr8sho]

ISP = Comcast
VoIP = CallVantage
TA = D-Link DVG-5102S

If I stream video, the VoIP phone connection breaks up. The TA reports both TX and RX packet loss.

At another location with similar equipment, I do not have such problems.

CallVantage claims the problem is due to packet loss from Comcast, but of course Comcast denies this.

Has anyone had similar experience and get this resolved favorably, and perhaps willing to share how this was handled? I have 9 days invested in this and am about to give up.

Thank you in advance.

[YARDofSTUF]

Can you reserve a certain amount of bandwidth for the VOIP?

[gr8sho]

I couldn't figure out how to do that in the D-Link. I'm assuming that's where you would want to apply the reservation. Apparently CallVantage deals with this for upload (speaking part), but the issue is also happening on the download (listening part).

[gr8sho]

Can you reserve a certain amount of bandwidth for the VOIP?

One other point. Even if I could, it doesn't make sense that I should have to. I've seen 10MB down and 2MB up. From a raw speed perspective the thing cooks.

But I am getting too much packet loss... Latency looks bad too. Again, this is happening only when I stream video.

Thanks and Cheers,

[trogers]

Post your TCP Analyzer report to check if your TCP Window is set for 10 mbps.

[gr8sho]

Post your TCP Analyzer report to check if your TCP Window is set for 10 mbps.

TCP options string = 020405b40103030201010402

MTU = 1500
MTU is fully optimized for broadband.

MSS = 1460
Maximum useful data in each packet = 1460, which equals MSS.

Default TCP Receive Window (RWIN) = 256960
RWIN Scaling (RFC1323) = 2 bits (scale factor of 4)
Unscaled TCP Receive Window = 64240

RWIN is a multiple of MSS
Other RWIN values that might work well with your current MTU/MSS:
513920 (MSS x 44 * scale factor of 8)
256960 (MSS x 44 * scale factor of 4) <-- current value
128480 (MSS x 44 * scale factor of 2)
64240 (MSS x 44)

bandwidth * delay product (Note this is not a speed test):

Your TCP Window limits you to: 10278 kbps (1285 KBytes/s) @ 200ms
Your TCP Window limits you to: 4111 kbps (514 KBytes/s) @ 500ms

MTU Discovery (RFC1191) = ON

Time to live left = 52 hops
TTL value is ok.

Timestamps (RFC1323) = OFF
Selective Acknowledgements (RFC2018) = ON

IP type of service field (RFC1349) = 00100000 (32)
Precedence (priority) = 001 (priority)
Delay = 0 (normal delay)
Throughput = 0 (normal throughput)
Reliability = 0 (normal reliability)
Cost = 0 (normal cost)
Check bit = 0 (correct, 8th checking bit must be zero)

DiffServ (RFC 2474) =

[trogers]

Try the following with TCP Optimizer:

General Settings tab:
Custom settings - check
Modify All Network Adapters - check
network adapter selection - your NIC
MTU 1500
TTL - 64
TCP Receive Window - 513920
MTU Discovery - Yes
Black Hole Detect - No
Selective Acks - Yes
Max Duplicate ACKs - 2
TCP 1323 Options:
Windows Scaling - checked
Timestamps - uncheck

Advanced Settings tab:
Max Connections per Server - 10
Max Connections per 1.0 Server - 10
LocalPriority - 1
Host Priority - 1
DNSPriority - 1
NetbtPriority - 1
Lan Browsing speedup - optimized
QoS: NonBestEffortLimit - 0
ToS: DisableUserTOSSetting - 0
ToS: DefaultTOSValue - 0
MaxNegativeCacheTtl - 0
NetFailureCacheTime - 0
NegativeSOACache Time - 0
LAN Request Buffer Size - 32768
Then select "Apply Changes" and reboot to take effect

[gr8sho]

okay. will give it a go next time I'm at that loc. Wierd that I would need to resort to such fine tuning but it's worth a shot.

[YARDofSTUF]

One other point. Even if I could, it doesn't make sense that I should have to. I've seen 10MB down and 2MB up. From a raw speed perspective the thing cooks.

But I am getting too much packet loss... Latency looks bad too. Again, this is happening only when I stream video.

Thanks and Cheers,

Whats ur latency, show us some tracerts if you can, do you only notice packet loss whiel streaming? Are you streaming from your PC or to it?

[gr8sho]

Whats ur latency, show us some tracerts if you can, do you only notice packet loss whiel streaming? Are you streaming from your PC or to it?

Here's a report from a setup that is working for comparison. I have applied the settings recommended earlier.

Pinging dcs.origin.comcast.akadns.net [216.148.227.202] with 64 bytes of data:

Reply from 216.148.227.202: bytes=64 time=112ms TTL=48
Reply from 216.148.227.202: bytes=64 time=134ms TTL=48
Reply from 216.148.227.202: bytes=64 time=79ms TTL=48
Reply from 216.148.227.202: bytes=64 time=83ms TTL=48
Reply from 216.148.227.202: bytes=64 time=202ms TTL=48
Reply from 216.148.227.202: bytes=64 time=123ms TTL=48
Reply from 216.148.227.202: bytes=64 time=85ms TTL=48
Reply from 216.148.227.202: bytes=64 time=270ms TTL=48
Reply from 216.148.227.202: bytes=64 time=190ms TTL=48
Reply from 216.148.227.202: bytes=64 time=110ms TTL=48
Reply from 216.148.227.202: bytes=64 time=92ms TTL=48
Reply from 216.148.227.202: bytes=64 time=320ms TTL=48
Reply from 216.148.227.202: bytes=64 time=240ms TTL=48
Reply from 216.148.227.202: bytes=64 time=160ms TTL=48
Reply from 216.148.227.202: bytes=64 time=387ms TTL=48
Reply from 216.148.227.202: bytes=64 time=205ms TTL=48
Reply from 216.148.227.202: bytes=64 time=126ms TTL=48
Reply from 216.148.227.202: bytes=64 time=149ms TTL=48
Reply from 216.148.227.202: bytes=64 time=101ms TTL=48
Reply from 216.148.227.202: bytes=64 time=194ms TTL=48
Reply from 216.148.227.202: bytes=64 time=94ms TTL=48
Reply from 216.148.227.202: bytes=64 time=137ms TTL=48
Reply from 216.148.227.202: bytes=64 time=205ms TTL=48
Reply from 216.148.227.202: bytes=64 time=190ms TTL=48
Reply from 216.148.227.202: bytes=64 time=205ms TTL=48
Reply from 216.148.227.202: bytes=64 time=125ms TTL=48
Reply from 216.148.227.202: bytes=64 time=356ms TTL=48
Reply from 216.148.227.202: bytes=64 time=275ms TTL=48
Reply from 216.148.227.202: bytes=64 time=194ms TTL=48
Reply from 216.148.227.202: bytes=64 time=114ms TTL=48

[gr8sho]

WAN Statistics

Sent : 659790 Received : 1623502
TX Packets Dropped : 2 RX Packets Dropped : 131
Collisions : 0 Errors : 0

If I try to use the phone while video is streaming, these numbers go up.

Here is ping trace during the event.

Reply from 63.240.76.72: bytes=64 time=49ms TTL=46
Reply from 63.240.76.72: bytes=64 time=457ms TTL=46
Reply from 63.240.76.72: bytes=64 time=153ms TTL=46
Reply from 63.240.76.72: bytes=64 time=304ms TTL=46
Reply from 63.240.76.72: bytes=64 time=184ms TTL=46
Reply from 63.240.76.72: bytes=64 time=414ms TTL=46
Reply from 63.240.76.72: bytes=64 time=769ms TTL=46
Reply from 63.240.76.72: bytes=64 time=670ms TTL=46
Request timed out.
Reply from 63.240.76.72: bytes=64 time=588ms TTL=46
Reply from 63.240.76.72: bytes=64 time=1041ms TTL=46
Reply from 63.240.76.72: bytes=64 time=50ms TTL=46
Reply from 63.240.76.72: bytes=64 time=187ms TTL=46
Reply from 63.240.76.72: bytes=64 time=50ms TTL=46
Reply from 63.240.76.72: bytes=64 time=49ms TTL=46
Reply from 63.240.76.72: bytes=64 time=98ms TTL=46
Reply from 63.240.76.72: bytes=64 time=409ms TTL=46
Reply from 63.240.76.72: bytes=64 time=279ms TTL=46
Reply from 63.240.76.72: bytes=64 time=442ms TTL=46
Reply from 63.240.76.72: bytes=64 time=282ms TTL=46
Reply from 63.240.76.72: bytes=64 time=110ms TTL=46
Reply from 63.240.76.72: bytes=64 time=122ms TTL=46
Reply from 63.240.76.72: bytes=64 time=51ms TTL=46
Reply from 63.240.76.72: bytes=64 time=55ms TTL=46
Reply from 63.240.76.72: bytes=64 time=49ms TTL=46
Reply from 63.240.76.72: bytes=64 time=49ms TTL=46
Reply from 63.240.76.72: bytes=64 time=386ms TTL=46
Reply from 63.240.76.72: bytes=64 time=208ms TTL=46
Reply from 63.240.76.72: bytes=64 time=210ms TTL=46
Reply from 63.240.76.72: bytes=64 time=474ms TTL=46
Reply from 63.240.76.72: bytes=64 time=485ms TTL=46
Reply from 63.240.76.72: bytes=64 time=208ms TTL=46
Reply from 63.240.76.72: bytes=64 time=193ms TTL=46
Reply from 63.240.76.72: bytes=64 time=68ms TTL=46
Reply from 63.240.76.72: bytes=64 time=652ms TTL=46
Reply from 63.240.76.72: bytes=64 time=289ms TTL=46
Reply from 63.240.76.72: bytes=64 time=50ms TTL=46
Reply from 63.240.76.72: bytes=64 time=71ms TTL=46
Reply from 63.240.76.72: bytes=64 time=328ms TTL=46
Reply from 63.240.76.72: bytes=64 time=501ms TTL=46

[YeOldeStonecat]

Is the DLink plugged in behind another router? Or directly into your cable modem?

[gr8sho]

Is the DLink plugged in behind another router? Or directly into your cable modem?

Direct to cable modem. I can direct connect to the D-link with cat5 and see the problem readily.

I'm really thinking there must some problem upstream with Comcast but they won't fess up. I have a 3rd visit from them tomorrow.

[YARDofSTUF]

Again, do you only notice packet loss while streaming and are you streaming from your PC or to it?

The 2 mbps upload you are seeing is powerboost, after a little while it most likely drops down to 300ish kbps.

[gr8sho]

pulling to PC. you know, I wonder if powerboost is confusing callvantage. But I have powerboost here in this other location with no troubles whatsoever.

Nevertheless, the voice quality issue is not on the talking part but rather on the listening part, and there is more than enough bandwidth there.

[gr8sho]

A quick update on this issue. Comcast has finally admitted that there is a signal issue at the one of the distribution boxes in the building and they confirm packet loss. I'm waiting for their maintenance team to show up today...

[Far-N-Wide]

Tweaking the pipe per the above is very helpfull. Also having Comcast attend the issue you mentioned is also helpful. However, another possibility is your end application.

This is going to be long but sells a point. Keep reading...

I have done testing of VOIP using CISCO 2600 and 3800 series Routers over Wans. Also over extened networks Via Satcom data paths.

The audio tests were done with standard telephone handsets. The badwith for the handsets were set within the router to 2.4k, 4.8k, 9.6k, 19.2k, 38.4k and 64K.

An older video camera was connected to the Router's RS-530 data connection Via a home build cable that we came up with. The data rates for that went from 128k, 256k, 384k, 512k, 1.5M and 2048. No higher testing could be done over the Satcom pipe as we had a limit on bandwidth.

What we learned was by sight and sound. We measured packet loss with a FIREBERD 6000 and used the routers ability to report packets we send / recieved. We setteled on what we liked. This being 9.6k Audio and 384k Video.

Since we also had a PictureTel Video conferencing suite that supported voice and video services at 384k. Higher then this we saw that data compression became an issue, so we went with 384K bandwidth for our customer.

In addition we could control the Optimum path of the data path by setting the router tables to lock down all packets to a single path. As you know the Internet will jam packets down any path open to it. Some packets will arrive later then others due to taking less optimum paths open to the router. This is a big problem you can not control on the internet.

So If you can try limit application to 384K bandwith. Even if you have a 10 Meg pipe, your going to notice more packet loss on the stream as more folks jump in on that broadcast.

My humble 2 coppers....
Good luck.

[allanwalker]

Its mostly the issue with freewares....I don't blame the voip providers. See I am using http://www.gomeetnow.com services . See its universal attendance technology ensures that everyone can join the meeting with no download whatsoever and it provides support for attendees on windows, mac, linux, unix, iPhone etc..

[helter]

ISP = Comcast
VoIP = CallVantage
TA = D-Link DVG-5102S

If I stream video, the VoIP phone connection breaks up. The TA reports both TX and RX packet loss.

At another location with similar equipment, I do not have such problems.

CallVantage claims the problem is due to packet loss from Comcast, but of course Comcast denies this.

Has anyone had similar experience and get this resolved favorably, and perhaps willing to share how this was handled? I have 9 days invested in this and am about to give up.

Thank you in advance.



Hi I work for comcast in the state of Washington. I have had some experience with this and the solution is varying. Ranging form bad ethernet ports, modem swaps, to drop replacements and even plant problems.

I have a guild below I will post, but I want to make this clear, it can be a LONG process to pin the cause of this down. there is also no guarantee the first tech that comes out will understand what you explain, no fix it. Comcast does not train you for this sort of diagnostic, I happen to be a network geek for some 15 years now as a personal hobby.



========================================================

Notes: I will mention DSLR, its not by choice, its just they have the test I want yo to use and I do not see an equivalent test here.

Intermittent packet loss.

This text is designed to help comcast cable customers with intermittent packet loss. Note it will work for any ISP, not just comcast or cable for that matter. However other forms of ISP may have more than I cover that needs to be looked at and you may have to look up your own local IP addresses differently.

First thing first I want you to simplify your connections. This means if you have a router/hub/switch/internet sharing set up, DITCH IT for this diagnostic phase and hook straight to your cable modem from one computer. If you have a 2 way splitter at the wall plate to feed your modem and TV ditch it and hook straight to the modem.

The next thing I want you to do is grab a free visual utility called ping plotter.
http://www.pingplotter.com/download.html

Also, familiarize yourself with DSLReports test tools, particularly the line quality test.
http://www.dslreports.com/tools

Step one, if you are playing games and getting kicked off/latency spikes, we need to first verify the packet loss is the cause. Please note just because you get packets lost reported does not mean they are lost, routers, servers, and whatever else have
more important jobs to do than respond to your ping requests and in the 90's mal-formed ping packets would bring a hop to it's knees and was the favorite pass time of script kiddies, so most network admins these days put ping response priority very low which means that lost packet may have just meant the hop was too busy to bother with you. So if the main feed in NY gives you packet loss, trust me, they'd already know about it if the whole state is losing packets. We really don't need to look past the first few hops with comcast's name in them when we are looking at the results of the tests below.

While playing a game, browsing the web, or whatever, run the command line and then type:
ping www.comcast.net -t

Now, leave it running in the background while you do whatever it is you do. When the problem occurs, check the command line window and try to see if you find a "Request timed out" near the bottom to indicate the packet loss is the problem with your service.

If you find "request timed out" matching your service disruption, it is a good bet that the two are linked. Now the question becomes what is causing them.


Phase two: Supporting the newly formed theory.

Ping plotter is a visual network admin tool that is a combination of ping and tracert or traceroute. The free version is fine for what we need.

Once it is installed we need to set it up to run like this
100 traces, 2.5 second interval, Include all samples

Then places I want you to ping are first
192.168.100.1
Take screen shot and then repeat the pinging to www.comcast.net, and take a screen shot there.

192.168.100.1 is your modem. If you have packet loss consistently here you have a problem between your computer and the modem. Could be an Ethernet cable could be the Network adapter on your computer, the modem, etc.

If you pass this then the problem might still be the modem, but it is past the Ethernet port the RF port though, or possible further up the path is where the problem lies.


The next run is an internet site away from you [comcast.net], each hop has a chance to start causing packet loss, and remember it is intermittent so it will not show immediately, hence the 100 packets. It should take about 4.5 minutes to obtain 100 packet worth of results, by the way.

Note: Comcast.net is not needed, you can target goggle.com or any other internet page. Back in the dial up days, ISP’s were smaller and the home page was likely hosted locally, giving you a test of just their network but Comcast and most ISP’s today are much larger. ISP means Internet Service Provider.

Now run the DSL reports line quality test. See if the matching hops are loosing packets this way as well.

Now my recommendation would be to post a new thread , with the results of these tests, preferably screen shots of the ping plotter test and a link to your line quality test results.