A phone can be a useful fourth angle, reporter camera or short-notice backup, but only if its invitation and recovery path are treated as production work. In Callaba, an authenticated operator creates a phone-publish invitation and the recipient redeems its opaque token; the invitation and returned publishing values are credentials, not call-sheet text. This guide covers the handoff from operator to contributor and back to a verified mixer source without inventing phone-app menus or treating the public demo as an operator console.
Assign a phone one bounded production job
Start with a job that the phone can complete: a reporter stand-up, a reaction angle, a brief mobile cutaway, or a backup source. Do not make it the only path for essential speech unless the team has rehearsed its audio and recovery path. A phone is easier to add when the producer knows whether it is a live scene source, a monitored reserve, or an occasional contribution.
| Decision | Write on the worksheet | What to verify |
|---|---|---|
| Source name | Role and person, for example “Reporter—north gate” | The operator can distinguish it from every other source |
| Picture | Front camera for a stand-up; rear camera for the scene when appropriate | Framing and orientation suit its assigned scene |
| Sound | Phone microphone, external microphone, or picture only | The source does not accidentally replace the planned Program speech |
| Fallback | Safe scene and local contact method | Program can continue while the phone reconnects |
This is also the right time to choose a source profile that matches the production rather than chase an abstract maximum. Test the intended image and sound on the real network and at the intended position. The article does not prescribe a bitrate, resolution or browser choice because those values depend on the device, contributor page and deployed workflow.
Handle the QR invitation as a credential handoff
Create the phone-publish invitation from an authenticated operator workflow and deliver its QR invitation only to the intended contributor. The token, publisher path and publish URL are credentials. They do not belong in a public chat, a screenshot attached to a runbook, source control, or production logs.
The contributor scans the invitation and redeems the opaque token in the supplied phone path. They should see the page's own permission request and choose whether to grant camera and microphone access. Browser media capture requires a secure context and user permission; a declined, missing or busy device may prevent a usable stream. That is a normal preflight condition, not a reason to improvise a different credential path.
Reusable invitations remain usable until an authenticated operator revokes them. Keep that control concern separate from the contributor's invitation: the contributor should not receive an owner API key merely to make a phone feed work.
Inspect the phone-to-mixer workflow
The public mixer example is for observing the production flow only. Use an authenticated operator environment to create, cancel and manage phone-publish invitations; use the intended phone path to request permissions and redeem the invitation.
- Confirm the source role, assigned scene and fallback before creating an invitation.
- Treat the QR invitation and returned publishing values as credentials.
- Test camera, microphone and orientation on the actual contributor device and network.
- Rehearse stop-and-return off air, then cancel the phone session when its job is complete.
Watch the public mixer here. To connect a phone by QR, use an operator-managed invitation; the contributor must allow camera and microphone access on their phone.
Open Live mixer in a new tab ↗Loading public workspace…
Confirm picture and microphone before the source reaches Program
Have the contributor stand where they will work, then make a short picture and sound check. A front-facing camera is commonly suitable for a direct-to-camera stand-up; a rear-facing camera generally faces the environment and may suit a scene or interview. Browsers expose those as media constraints, but the available choice is device-dependent. Let the contributor confirm the actual picture rather than relying on a label.
Ask four concrete questions: Is the lens clean? Is the phone in the intended orientation? Is the phone microphone or external microphone producing intelligible sound? Is the contributor wearing headphones or positioned to avoid an obvious feedback loop? The operator checks the arriving source in Multiview or the selected mixer input; the producer decides when it earns a place in a Preview scene.
Put the phone into a simple scene first, then load that scene in Preview. Check crop, headroom, exposure changes and audio relationship before taking it to Program. When the source is a moving cutaway, separate “useful natural sound” from “audio that must carry the story.” Those are often different choices.
Treat reconnection as an off-air recovery
A phone can change network or lose foreground access during a real assignment. The production response is to leave a safe scene in Program, tell the contributor which contact channel to use, and let the operator verify the returning source before it goes back into a scene. Do not repeatedly take a tile to air in the hope that it has recovered.
- Keep the designated wide, presenter or other safe scene in Program.
- Confirm whether the issue is limited to the phone source or also affects the operator's broader contribution environment.
- Ask the contributor to return to the approved invitation path and re-check the page's camera and microphone permissions; avoid sending credentials in a new ad-hoc message.
- When picture returns, check it in the monitored source view, rebuild it in Preview if needed, then take it only when the producer is satisfied.
The expected result is continuity: the audience keeps receiving a deliberate Program scene while the contributor is recovered off air. A reconnection test during rehearsal should include a real stop-and-return, not only opening the phone page at the desk.
Close the access path after the contribution
When the contributor's work is complete, revoke the invitation from the authenticated operator workflow. Record the event owner and result in the production notes rather than assuming a phone browser tab is an access-control mechanism.
Use a fresh invitation when that makes the next contributor or assignment easier to audit. Do not reuse a captured QR image as a convenience shortcut, and do not retain returned connection values in support tickets or recordings. If a phone is lost, the wrong person receives an invitation, or the scope of the contribution changes, revoke the old handoff before continuing.
These controls protect the invitation workflow. They do not replace the venue's device management, the contributor's lock screen, a secure communications policy, or a full incident-response procedure.
Next steps
Run the invitation, permission, picture, microphone, stop-and-return and cancellation checks with one real phone before adding the workflow to a live show. Then add the source to a recovery-capable mixer scene and practice the producer handoff. The public mixer example can help a team recognize the interface, but it is view-only; create and manage invitations only in the authenticated operator workflow.
