A production stream key should identify one permitted RTMP connection—not become a password that everybody shares forever. In Callaba, an RTMP server can separate publishers from receivers, use explicit stream records or allowed hosts, and expose live connection data so an operator can see whether the expected client is actually sending or consuming media.
This guide is for the person issuing access, onboarding an external contributor, responding to an exposed key or diagnosing a connection that will not publish. If you only need the underlying concept, start with what a stream key is. The operating choices begin here.
Choose the access boundary before you send connection details
Create the Callaba RTMP server on a reachable TCP port, but do not treat a reachable port as permission to publish. Decide which access model owns admission:
| Access model | Use it when | Operational consequence |
|---|---|---|
| Explicit stream key | A known publisher or receiver needs a named identity. | You can separate roles, replace one credential and reject an unknown key without affecting everyone else. |
| Allowed host or IP | The client comes from controlled infrastructure with a stable address. | Address changes become an access event; this is usually unsuitable for contributors on dynamic consumer networks. |
| Intentional guest/open policy | Your product provides its own admission flow for external users who create or receive connection identities. | The RTMP server no longer relies on a pre-created identity gate alone. Product-level authorization, expiry and monitoring become essential. |
Explicit access is the safe starting point. “Allow all” is not a troubleshooting toggle to leave enabled after a test. It is a product decision for a workflow that deliberately accepts guest connections and has another boundary around who can obtain or use them.
Issue publisher and receiver access separately
- Name the owner. Use an event, venue, customer or device name that an operator can recognize during an incident.
- Choose one role. A publisher sends media. A receiver consumes it. Create separate records when both are required.
- Create a unique key. Do not reuse the same credential across unrelated producers or events merely because the RTMP server address is the same.
- Share only the required fields. Give the publisher the server URL and its publisher key. Do not include receiver or administrative credentials in the same message.
- Test one client first. Confirm the publisher count and non-zero input bitrate before connecting recordings, restreams, players or several guest users.
The server URL may be stable for a long time. The key should remain replaceable. Keeping those concerns separate lets you rotate one contributor without changing every downstream workflow.
Onboard a guest RTMP publisher without losing accountability
A guest may be a remote speaker, venue producer, customer or partner application. The useful product experience is self-service connection—not anonymous access to every stream on the server.
- Decide whether your application will create an explicit temporary Stream record for the guest or operate an intentionally open RTMP policy behind its own admission layer.
- Assign publisher-only access unless the guest also has a legitimate playback requirement.
- Show the guest only their URL and key, with a clear event window and a way to request a replacement.
- Ask them to connect before the live window and confirm the expected address or region, connection duration and input bitrate in Callaba.
- Revoke or expire access when the event or customer session ends.
The same principle applies to guest receivers: give them a receiver identity, not the publisher key. This prevents a playback user from becoming an ingest source and makes publisher and receiver counts meaningful.
Use live analytics to verify the identity is carrying media
Callaba's RTMP server statistics can report current publisher and receiver counts, input and output bitrate, connection duration, and available peer address, region and application metadata. These signals answer different questions:
- Publisher count: did the intended source establish a publishing session?
- Input bitrate: is media arriving, rather than only a TCP connection existing?
- Receiver count and output bitrate: is the feed being consumed where direct RTMP receiving is part of the workflow?
- Address and region: does the connection origin fit the producer or venue you expected?
- Duration: did the client remain connected through the required rehearsal or event window?
These are operational signals, not a permanent audit archive. Export or collect them externally when your incident, compliance or customer-reporting policy requires longer retention.
Rotate a key without making the live event the test
Rotation is a controlled handover. It should have an owner and a verification step.
- Inventory the dependency. Identify the encoder, automation, person and event that currently use the old key.
- Create the replacement. Keep the same narrow role; do not use rotation as a reason to broaden access.
- Update and test the client. If the operating workflow allows a parallel rehearsal path, prove the new key there. Otherwise schedule a controlled switch window.
- Confirm real media. Look for the expected publisher identity and non-zero input bitrate, not only a “connected” message in the encoder.
- Revoke the old key. Disconnect or disable it, then attempt a controlled reconnect and confirm rejection.
- Record the change. Store the new owner, issue date and planned expiry in the system that tracks secrets—never the key itself in an ordinary ticket.
If a key is visibly exposed during a broadcast or published online, prioritize containment. Create a clean credential and revoke the compromised one as soon as the continuity plan allows.
Troubleshoot from the first failed boundary
| Symptom | Check first | Next action |
|---|---|---|
| Encoder cannot connect | Server state, TCP port, firewall, RTMP URL and exact key | Test one known publisher record; do not enable allow-all merely to hide a wrong address or blocked port. |
| Connection is rejected | Publisher versus receiver role, key spelling and allowed host | Create or correct the explicit access record and remove copied whitespace from the credential. |
| Publisher count is one but input bitrate is zero | Encoder output, selected scene, audio/video enablement | Repair the source before changing server access control. |
| Unexpected publisher appears | Peer address/region, key owner and recent sharing | Disconnect if required, rotate that identity and determine where the key was exposed. |
| A receiver cannot play | Receiver role and output bitrate | Do not give the receiver the publisher key; create the correct role and verify that the source is already flowing. |
| Old key still works after rotation | Whether the old access record was actually disabled or removed | Revoke it and test a fresh connection, not an already established session. |
Connect the verified ingest to the rest of Callaba
Once one named publisher is stable, the same source can feed Recording, Restreaming, Multiview or a Web player. Keep access control at the ingest boundary and use separate downstream destination credentials. For example, a YouTube stream key belongs in the YouTube-bound Restream job—not in the OBS profile used by a guest publisher.
For UI steps, settings and validation signals, open the RTMP servers chapter of the Callaba user guide. Teams automating provisioning can use the RTMP Server API documentation after the first path is proven in the interface.
