webrtc-workflow

WebRTC Workflow

Purpose

Use this skill when a task needs real-time browser or native media, peer connection behavior, data channels, NAT traversal, or WebRTC signaling. Keep signaling, media transport, application state, and deployment roles separate.

Source Check

Check current sources before claiming behavior:

• W3C WebRTC
• RFC 8825: Real-Time Protocols for Browser-Based Applications
• RFC 8831: WebRTC Data Channels
• RFC 8445: Interactive Connectivity Establishment

Also check browser compatibility, native SDK docs, SFU/MCU docs, and deployment provider docs because behavior often depends on runtime and network shape.

Planning Workflow

1. Inspect the feature:
   • audio, video, screen sharing, camera capture, data channel, file transfer, game state, remote control, or mixed
   • browser, iOS/macOS, Android, desktop native, server-side media, or headless runtime
   • peer-to-peer, SFU, MCU, broadcast, recording, transcription, or relay topology
   • permissions, device selection, codecs, simulcast/SVC, bandwidth adaptation, and privacy needs
2. Separate responsibilities:
   • signaling channel: offer/answer exchange, trickle ICE, room/session state, auth, retries, and reconnection
   • media/data transport: peer connection, tracks, transceivers, DTLS/SRTP, SCTP data channels, congestion, and stats
   • NAT traversal: STUN, TURN, ICE candidates, relay policy, and corporate/mobile network constraints
   • application behavior: UI state, moderation, recording, storage, payments, analytics, and notifications
3. Choose topology:
   • peer-to-peer for small direct calls when NAT and scale fit
   • SFU for multi-party calls, server-side forwarding, selective subscription, recording, or moderation
   • MCU when server-side compositing is required and latency/cost tradeoffs are accepted
   • WebSocket or HTTP for signaling; do not confuse signaling with media transport
   • MoQ or HTTP streaming only when the media distribution problem is not conversational WebRTC
4. Route implementation to stack plugins:
   • web-dev-skills for browser UI and TypeScript integration
   • apple-dev-skills or android-dev-skills for native app integration
   • server-side-swift, python-skills, server-side-jvm, or rust-skills for signaling services, SFU integration, or backend work
   • cloud-deployment-skills for TURN, UDP, firewall, autoscaling, media servers, and hosting constraints

Diagnostics

Gather evidence from:

• browser WebRTC internals, stats, and network panels
• native SDK logs and permission state
• signaling logs with offer/answer and ICE candidate flow
• STUN/TURN reachability and credentials
• SFU/MCU room, track, and subscription logs
• packet capture only when logs cannot identify the failing hop

Name the failing layer: permissions, media capture, signaling, SDP, ICE, DTLS, SRTP, data channel, codec negotiation, SFU, TURN, firewall, or UI state.

Output Shape

Return:

1. WebRTC shape: media, data channel, or mixed; browser, native, server, or mixed.
2. Topology: peer-to-peer, SFU, MCU, broadcast, recording, or fallback.
3. Boundaries: signaling, media/data transport, NAT traversal, app state, and deployment owner.
4. Evidence: docs, code, logs, WebRTC stats, TURN/STUN checks, or browser/native runtime observations.
5. Validation: local call, multi-peer test, device/browser matrix, network path, media quality, stats, or manual gaps.
6. Handoffs: web, mobile, backend, cloud, MoQ, or diagnostics workflow.

Guardrails

• Do not treat WebRTC signaling as the media transport.
• Do not skip TURN planning for user-facing calls across real networks.
• Do not claim codec, permission, or browser behavior without current runtime/source checks.
• Do not replace WebRTC with MoQ for conversational media unless the product requirements explicitly fit that tradeoff.