You press a talk button on your phone and the other person hears you moments later. Under the hood, several layers usually work together. This page explains a common “app PTT + real-time audio” pattern in plain language—so the complexity is easier to picture.
Vendors name layers differently, but most separate: accounts and permissions, who’s online and who may talk, how audio travels, and how media is relayed when a direct path fails. Product details always follow the official site.
What the layers typically do
| Layer (plain words) | Common tech | Main job |
|---|---|---|
| Accounts & business | HTTPS, etc. | Sign-in, groups, quotas, short-lived credentials |
| Control & floor | Secure long-lived links (e.g. WSS) | Presence, talk arbitration, reconnect, call setup |
| Audio & video | WebRTC, etc. | Real-time media; small groups may go peer-to-peer, larger ones via a server |
| NAT relay | TURN, etc. | Helps media through hard networks; usually not business rules |
Direct path vs server forwarding
Small groups on good networks often prefer a direct path for lower delay. Larger or trickier networks often use selective forwarding (SFU) so phones do less work. When to switch depends on group size and network checks—policies vary.
Multi-region deployments
Large services may connect users to nearby regions. That raises data-residency and compliance questions that need deliberate design.
Security in brief
Control planes usually use encrypted links and short-lived tokens; media often uses channel encryption. Token handling, certificate renewal, and relay credentials are ongoing ops and product-security work.
See also
Official product commitments follow published product docs.