| Hi Murilo,
Thanks for your reply. Those are all good suggestions, and I'll try them. Meraki routers, unfortunately, hide a lot of this information from the administrator (for "ease of use") so I will have to go digging with their tech support. One reason we will be moving away from Meraki.
I would still love to hear others' thoughts on the situation, since there are certainly many ways to approach the problem!
Thanks, noam
On Sep 5, 2012, at 5:02 AM, Murilo Grizi wrote: 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@xxxxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?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@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
Noam Birnbaum Mac Daddy 877.luv.macs x666 tweet @noamb
|
