This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Examples of Google Hangouts traffic analysis?

1

Hi,

Has anyone got a sequence of events with example network capture for a Google Hangouts session?

My client has just started using Google Hangouts. We have it working end to end through various Firewalls and Proxy servers but it's only working over TCP which we believe is causing latency issues. We're about to do some analysis to see where in our environment we're blocking UDP (we'd thought all our Corporate Firewalls had been configured to pass UDP to the correct ports but we must have missed one).

What I'm struggling with is understanding what a good end to end traffic flow should look like i.e. not just a clean capture (which I can obtain at home) but what each element sequence means. If it were 'normal' SIP/SDP with RTP/RTCP traffic then one of the Wireshark books has some good worked examples. However, Google uses STUN, RTP, RTCP and SRTP and I don't understand the hand-off's between each protocol (STUN seems very hard to understand even after reading the RFC's).

Any help or pointers to online information would be much appreciated.

Regards, Matt

asked 05 Jul '14, 04:36

hootsmagandy's gravatar image

hootsmagandy
26113
accept rate: 0%


One Answer:

0

Unfortunately I don't have sample traffic, but maybe I can answer some of your questions without that.

we'd thought all our Corporate Firewalls had been configured to pass UDP to the correct ports but we must have missed one).

There is a list of ports that Hangout is using: https://support.google.com/a/answer/1279090?hl=en

However, Google uses STUN, RTP, RTCP and SRTP and I don't understand the hand-off's between each protocol (STUN seems very hard to understand even after reading the RFC's).

The mentioned protocols are all required for Video and Audio data. I'm not sure if this is the right place to explain all of them, especially as there are loads of explanation pages on the internet.

STUN seems very hard to understand even after reading the RFC's)

Actually it's pretty easy: By using STUN the client tries to figure out if it is placed behind a NAT device. The IP address of the STUN packet will be different than the IP address placed in the payload by the STUN server (the address the server sees - usually the NATed address). If the client knows it external (NATed) IP address, it can use that information in protocols like SIP and H.323 (and probably internally within the Hangout protocols) to allow the other side to send data to the correct (NATed) address.

The key to success for Hangout through a firewall is to allow incoming UDP traffic on ports 19302 through 19309 from the internet, as stated in the link I posted above.

Cite:

The ideal connection for a user to make to a hangout is through UDP. To allow this connection attempt to succeed you will need to allow connections into your network from UDP ports 19302 through 19309.

That's kind of odd and dumb, as they won't tell you the IP addresses of the Google Hangout/Conference servers (probably because there are too many and they are subject to change), so you'll have to break a hole into your firewall policy just to make Hangout work, or buy a firewall that is able to detect Hangout traffic and do the rest auto-magically in the background, hopefully in a secure way ;-))

Regards
Kurt

answered 08 Jul '14, 07:18

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%