81a6d9c9 wired getRtcTransports() but its .well-known fallback read
mx.getClientWellKnown(), which the SDK only populates when the client
is started with clientWellKnownPollPeriod — cinny never sets it, so on
the live client the fallback returned [] and calls still failed with
MISSING_MATRIX_RTC_TRANSPORT after deploy. (The unit test faked a
populated cache and hid this.)
The driver now fetches the client .well-known itself, once, via
AutoDiscovery.getRawClientConfig(domain) — the same resolver Element
Call used before 0.22 — and only when the SDK has nothing cached. Test
added for the uncached path (asserts a single fetch); verified the
resolver returns the livekit focus for matrix.lotusguild.org.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA
Since the upstream v0.25.0 merge, Element Call in widget mode no longer
reads .well-known for its LiveKit transport; it asks the HOST via the
widget API (org.matrix.msc4515.get_rtc_transports, capability
org.matrix.msc4515.rtc_transports). cinny never granted the capability
nor implemented WidgetDriver.getRtcTransports(), so discovery returned
nothing and every join failed with "Call is not supported"
(MISSING_MATRIX_RTC_TRANSPORT) — the [LocalMembership] Multiple
Transport Errors line in the browser console.
- matrix-widget-api 1.17.0 -> 1.18.0 (adds MSC4515; also changes the
sendDelayedEvent driver signature, adapted — parent delay ids were
removed from the draft).
- Grant MSC4515RtcTransports in getCallCapabilities.
- CallWidgetDriver.getRtcTransports(): homeserver /rtc/transports
(MSC4143) first, then the .well-known org.matrix.msc4143.rtc_foci list
(what matrix.lotusguild.org advertises today). Unit-tested.
Server side needs no change: the well-known already carries the livekit
focus and the JWT service answers.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PPmy3tPq869XDW4njjVaKA