SRT Caller, Listener, Ports, and Passphrases for IRL Streaming

The useful mental model

SRT problems often look mysterious because the words caller and listener sound like audio settings. They are connection roles. Haivision's current SRT connection modes documentation explains that SRT uses a handshake where devices identify as Caller or Listener, and in some cases use Rendezvous mode. The Caller initiates the connection. The Listener waits on a port.

For most IRL streamers using a cloud server, the field device is the caller and the cloud server is the listener. The phone, OBS machine, LiveU-style encoder, or backpack source starts the connection to the server's SRT URL. The server waits on the assigned UDP port. If those roles are reversed or the port is blocked, the stream will sit at connecting.

StreamableRun hides as much of this complexity as possible by giving you ingest details, but it still helps to understand the failure modes. When a source does not connect, check mode, host, port, stream ID if used, passphrase, latency, and whether the network allows UDP traffic.

Caller vs listener in plain language

Listener mode means the device opens a port and waits. Caller mode means the device dials a host and port. One side must call and the other must listen. Two callers do not connect because nobody is waiting. Two listeners do not connect because nobody starts the handshake.

The OBS SRT protocol streaming guide gives a practical example: if OBS receives from a server in listener mode, the connection is caller by default; if OBS receives directly from an encoder in caller mode, the OBS URL needs mode=listener. That same idea applies to IRL workflows. You are matching two halves of a handshake, not choosing a quality preset.

Rendezvous mode exists for some firewall cases, but it is not the first thing most streamers should reach for. If you have a managed cloud ingest, use the mode it provides. If you self-host, document exactly which side owns the open UDP port and which side starts the call.

• Caller: starts the SRT connection to a known host and port.
• Listener: waits for an SRT connection on a selected UDP port.
• Rendezvous: both peers negotiate in a more specialized peer-to-peer case.
• Common cloud workflow: phone or encoder is caller, cloud server is listener.
• Common local receive workflow: OBS may need listener mode if the encoder calls directly into it.

Ports are usually UDP, not a browser problem

SRT runs over UDP. That means a network can allow normal web browsing and still block the stream. Hotel Wi-Fi, campus Wi-Fi, corporate Wi-Fi, public venues, and some mobile hotspots can restrict UDP or unusual ports. The symptom can be confusing because the dashboard loads, chat works, and the app still cannot connect the SRT feed.

Do not debug this by changing five settings at once. First confirm the exact host and port. Then confirm the sender is caller and the server is listener, or whatever role your server expects. Then test from another network. If cellular works and venue Wi-Fi does not, the port or UDP path is likely the problem.

For self-hosted servers, open the specific UDP port at the cloud firewall, operating-system firewall, and any router or security group in front of it. For managed servers, use the assigned ingest port and avoid guessing.

• Check whether the SRT URL uses the expected host and port.
• Check whether the port is UDP, not only TCP.
• Check whether a venue network blocks unknown UDP traffic.
• Check whether a local firewall was changed since the last test.
• Check whether the same source connects from mobile data or another Wi-Fi network.
• Check whether a VPN changes the path enough to create new problems.

Passphrases protect the feed, but they are not full access control

The SRT protocol specification describes SRT as providing reliability and security optimized for low-latency live video over UDP, including encryption mechanisms. In practice, many tools expose this through a passphrase. That passphrase matters. Treat it like a contribution credential.

Do not paste passphrases into public chat, screenshots, OBS tutorials, or mod channels that do not need them. If a passphrase appears in a stream, clip, or public help request, rotate it. If you share an ingest URL with a collaborator, decide whether that person needs temporary access or a durable ingest.

Also remember what the passphrase does not do. It does not decide who can switch scenes, who can start destinations, who can read chat, or who can control OBS. That belongs in the server's account and permission model. Keep transport credentials and production permissions separate.

• Use a unique passphrase for a serious ingest when the tool supports it.
• Rotate it after accidental exposure.
• Do not store ingest URLs in public documents.
• Give collaborators their own named ingest where possible.
• Separate stream keys, SRT passphrases, dashboard permissions, and moderator controls.

Latency is a buffer budget, not just delay

SRT latency gives the receiver time to recover from packet loss and jitter. Lower latency feels better when the network is clean, but it gives the protocol less time to repair damage. Higher latency can make a mobile IRL feed more stable, but it delays interaction and can make chat reactions feel late.

For a moving IRL stream, set latency based on the route, not the ego of the number. A short indoor test can survive lower latency than a city walk, train station, convention floor, or driving route. If the stream drops or artifacts during movement, raising SRT latency can be a better first change than raising bitrate.

Keep a written profile for common route types. A studio-to-cloud OBS source on wired internet can use a tighter setting. A phone on one carrier in a crowded area needs more room. A bonded SRTLA setup may behave differently again. Test the setting viewers will actually see.

• Use lower latency for controlled wired contribution.
• Use more latency for cellular, Wi-Fi handoffs, and crowded venues.
• Lower bitrate before assuming latency is the only problem.
• Watch audio continuity, not only video sharpness.
• Do not change latency and bitrate at the same time during a diagnosis unless you document both.

How this maps to Moblin and IRL Pro

Moblin's listing describes SRTLA, SRT, RIST, RTMP, RTMPS, adaptive bitrate, and HEVC support. IRL Pro lists SRTLA bonding, on-the-fly bitrate adjustment, and streamer-focused controls. These apps are valuable because they give phone-first streamers contribution options that direct platform apps usually do not expose in the same way.

The setup path is to create the cloud ingest, copy the exact SRT or SRTLA details, paste them into the app, and test while the phone is on the network type you will use live. If the server expects caller mode from the app, do not make the app listen. If the URL includes a passphrase or stream ID, copy it exactly.

If the app connects but the picture is unstable, do not immediately rebuild the ingest. Check bitrate, resolution, latency, heat, battery, carrier, and whether adaptive bitrate is doing what you expect. Connection failure and quality failure are related but not identical.

• Connection failure: mode, host, port, passphrase, stream ID, or network block.
• Quality failure: bitrate, resolution, frame rate, encoder load, latency, signal, heat, or congestion.
• Reconnect failure: app state, timeout behavior, old session state, or a server-side stale connection.
• Operator failure: the team did not write down which setting changed last.

A calm troubleshooting order

When SRT fails, avoid random setting changes. Random fixes are hard to remember and harder to reverse. Use a fixed order so the team learns what the problem was.

Start with credentials and role. Confirm the URL, port, mode, passphrase, and stream ID. Then check network path by trying cellular, another Wi-Fi network, or a known-good test source. Then check application state by restarting the app or creating a new ingest if the server allows. Only after the connection is stable should you adjust quality settings.

For public shows, have a fallback scene ready before troubleshooting. The audience should not watch an operator debug SRT. Switch to clips, BRB, backup phone, or another source, then solve the ingest with less pressure.

• Step 1: verify the exact ingest URL and role.
• Step 2: verify UDP port access from the current network.
• Step 3: verify passphrase and stream ID if used.
• Step 4: test from a known-good source or network.
• Step 5: lower bitrate or resolution if connection succeeds but quality breaks.
• Step 6: document the final working profile before the next stream.

Other resources

These references explain SRT connection modes, protocol behavior, OBS receive/send patterns, and mobile app support for IRL contribution workflows.