Start with the receiver: use the protocol its ingest contract accepts. Choose SRT when your team controls a compatible contribution receiver; choose RTMP or RTMPS when the next receiver is a platform that requires it. The useful decision is not which protocol wins in general. It is who owns the next receiver, what its contract requires, and whether the network can sustain the handoff.
Callaba begins at a supported video handoff. Callaba SRT Server receives a configured SRT contribution feed with explicit connection rules and live transport telemetry. Callaba RTMP Server is the corresponding receiving boundary for configured RTMP publishers and receivers. Neither product makes an external platform, encoder, or viewer delivery path Callaba-owned.
- Name the next receiver
A platform may publish an RTMP(S) ingest contract. A receiver your team operates can be configured for a compatible SRT role. - Match the contribution handoff
Use the receiver's accepted transport, then agree the media profile, address, access setting, and network path with the source owner. - Verify the next owner
A Callaba module, decoder, recording job, or external platform independently proves it accepted the feed.
This ordered flow remains one readable sequence at narrow widths. A connected transport session is useful evidence, but it does not prove the next decoder, platform, player, or audience experience.
Start with the receiver, then choose the handoff
If the receiver is an external platform
Follow its current RTMP(S) ingest contract. Use RTMPS when the platform offers it and the encoder supports it. The destination still owns its stream key, supported profile, and acceptance test.
If your team controls a compatible contribution receiver
SRT fits a point-to-point handoff such as venue-to-cloud, field-to-studio, or partner-to-control-room when both endpoints support the agreed role and the team can plan UDP reachability, latency, and monitoring.
Many live paths use both: SRT across the contribution leg, then RTMP(S) only at the platform-facing handoff. That is an architecture choice, not a conversion promise. Every handoff still needs its own source and destination acceptance check.
What changes operationally
Network behavior and recovery
SRT runs over UDP and uses a timed receive buffer and retransmission mechanisms to work through loss, jitter, and bandwidth variation. Recovery needs latency budget: set it too aggressively and a late packet cannot help; set it without regard to the path and contribution delay grows. Transport latency is only one part of total delay.
For a direct RTMP(S) publishing workflow, follow the receiver's current ingest contract. Test the real uplink, firewall path, encoder buffering, and receiver—not a clean local connection.
Security and access are separate choices
SRT can encrypt its media payload when both sides are configured to do so. RTMPS is RTMP carried over TLS. Neither replaces access rules, key handling, firewall policy, stream-key hygiene, or destination-side permissions.
In Callaba, SRT can assign publisher, receiver, or paired access with role-specific stream IDs or fixed peer-IP rules, and show active-session bitrate, loss, RTT, duration, peer IP, and event state. RTMP can use publisher and receiver stream-key or IP rules, or a deliberately configured guest-key workflow, and show publisher/receiver activity, bitrate, region, and peer IP. These are operator controls and observations, not a claim that an upstream network or external destination is healthy.
Compatibility decides
An SRT sender needs a compatible receiver role, port, stream ID where used, passphrase where used, latency, firewall policy, and media profile. An RTMP(S) sender needs the destination's current address, stream key, and supported encoder profile. YouTube currently documents RTMPS as an ingest option; that is a destination-specific fact, not proof that every platform accepts RTMPS or SRT.
One scenario: a venue feed that ends at an RTMPS-only platform
A venue sends a programme feed over a variable uplink. The platform provides an RTMPS URL and stream key, but the team chooses a separately controlled SRT contribution handoff first.
- Receiver decision: record the platform's RTMPS ingest contract and its responsible operator.
- Contribution decision: configure the venue encoder as the agreed SRT publisher, then record the role, address, UDP port, latency, access setting, and network owner.
- Callaba boundary: create the SRT Server access rule and confirm the expected peer, bitrate, RTT, packet loss, duration, and event state.
- Next job: configure the reviewed routing or restreaming path. The protocol bridge, media processing, and destination credential are separate decisions; an active SRT session does not prove the platform has video.
- Platform check: validate its ingest indicator and preview, then test a controlled reconnect before the event.
If the SRT session is absent, investigate the source, role, UDP path, or access rule. If it is healthy but the platform is not, investigate the output, credential, codec/container, or platform requirement. Change one layer at a time.
Choose with a short preflight
- Who owns the receiver? A team-controlled compatible receiver makes SRT a candidate. A platform naming RTMP(S) sets that handoff.
- What is the network actually like? Measure RTT, loss, jitter, usable uplink, and UDP reachability at the event location.
- What must recover? Define the exact reconnect, source switch, encoder restart, or platform re-authentication test.
- Where does encryption stop? Match SRT encryption settings or the destination's RTMPS requirement, then protect the access rule or stream key separately.
- What proves success? Check source-side transport data and the next receiver; viewer playback is another check.
Where Callaba fits—and where it does not
Use Callaba when work begins with an accepted SRT or RTMP contribution feed and the team needs an explicit access boundary plus live operational evidence. From there, choose only a reviewed next module: Multiview, recording, or a routing/restreaming path.
Callaba does not make an unsupported encoder compatible, open a blocked network, provide the platform's stream key, replace a CDN or switcher, or guarantee end-to-end delivery. The source device, network, external platform, decoder, player, and audience path remain separate owners.
Protocol references for the implementation team
- SRT documentation — encryption and recovery context.
- SRT latency documentation — transport delay versus the complete live path.
- YouTube RTMPS guidance — destination-specific RTMPS example.
- OBS SRT guide — role and latency context.
Next steps
Open the setup path that matches the receiver you control. Confirm its connection rule and active-session evidence before configuring the next module or platform handoff.
