Source-linked AI summary
Where Does My Call Go? Measuring Google Meet, Zoom, and Microsoft Teams on Starlink
Kousar Malekinasab, Mostafa Abdollah, Jinwei Zhao, Jianping Pan
TL;DR
This paper investigates how RTC platforms select service points over Starlink, where the egress PoP can vary across locations and change during flights. Using a Canada-wide testbed and more than 24 hours of in-flight measurements, it finds distinct strategies across Google Meet, Zoom, and Microsoft Teams, with some selections poorly aligned to egress paths or peer location.
Problem
Evidence is limited on how RTC providers select media service points over Starlink across different PoPs and mobility settings.
Source: §1 · p. 1Method
Results
Takeaways & Limitations
The findings suggest that Starlink egress dynamics and provider service-point selection can mismatch, motivating further measurement and LEO-oriented service placement and selection designs.
Source: §1 · p. 2
Abstract
from arXiv · showhide
Low-Earth-Orbit (LEO) satellite networks are expanding broadband access, but major Real-Time Communication (RTC) platforms, including Google Meet, Zoom, and Microsoft Teams, still rely on service-point selection mechanisms that appear to be largely shaped by terrestrial-network assumptions. As a result, they may not consistently account for LEO-specific dynamics such as satellite topology and Point-of-Presence (PoP) changes, especially during in-flight connectivity. To characterize RTC service-point selection over Starlink, we measure RTC performance using a Canada-wide testbed and more than 24 hours of in-flight experiments. Our results show clear platform differences. Google Meet tends to align more closely with the serving PoP, consistent with broader observed edge coverage. Zoom follows a regional service-point selection pattern, while Microsoft Teams often remains tied to fixed service points. Moreover, we show that in-flight PoP handovers can shift traffic egress points mid-session, and that RTC platforms respond differently to these changes. In some cases, this interaction leads to suboptimal service-point selections and RTT inflation. Overall, our findings suggest that LEO connectivity can expose mismatches between Starlink egress dynamics and RTC service-point selection, motivating further measurement and LEO-optimized designs for service placement and selection.
1 Introduction
The paper asks how terrestrial-oriented RTC service selection behaves over Starlink, where egress PoPs can vary or change during flights. It measures three platforms across stationary Canadian locations and in-flight sessions, finding distinct selection strategies and potential path mismatches.
1 Introduction
- The paper identifies a gap in evidence on how RTC platforms select service points over Starlink, especially across PoPs and during mobility.Existing Starlink RTC studies mainly measure client-side performance rather than provider service-point selection and its routing and latency effects.Source: §1 · p. 1
- Measurements cover seven Canadian Starlink locations and six commercial flights totaling more than 24 hours of traces.Stationary scenarios vary PoP associations and participant counts; flight traces capture mobility, PoP handovers, and changing user–PoP distance.Source: §1 · p. 1, Figure 1 · p. 2
- Google Meet generally selects service points near the associated Starlink PoP, Zoom uses regional hubs, and Microsoft Teams often remains tied to a fixed service point.Meet’s alignment is consistent with broader observed edge coverage; Teams commonly used San Antonio or Boydton in these measurements.Source: §1 · p. 2
- During flights, Meet often changes service points with the active Starlink access path, Zoom usually stays within regional hubs, and Teams typically keeps its session-selected service point.When the PoP remains unchanged, Meet and Teams are generally stable, while Zoom can switch without an observed handover; some selections are poorly aligned with peer location and can produce hairpinning.Source: §1 · p. 2
- The paper concludes that provider-specific service selection can coincide with less favorable end-to-end paths, particularly when in-flight service points do not align with Starlink egress or peer location.The authors make the dataset publicly available to support reproducibility and follow-up measurements.Source: §1 · p. 2
2 Related Work
Prior RTC measurement work largely examines client-side performance or regional differences in terrestrial networks, while Starlink studies have concentrated on Zoom or network-layer behavior. This paper addresses the limited evidence on service-point selection across providers and stationary and in-flight Starlink settings.
2 Related Work
- Prior terrestrial studies measured client-side QoS and QoE or inferred regional infrastructure effects, but did not focus on service-point selection over Starlink.The cited work includes measurements across WiFi and 4G, client-side configurations, and geo-distributed clients in US and European regions.Source: §2 · p. 2
- Most prior WebRTC measurements over Starlink focused on Zoom and stationary nodes, while recent in-flight LEO studies examined network and transport layers rather than application-layer RTC.The paper shifts attention to the interaction between Starlink egress dynamics and externally observable RTC service-point selection.Source: §2 · pp. 2–3
3 Measurement Design Overview
The study compares browser-based Google Meet, Zoom, and Microsoft Teams using WebRTC telemetry to infer service points and analyze paths over Starlink. It combines fixed-PoP measurements at Canadian locations with repeated sessions on six Starlink-enabled flights.
3 Measurement Design Overview
- The study evaluates the web versions of Google Meet, Zoom, and Microsoft Teams, without assuming equivalence to native clients.The choice provides a consistent interface for collecting WebRTC data needed to infer service-point selection and analyze paths.Source: §3 · p. 3
- The measurement framework uses the remote address from WebRTC’s nominated ICE candidate pair to infer a service point, defined as the externally visible provider-side RTC endpoint reached by a session.Inferred endpoints are annotated with ASN, operator, and approximate location, then compared with the active Starlink egress PoP.Source: §3 · p. 3
- Service-point inferences are retained when candidate information, IP ownership, geolocation, and UDP- or TCP-based path measurements are consistent.The same validation procedure is applied across all three platforms.Source: §3 · p. 3
- Stationary measurements span seven Canadian locations over more than 10 hours, while in-flight measurements cover six WestJet flights and more than 24 hours.Flights used repeated 10-minute sessions per provider, creating fresh service-point selection opportunities rather than maintaining one continuous call.Source: §3 · p. 3
4 Service-Point Selection for Stationary Starlink Users
For stationary Starlink users, the three RTC platforms select service points differently across shared-PoP, different-PoP, and multi-party sessions. Google Meet aligns most closely with the active egress PoP, Zoom uses regional hubs, and Microsoft Teams is more centralized.
4 Service-Point Selection for Stationary Starlink Users
- Even with the same Starlink egress PoP, Zoom selects San Jose, Microsoft Teams San Antonio, and Google Meet Seattle.This illustrates that provider-side selection can shape the traffic path even when Starlink egress is identical.Source: §4 · p. 4
- Google Meet and Zoom generally have RTT samples below 75–100 ms, whereas Microsoft Teams has median RTTs around 120–160 ms and tails often beyond 180–200 ms.The paper associates Teams’ higher latency with its more centralized anchoring strategy, compared with the more localized selection observed for Meet and Zoom.Source: §4 · p. 4, Figure 5 · p. 4
- In multi-party sessions, Teams routes Groups 1 and 2 to Boydton and Group 3 to San Antonio, while Zoom preserves regional hubs and Meet most closely follows egress geography.Google Meet’s exception is Thompson, which exits through Minneapolis and connects to Chicago infrastructure.Source: §4 · p. 4
- Across stationary sessions, Google Meet aligns most closely with Starlink egress PoPs, Zoom follows regional hub steering, and Microsoft Teams remains more centralized.Teams anchors multi-party sessions to the service point selected for the first participant, while Zoom generally directs eastern users to Virginia and western users to San Jose.Source: §4 · p. 4
5 In-flight Starlink Users
This section examines how in-flight Starlink PoP changes relate to RTC service-point selection and RTT. Across platforms, Google Meet often follows the serving region, Microsoft Teams tends to stay session-anchored, and Zoom uses regional hubs with some instability.
5 In-flight Starlink Users
- Microsoft Teams can remain anchored to a distant service point despite changing serving PoPs, and its in-flight RTTs are consistently higher than Google Meet and Zoom.Several routes show Teams RTT medians of 130–200 ms, with tails beyond 250–300 ms.Source: §5 · p. 5, Figure 6 · p. 5
- Google Meet usually selects a nearby service point and remains stable for a given PoP, but route-dependent mismatches can coincide with higher RTT.On YYZ→YEG, Chicago remained selected after a transition to mplsmnx1, while Seattle was selected for clgycan1 despite closer service points being available.Source: §5 · p. 5, Figure 7 · p. 5
- Zoom typically uses San Jose or Virginia rather than tracking each serving PoP, and its service-point changes can coincide with RTT increases.On YEG↔YYZ, Zoom switched between east- and west-coast service points while the PoP was fixed; a separate PoP switch also coincided with a noticeable RTT increase.Source: §5 · pp. 5–6, Figure 8 · p. 6
- Zoom generally has lower RTT than Microsoft Teams, but its RTT distributions are less compact than Google Meet’s on several routes.The text associates wider spread with regional-hub behavior, including unnecessary cross-region switches that introduce RTT inflation and longer tails.Source: §5 · p. 6
- Google Meet often changes service points with Starlink serving-PoP transitions, while Microsoft Teams typically stays session-anchored and Zoom uses regional hubs.Zoom may also change service points without an observed PoP handover.Source: §5 · pp. 5–6
6 Conclusion
The study measures browser-based RTC over Starlink with a Canada-wide testbed and more than 24 hours of in-flight experiments. It finds platform-specific service-point strategies and suggests that their interaction with changing Starlink egress PoPs can affect latency.
6 Conclusion
- Google Meet, Zoom, and Microsoft Teams show different service-point selection behaviors over the same LEO access network.During flights, Google Meet often follows the serving region, Teams is largely session-anchored, and Zoom follows regional hubs with occasional changes coinciding with RTT inflation.Source: §6 · p. 6
- The study measures browser-based RTC over Starlink using a Canada-wide testbed and more than 24 hours of in-flight measurements.The authors motivate future measurements that include terrestrial baselines, native clients, and controlled provider comparisons.Source: §6 · p. 6
- Starlink egress dynamics and provider service-point selection can interact in ways that affect latency, especially during in-flight connectivity.Source: §6 · p. 6
A Inbound Video Performance Details
Inbound video measurements show that jitter variability and playback impairments distinguish Microsoft Teams from Google Meet, despite similar resolution profiles. Zoom exposes less browser-accessible video telemetry than the other platforms.
A Inbound Video Performance Details
- Teams shows wider jitter ranges than Meet in Fredericton, Thompson, and Saskatoon, and these larger excursions coincide with more packet loss and freeze events.Teams' jitter ranges are [0,126] ms, [0,101] ms, and [0,84] ms, compared with Meet's [5,88] ms, [4,39] ms, and [5,57] ms, respectively.Source: A Inbound Video Performance Details · p. 7
- Despite comparable 720p inbound profiles, Meet has lower inbound bitrate, higher frame rate, and fewer playback impairments than Teams.Meet uses VP9 with a stable encoding profile; Teams uses H.264 and frequently reports bandwidth limitation.Source: A Inbound Video Performance Details · p. 7
- Zoom's browser-accessible telemetry includes ICE-related information and RTT to the selected peer, but omits jitter, frame rate, resolution, and bitrate.Source: A Inbound Video Performance Details · p. 7
B Additional In-Flight RTT Measurements
Route-specific flight measurements illustrate different platform responses to Starlink PoP changes: Teams remains session-anchored, Meet follows PoP transitions, and Zoom moves among regional service points. These examples complement the main-text analysis.
Additional In-Flight RTT Measurements
- These route-specific measurements complement the main-text analysis of in-flight behavior across the three platforms.Source: B Additional In-Flight RTT Measurements · p. 7
Microsoft Teams – YEG→YYJ
- On YEG→YYJ, Teams uses Virginia outbound and San Jose on the return, with stable selections showing no clear correlation to RTT, host direction, or available PoPs.Source: B Additional In-Flight RTT Measurements · p. 7
Google Meet – YVR→OGG
- On YVR→OGG, Meet changes service points in step with PoP transitions and keeps its selection stable while the user remains on the same PoP.RTT evolution broadly tracks whether the aircraft moves closer to or farther from the associated PoP.Source: B Additional In-Flight RTT Measurements · p. 7
Zoom – YEG→YYZ
- On YEG→YYZ, Zoom oscillates between San Jose and Virginia before settling on Virginia, where RTT reaches a stable 32–49 ms range by flight's end.After Starlink stabilized on mplsmnx1, traffic remained associated with Virginia through chcoilx1 and mntlcan1.Source: B Additional In-Flight RTT Measurements · p. 7
Zoom – YEG→YYJ
- On YEG→YYJ, Zoom mostly uses San Jose, with brief switches to Virginia after PoP transitions before returning to San Jose.The brief switches occur after clgycan1 association on the outbound and during the clgycan1-to-sttlwax1 transition on the return.Source: B Additional In-Flight RTT Measurements · p. 7
C Direct and Indirect AS-Level Connectivity from Starlink to Google
Starlink-to-Google connectivity is often direct on measured terrestrial flight routes, but PoP-dependent indirect paths also occur. Direct connectivity is associated with lower average RTT on terrestrial routes, while RTT remains high on a long oceanic route despite direct connectivity.
C Direct and Indirect AS-Level Connectivity from Starlink to Google
- Direct Starlink-to-Google connectivity is common but not universal on measured terrestrial flight routes, with direct and indirect paths varying by PoP on YYZ→YEG and YEG→YYJ.Similar behavior is observed on the return flights YEG→YYZ and YYJ→YEG.Source: C Direct and Indirect AS-Level… · p. 7
- Direct connectivity yields lower average Google Meet RTT than indirect connectivity on terrestrial routes, where traffic traverses transit ASes before reaching Google.Source: C Direct and Indirect AS-Level… · p. 7
- The long oceanic YVR→OGG route has consistently direct connectivity but substantially higher RTT, which may reflect longer terrestrial or submarine paths to the selected service point.Source: C Direct and Indirect AS-Level… · p. 8
D Proximity Mismatch in Service-Point Selection
Google Meet's observed service-point selection is not always nearest to the Starlink egress location. The measurements suggest that backend constraints or other service-assignment factors may direct traffic to farther points despite closer alternatives.
D Proximity Mismatch in Service-Point Selection
- Calgary and Minneapolis PoPs are observed to associate with Seattle and Chicago Google service points, respectively, despite other service points appearing geographically closer.Figure 10 shows observed Google Meet service-point selection for users in Saskatoon and Thompson.Source: D Proximity Mismatch in Service-Point… · p. 8, Figure 10 · p. 9
- The observed selections suggest Meet is not strictly proximity-aware, though backend constraints or assignment factors not visible in the measurements may explain them.Traffic may therefore be directed to farther service points despite closer alternatives.Source: D Proximity Mismatch in Service-Point… · p. 8