OBS
RTMP / SRTLet the platform own routing, conversion, and fan-out so the source encoder can focus on sending one clean contribution feed.
Delivery
Live multistreaming platform
Bring one verified contribution feed into Callaba, then create a separate Restream job for each destination. Each job has its own destination settings and runtime state; recording, Web Player, and recovery are separate workflows you add when needed.
Deploy Callaba on AWSTurn one ingest into many outputs
Accept the contribution feed once, then create a separate Restream job for every social platform, partner endpoint, or other destination.
Each Restream job has its own destination settings and runtime state. Review every output independently so each destination has its own clear operating evidence.
YouTube
RTMP · Separate output job 01
RTMP · Separate output job 02
Interactive workflow model · example statesOnly this destination changes; the other two continue running.The accepted input remains shared while each destination reports its own operating state.
Workflow
Keep your destination logic under control
Treat every outlet as an independent delivery contract, even when all of them begin with the same source.
Turn one ingest into many outputs
Create one output job per endpoint so credentials, limits, and failures stay isolated.
Prepare routes deliberately
Keep alternate endpoints documented and tested before they are needed during a live programme.
Add recording or playback as separate workflows
Attach recording or browser playback to the accepted feed as separate jobs with separate checks.
Continue in the product
Set it up in Callaba. Then check the full path.
You have seen what the product does. These three guides take you into the exact controls, show what to connect next, and give you a practical check before the workflow goes live.
Technical specification
Can I route one source to multiple destinations?
Use this contract to confirm what is shared at ingest and what must be proven for each output.
| Capability | Supported behavior | Acceptance check |
|---|---|---|
| Turn one ingest into many outputs | One verified contribution feed can supply multiple independently configured Restream jobs. | Confirm the input once, then watch every destination job establish its own live state. |
| Keep your destination logic under control | Endpoint URL, credentials, media expectations, and retry behavior belong to the individual output job. | Open each job separately and verify its live state against the intended destination. |
| Move the heavy work off the encoder | The source encoder publishes one clean contribution feed while Callaba performs downstream fan-out. | Compare encoder upload with the state of every created output rather than multiplying source publishes. |
| Use routing flexibility across destinations | Choose cloud for a quick workflow test or self-hosted infrastructure when network and data-location control are required. | Run the real source and endpoints in the chosen environment before relying on the route for production. |
Workflow
Choose cloud or self-hosted from the operating need
Use cloud to validate a real source and destination quickly. Choose self-hosted when you need infrastructure, network, or data-location control, then revalidate the workflow after deployment.
Deploy Callaba on AWS
Start a cloud deployment to prove one input and several independent outputs with real destinations. AWS instance time, network egress, destination requirements, and optional storage are planned separately.
Deploy Callaba on AWSInstall Callaba self-hosted
Use one contribution input for several business destinations, with explicit destination settings for each platform or partner endpoint.
Install Callaba self-hostedAPI
Multi-streaming REST APIAutomate independent output jobs after the route works
Each destination is its own Restream job. Use the API to create, start, and inspect jobs after your team has validated the source, destination, and media profile in Callaba.
Frequently Asked Questions
What does “ingest and route” mean here?
It means you accept one live input into a managed ingress point, then decide how that signal should move next: to social platforms, partner endpoints, players, or other workflow modules.
When do teams choose this instead of publishing directly from OBS?
Teams usually choose it when one source has to feed multiple destinations, when backup paths matter, or when routing logic should live in a managed workflow instead of inside the encoder setup.
Can I route one source to multiple destinations?
Yes. Callaba accepts the source once, and you create one independent Restream job for each destination. Configure and inspect every job separately.
Do I need more upload bandwidth for each destination?
Not from the encoder side if the workflow is built correctly. The source can usually send one managed contribution stream while the platform handles the downstream fan-out.
Can I use SRT as the contribution input?
Yes. SRT is a common ingest choice when network conditions, contribution quality, or controlled receiving infrastructure matter.
Is this API-first or dashboard-first?
Start in the control interface to validate the source, destination, and profile. Then use the API to create, start, and inspect each independent Restream job.
Where should I start in the docs?
Start with SRT servers if the first question is where the signal enters, then continue to SRT routes and Restreams to define how it moves.
Delivery
Use routing flexibility across destinations
Validate one source with the destinations that matter now, then add separate recording or playback jobs when required.