Re: Troubleshooting video chat dropouts

[Murilo Grizi <mbgrizi () gmail com>]

Well, I'm new here and kinda new on this whole networking stuff as well,
but I believe you're going an extra mile before checking locally.

You said  you thought the receiver could be the issue, but well, there are
many places you could check before the receiver. Are you sure that
capturing packets is the correct thing to do now?

It could be QoS drops, for example. You could verify the local routers, how
offsite packets are being marked and how office packets are being marked
(which can be done much more easily just by taking a glance at the source
IP address, for example)

Another thing: setting a high precedence (like 7) could be harmful to your
network, since it will dispute network control traffic. Besides, bandwidth
for CS7 is prioritized, but often small, which could reproduce the issue
because of packet drops. If you can use a secondary WAN line, I'd go that
way first and verify if packets are dropped there, through normal queueing.
Doing the tests outside business hours could also be better (both with
current link and backup link).

Also, you didn't mention, but did you check your traffic drops?

Sorry for not being able to help directly on the video buffering
experiment, I'm also eager to see if one of our colleagues knows something.

Thanks,

2012/9/4 Noam Birnbaum <noam () maccentricsolutions com>

> Hi everybody,
>
> One of our clients has been complaining that video chats can be extremely
> choppy, or drop out entirely and require restarting the chat, on Skype and
> Google Hangouts. It seems to be intermittent, and my first suspicion was
> simply that the problem resides with the remote correspondents' network.
>
> However, there have been a number of instances when the remote
> correspondent was unlikely to be the problem, such as when a chat with a
> remote correspondent works fine offsite, repeatedly, but not at the office,
> repeatedly.  There are other such scenarios, like when the remote
> correspondent has never experienced these problems except when chatting
> with our client.
>
> We've done the following:
>
> - set videoconferencing to IP Precedence 7 on the client router (Meraki
> MX60)
> - bound video to the less-utilized secondary WAN line
>
> However, rather than waiting to see (again) whether this actually fixes
> it, I would love to get to the bottom of the problem at the packet level. I
> am considering running a ring buffer capture for all videoconferencing
> traffic. I would want to compare videochats that don't exhibit dropouts to
> those that do.
>
> Questions:
>
> 1. How would you set up the ring buffer capture to filter Skype and Google
> Hangout chats?
>
> 2. What metrics and methods of comparison would you use to try to isolate
> the problem in the troublesome captures?
>
> Many thanks!
>
> noam
>
> ___________________________________________________________________________
> Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
>              mailto:wireshark-users-request () wireshark org
> ?subject=unsubscribe



-- 
"Deus que me conceda esses últimos desejos – paz e prosperidade para o
Brasil…"
(Dom Pedro II)

___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe