Focus 1: Browser Interoperability

[rainliu]

Focus 1: Browser Interoperability

Ensuring seamless interoperability with all major browsers is critical for real-world deployments. While the core protocol implementation is complete, comprehensive browser testing and compatibility verification is ongoing.

Target Browsers

Browser	Platform	Status	Priority
Chrome/Chromium	Windows, macOS, Linux	🔄 In Progress	High
Firefox	Windows, macOS, Linux	🔄 In Progress	High
Safari	macOS, iOS	📋 Planned	High
Edge	Windows	📋 Planned	Medium
Mobile Chrome	Android	📋 Planned	Medium
Mobile Safari	iOS	📋 Planned	Medium

Interoperability Test Scenarios

Data Channels:

• Reliable ordered channels
• Unreliable unordered channels
• Multiple concurrent channels
• Large message fragmentation
• Binary and text messages

Media:

• Audio-only calls (Opus codec)
• Video-only streams (VP8, VP9, H.264)
• Audio + Video combined
• Simulcast with layer switching
• Screen sharing

ICE & Connectivity:

• Direct host-to-host connection
• STUN-assisted connectivity
• TURN relay fallback
• Trickle ICE candidate exchange
• ICE restart mid-session
• mDNS candidate handling

SDP Negotiation:

• Offer/Answer exchange
• Renegotiation (add/remove tracks)
• Codec negotiation
• Extension negotiation
• Rejected media sections

Browser-Specific Quirks

Each browser has its own WebRTC implementation quirks that need to be handled:

┌─────────────────────────────────────────────────────────────────────────────┐
│                     Browser Compatibility Matrix                            │
├─────────────────────────────────────────────────────────────────────────────┤
│  Issue                          │ Chrome │ Firefox │ Safari │ Edge          │
├─────────────────────────────────┼────────┼─────────┼────────┼───────────────┤
│  SDP format variations          │   ✓    │    ✓    │   ⚠    │    ✓          │
│  ICE candidate formatting       │   ✓    │    ✓    │   ⚠    │    ✓          │
│  DTLS role handling             │   ✓    │    ✓    │   ⚠    │    ✓          │
│  Data channel negotiation       │   ✓    │    ✓    │   ✓    │    ✓          │
│  Simulcast configuration        │   ✓    │    ⚠    │   ⚠    │    ✓          │
│  TWCC support                   │   ✓    │    ✓    │   ⚠    │    ✓          │
└─────────────────────────────────┴────────┴─────────┴────────┴───────────────┘
  ✓ = Works as expected   ⚠ = Requires special handling   ✗ = Known issues

Automated Browser Testing

Planned infrastructure:

1. Selenium/Playwright tests — Automated browser control for E2E testing
2. WebDriver BiDi — Modern browser automation protocol
3. CI integration — Run browser tests on every PR
4. Cross-platform matrix — Test on Windows, macOS, Linux

# Example CI configuration (planned)
browser-interop:
  strategy:
    matrix:
      browser: [chrome, firefox, safari, edge]
      os: [ubuntu-latest, macos-latest, windows-latest]
  steps:
    - run: cargo build --release
    - run: ./run-browser-tests.sh ${{ matrix.browser }}

Known Issues to Address

• Safari SDP parsing edge cases
• Firefox simulcast layer negotiation
• Mobile browser power management
• Browser-specific codec preferences
• ICE candidate timing differences

[StefanoD]

Safari SDP / ICE interop — investigation status

I audited the "Safari SDP parsing edge cases" and the related interop items
(ICE candidate formatting, DTLS role, simulcast, TWCC) against the RFCs and the
current code, testing against a real WebRTC offer captured from Safari 26.5.2
(which, being libwebrtc-based, produces Chrome-like SDP).

Summary: modern Safari's common SDP already parses; the concrete gaps were
narrow. Three fixes are up as separate PRs, and three of the flagged areas are
already correct.

Fixes (PRs)

• sdp: accept any RFC 8866 <proto> token in m= lines #114 — the m= <proto> sub-field was a hardcoded allowlist that rejected
  IANA-registered transports (UDP/BFCP, TCP/DTLS/SCTP, UDP/UDT/IX, …).
  RFC 8866 §5.14 makes <proto> extensible ("New transport protocols MAY be
  defined, and MUST be registered with IANA") → accept any token.
• sdp: allow extmap IDs up to 255 per RFC 8285 #115 — ExtMap::unmarshal capped extension IDs at 246; RFC 8285 §4.3
  allows 1-255. Latent (Safari's max extmap ID is 14), but a real conformance
  defect found while auditing TWCC.
• Default mDNS mode to QueryOnly so Safari ICE candidates resolve #116 — the real Safari ICE blocker. SettingEngine defaulted the
  multicast-DNS mode to Disabled (with a //TODO: Re-enable it to QueryOnly),
  so Safari's default mDNS-only <uuid>.local host candidates were silently
  dropped → zero usable remote candidates → ICE could not connect. Defaulted to
  QueryOnly (matching the enum's own #[default] and AgentConfig::default).
  Verified end-to-end: rtc-mdns resolved Safari's actual .local candidate to
  its LAN IP over the network.

Verified already-correct (no change needed)

• ICE candidate formatting — the parser already accepts Safari's mDNS
  <uuid>.local connection-address and ignores the non-standard
  generation/network-cost extension tail, per RFC 8839 §5.1. (The only ICE
  issue was the mDNS-mode default above.)
• DTLS role handling — a=setup:actpass → the answerer correctly derives
  active/DTLS-client; the media-level sha-256 a=fingerprint is parsed.
  RFC 8842 / RFC 4145 / RFC 8122.
• Simulcast — a=rid:<id> send and a=simulcast:send h;m;l are parsed by
  get_rids, and the RID / repaired-RID header extensions are registered for
  demux. RFC 8851 / RFC 8853.
• TWCC — the transport-wide-cc extmap URI matches byte-for-byte and
  a=rtcp-fb:<pt> transport-cc is negotiated for audio and video via the default
  interceptors. RFC 8285 + draft-holmer-rmcat-transport-wide-cc-extensions-01.

Each PR has reproduce-first tests, and the Safari 26.5.2 offer is frozen as a
regression fixture.