Video Conferencing PCAP Analysis: Zoom, Webex, and GoTo

Video meetings combine signaling, media, DNS, TLS, NAT traversal, and sometimes transport fallback. A useful PCAP investigation must identify the user's actual flows before measuring loss or latency. Product ports and address ranges change, and encrypted media may not decode as RTP in Wireshark.

Do not begin with “filter all traffic on port X.” Begin with the affected endpoint, meeting time, direction, and symptom.

1. Establish the evidence boundary

Record:

• affected client IP and whether NAT changes it
• meeting start/end and exact bad-quality interval
• capture point and whether both directions are visible
• wired, Wi-Fi, VPN, or proxy path
• platform/client version and whether media relays or local gateways are used

Capture near the client when possible. A data-center SPAN may miss split-tunneled media; an endpoint capture may show offload artifacts.

2. Discover the meeting flows

Use DNS, connection timing, endpoint processes, vendor network documentation, and flow volume to build a candidate set. Zoom documents meeting traffic on TCP 443/8801/8802 and UDP 3478/3479/8801–8810, while Webex documents primary and fallback media paths that depend on the service and deployment. Treat these as discovery hints and validate them against the current vendor documentation and the actual trace.

Examples after you know the client address:

ip.addr == 10.0.8.24 && (tcp || udp)
dns && ip.addr == 10.0.8.24
tls.handshake.type == 1 && ip.addr == 10.0.8.24

Then use Statistics → Conversations and I/O Graphs to identify sustained high-rate UDP flows and signaling connections aligned with the meeting.

3. Measure the symptom, not just packet counts

For media that Wireshark decodes as RTP, use RTP stream analysis for sequence gaps, jitter, skew, and direction. For encrypted or proprietary media, derive equivalent evidence from UDP sequence behavior when exposed, inter-arrival timing, datagram-size patterns, flow interruptions, and path changes.

Distinguish:

• Capture loss from network loss: check capture drop counters and simultaneous gaps across unrelated flows.
• Bursty arrival from high average latency: inspect timing distribution, not only an average.
• One-direction impairment from a general outage: compare send and receive flows.
• Media impairment from signaling delay: align the user symptom with the correct flow.
• Fallback transport from ordinary reconnects: verify a move from preferred UDP media to a TCP/TLS path and its timing.

4. Compare a healthy baseline

A successful meeting from the same site is often more valuable than a generic threshold. Compare:

The comparison prevents a common error: blaming every retransmission or UDP gap in a busy meeting capture for the reported quality problem.

5. Write a bounded conclusion

Prefer:

From 14:32:18–14:32:41, the client's outbound media flow shows repeated sequence gaps and 80–240 ms arrival bursts while the inbound flow remains stable. The interval aligns with the user's frozen-video report and is absent from a healthy meeting on the same relay. The capture supports impairment between the client capture point and the media relay; it does not identify the congested hop.

Avoid:

Webex is slow because Wireshark found packet loss.

The first statement contains time, direction, baseline, user impact, and limitation. It also tells the network team what to measure next.

Platform-specific cautions

• Zoom: 8801 is a useful candidate, not a universal single-flow detector. Current official network rules include multiple ports and address ranges.
• Webex: media may use preferred UDP or fallback TCP paths; enterprise video devices, calling, and Meetings have different requirements.
• GoTo: do not assume every current meeting uses Citrix ICA. Discover the client flows and check the vendor's current network requirements for the deployed product.

PacketSafari's performance-analysis workflow correlates transport behavior, packet timing, and application outcomes while keeping the exact evidence available for review. Use the AI PCAP analyzer when you need to investigate multiple meeting flows without reducing the result to a protocol count.

Bottom line

Find the real media and signaling flows, align them with the user's bad interval, compare both directions and a healthy meeting, and preserve the boundary between packet evidence and infrastructure attribution. That method survives vendor protocol changes better than a hard-coded port filter.