A 1:1 call and a meeting are different animals on the wire: one negotiates a private path that can go peer-to-peer, the other always converges on the conference service. Escalation from one to the other is a live surgery worth watching once.
The flow — what actually happens
Plain-language first; the packet-level
view underneath each step is what you'd see in a Wireshark trace, and what healthy looks like.
-
1:1 setup — the private negotiation
Alice calls Bob: signalling invites Bob's endpoints, both sides gather ICE candidates (as in the network concept), and — uniquely for 1:1 — a DIRECT path between their machines is tried first. Same office LAN? Media may never leave the building.
On the wire STUN checks between the two clients' host/reflexive candidates; on success, bidirectional SRTP directly between their IPs. Relay candidates sit ready as fallback — you can watch the pair choice in a capture: private IPs = P2P won.
-
1:1 in progress — renegotiation is normal
Add video, start sharing, switch Wi-Fi to wired — each triggers renegotiation on the live call. Brief media gaps at those moments are the mechanism, not a fault.
On the wire Fresh ICE activity mid-call (new checks, possibly a new selected pair). A path SWITCH mid-call (P2P to relay after a network change) is visible as the SRTP destination flipping.
-
Escalation — the surgery
Alice adds Carol. A 1:1 cannot become three-way P2P; instead a CONFERENCE is born on the service, and both original legs are torn down and re-homed to it. That momentary 'connecting…' blip during the add is the transplant happening.
On the wire The P2P SRTP stops; both clients run new ICE toward conference relay candidates; media resumes to Microsoft ranges. In CQD this call now appears as a conference with three participants — the 1:1's afterlife.
-
Conference steady-state
From here it is the large-meeting model at any size: every participant one uplink to the service, per-receiver forwarding decides what each person downloads. There is no P2P in conferences, ever — two colleagues in a meeting still route via the service.
On the wire All SRTP to/from Microsoft relay ranges; per-client downlink count tracks visible tiles, not participant count.
Why the distinction runs every diagnosis
| Property |
1:1 |
Conference |
| Media path |
P2P if possible, relay otherwise |
Always the conference service |
| Who mixes |
Nobody (two streams) |
The service, per receiver |
| Firewall sensitivity |
BOTH ends' client-to-client reachability matters |
Only each side's path to Microsoft |
| Quality blame surface |
Either endpoint's network, or the P2P path |
Each leg independently to Microsoft |
Consequences worth internalising:
- "Calls fine, meetings terrible" (or the reverse) is a routing clue, not a
contradiction: different paths, different bottleneck. P2P fine + meetings bad →
the path to Microsoft (proxy/VPN?) is the suspect. Meetings fine + 1:1 bad →
client-to-client blocking (host firewalls, inter-VLAN rules).
- P2P surprises security teams: two clients exchanging UDP directly on the LAN
is by design; blocking client-to-client media just forces relay hairpins for
every internal call.
- Escalation blips are normal — but a call that DROPS on add-participant means
the conference path failed while the P2P path worked: check Microsoft
reachability, not the users.
What to watch (proofs)
- The chosen path, live: during a test 1:1, capture on one endpoint — SRTP peer =
colleague's IP (P2P) vs 52.112/13.107 ranges (relay). One capture teaches more
than ten docs.
- The same fact without Wireshark: per-call telemetry in Call Analytics (user >
call > media tab) names the connectivity type (direct vs relay) per stream.
- Escalation in the record: CQD/call analytics show the 1:1 ending and a
conference beginning at the add moment — correlate by timestamps to explain
'the call restarted itself'.
- Renegotiation blips: client media logs mark ICE restarts on network change —
match them to user-reported gap times to close 'random glitch' tickets with a
cause.
Discussion
No messages yet — start the thread.
