DemoApp

Demo apps

Two complete applications in the repository, built on WebRTCme.Middleware, deliberate siblings of each other:

		runs on
WebRTCme.DemoApp.Blazor	Blazor WebAssembly, with MudBlazor	a browser
WebRTCme.DemoApp.Maui	.NET MAUI, with the Syncfusion MAUI Toolkit	Android, iOS, Mac Catalyst, Windows

Both do the same things, through the same view models, against the same servers. Between them they are how every platform in this framework gets exercised by a human.

If you want a starting point for your own app, read these rather than copying them. They carry demo scaffolding — a nav menu, an about page, a server-down banner — that your app does not want. The smallest real starting point is Getting started and Hello world.

What they do

Page
Connection parameters	Choose the connection type, the server, the room and your name
Call	The tiles, and the controls: mute microphone, mute camera, share screen, record, restart ICE, cap spatial layer
Chat	Messaging and file transfer over the data channel
About	Versions

The Blazor app adds a signalling server down banner, which is worth knowing about because it is the first thing you will see if the server is not running.

Before they do anything: run a server

Neither demo works out of the box. Both need a server you deploy, and the default addresses in their configuration point at a machine on the author's LAN — 192.168.1.48 — which is not yours.

This is the single most common reason these apps appear broken. Do this first:

1. Pick a connection type. Signaling is the simpler path and the one to start with; its server is in this repository. MediaSoup needs Docker and a separate server.

2. Start the signalling server, bound to an address your devices can reach — not localhost if a phone is involved:

   dotnet run --project WebRTCme.Connection/Signaling/WebRTCme.Connection.Signaling.Server `
     --urls "https://0.0.0.0:5053;http://0.0.0.0:5052"

3. Point both demos at it. Edit SignalingServer:BaseUrl in:

   • WebRTCme.DemoApp/WebRTCme.DemoApp.Blazor/wwwroot/appsettings.json
   • WebRTCme.DemoApp/WebRTCme.DemoApp.Maui/appsettings.json

   "SignalingServer": { "BaseUrl": "https://<your machine>:5053" }

   Same for MediaSoupServer:BaseUrl if you are using the SFU.

Running them

Both demos reference the middleware by project, not by package, so they build from the source tree with no NuGet involved:

dotnet run --project WebRTCme.DemoApp/WebRTCme.DemoApp.Blazor

dotnet build WebRTCme.DemoApp/WebRTCme.DemoApp.Maui -f net10.0-windows10.0.22621.0 -t:Run
dotnet build WebRTCme.DemoApp/WebRTCme.DemoApp.Maui -f net10.0-android -t:Run

iOS and Mac Catalyst need a Mac to deploy, though both slices build on Windows.

A project reference is not a package test. These apps would build and run perfectly against a .nupkg that was missing libwebrtc.aar entirely. That is what Testing is for; the demos prove the code works, not that the package does.

Two clients, the same room name, two different display names — peer id is the display name, so two peers called the same thing collide.

Things in them worth stealing

MauiProgram.cs and Program.cs are the reference startups. Getting started is those two files with the demo-specific parts removed.

The ConsoleLoggerProvider registration in the MAUI app. Without it, every ILogger call in the middleware goes nowhere on every MAUI platform. If you are debugging a call on a device and seeing no library logs, this is why.

ConstraintsFor and the camera handling in CallViewModel, which the demos drive rather than reimplement.

One thing not to steal: WebRTCme.DemoApp.Blazor/Program.cs still carries a ConfigureProviders method that reaches into JSRuntime's non-public JsonSerializerOptions by reflection. Until 26.9.15 that was load-bearing — without it no Blazor app could create a peer connection at all. The fix now lives in the binding, so this is harmless leftover. Do not copy it into a new app; if you ever find you need it, that is a regression worth reporting.

Why the MAUI demo references the bindings directly

WebRTCme.DemoApp.Maui.csproj has a ProjectReference to each platform binding, which looks redundant next to its reference to the middleware. It is load-bearing, and only for project references:

WebRTCme and WebRTCme.Middleware reference the bindings with PrivateAssets="all", which keeps them out of the published packages' dependency lists — but also stops a binding's .resources.zip flowing to consumers. That zip is what the Apple SDK extracts WebRTC.xcframework from, so without it the app compiles, the registrar emits references to RTCAudioSession and friends, and then clang++ fails with "Undefined symbols for architecture arm64". Nothing on Windows shows it; it only appears when the Mac links.

Package consumers do not need this, and should not do it. In a package, the binding assembly and its zip sit side by side in lib/<tfm>/, which is the layout the SDK already understands.

About the MediaSoup defaults

The demos set UseSimulcast: false deliberately. The library supports simulcast; this SFU's congestion control collapses under it. Measured, with numbers, on Connection: MediaSoup.

What the demos are for

Beyond being samples, they are the framework's manual test rig — and honestly so. A headless test can prove frames arrive; it cannot prove they are drawn, the right way up, at the right size. That is exactly the frame-rotation bug class that took four commits across three platforms. So rendering is checked here, by a person, and Testing says so rather than implying coverage that does not exist.

The record of one call across all five platforms at once — what it showed, and what it cost to set up — is in doc/KnownGaps.md under "One call, five platforms".

Where next

Getting started	The same wiring, without the demo scaffolding
Middleware	The view models these bind to
Connection: Signaling	The server to run first
Troubleshooting	When a demo starts and then does nothing