Re: Troubleshooting video chat dropouts

[Noam Birnbaum <noam () maccentricsolutions com>]

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 () 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

Noam Birnbaum
Mac Daddy
http://www.maccentricsolutions.com
877.luv.macs x666
tweet @noamb

Tech support —> 877.luv.macs or support () maccentricsolutions com

___________________________________________________________________________
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