Every SRT protocol reject code, in plain English — and what to actually do about each one

Your SRT connection failed and you got a number. Maybe SRT_REJ_BADSECRET, maybe just 10, maybe a log line that says rejected and nothing more. The number is documented — it lives in the libsrt repository, written for people implementing the protocol. What it does not tell you is which knob to turn.

This is the whole list, with what each code actually means on a live link and what to do about it. Every official description below is quoted verbatim from the libsrt documentation; everything in the "what to do" column is a practitioner reading, and I say so where the mapping is a judgement call rather than a fact.

Where you see these codes

A rejection is not a network failure. The two ends found each other, exchanged handshakes, and one of them said no. That distinction matters: if you are getting a reject code, your packets are arriving. Firewall and routing problems usually look like a timeout instead.

The code surfaces in three places: srt_getrejectreason() in the API, the log line on the socket that failed, and whatever your application chooses to show you. Caller and listener do not always see the same code — the side that rejects knows why, and the side that got rejected may only learn that something refused it.

The internal codes: 0–17

These come from the protocol itself. They are the ones you will meet in normal operation.

Code	Name	Official description	What to do
0	SRT_REJ_UNKNOWN	"Fallback value for cases when there was no connection rejected."	Nothing was rejected. If you are seeing this after a failure, the failure was something else — look at timeouts and routing.
1	SRT_REJ_SYSTEM	"One system function reported a failure. Usually this means some system error or lack of system resources."	The host, not the link. File descriptors, memory, socket limits. Check the system log on the rejecting side.
2	SRT_REJ_PEER	"The connection has been rejected by the peer, but no further details are available."	The other end refused and told you nothing. The real reason is in their log. If you don't control that end, this is where you make a phone call.
3	SRT_REJ_RESOURCE	"A problem with resource allocation (usually memory)."	Memory pressure on the rejecting side. On a phone or tablet this often means too many simultaneous streams for the device.
4	SRT_REJ_ROGUE	"The data sent by one party to another cannot be properly interpreted."	What arrived wasn't a valid SRT handshake. Most often something non-SRT is hitting the port, or one side is talking a very different protocol version. Worth checking you're not pointing at an RTMP or plain UDP endpoint.
5	SRT_REJ_BACKLOG	"The listener's backlog has exceeded its queue limit."	The listener is full. Either too many callers at once, or stale connections that never closed. Raising the backlog hides it; finding what isn't disconnecting fixes it.
6	SRT_REJ_IPE	"Internal Program Error. This should not happen during normal usage."	A bug in the implementation, not your configuration. Worth reporting upstream with the version and a reproduction.
7	SRT_REJ_CLOSE	"The listener socket was able to receive the request, but is currently being closed."	You connected during a shutdown. Retry. If it persists, the far end is restarting in a loop.
8	SRT_REJ_VERSION	"One party has set up a minimum version that is required, but the other party doesn't satisfy it."	Someone set SRTO_MINVERSION. Check the libsrt version on both ends — a modern encoder talking to old hardware is the usual shape of this.
9	SRT_REJ_RDVCOOKIE	"Rendezvous cookie collision."	Only happens in rendezvous mode. It is a genuine collision and retrying normally clears it. If it repeats, both sides may be misconfigured into rendezvous when one should be a listener.
10	SRT_REJ_BADSECRET	"Both parties have defined a passphrase for a connection, but they differ."	The passphrases don't match. Check for trailing whitespace, smart quotes from a copy-paste, and length — the passphrase must be minimum 10 and maximum 80 characters.
11	SRT_REJ_UNSECURE	"Only one connection party has set up a password."	One side is encrypted, the other isn't. Either both set a passphrase or neither does. This one catches people who added encryption at the sender and forgot the receiver.
12	SRT_REJ_MESSAGEAPI	"The value of the SRTO_MESSAGEAPI flag is different on both parties."	Message mode versus buffer mode mismatch. For live video both ends should be in message mode.
13	SRT_REJ_CONGESTION	"The SRTO_CONGESTION option has been set up differently on both parties."	One side is set to live and the other to file. For streaming, both should be live.
14	SRT_REJ_FILTER	"The SRTO_PACKETFILTER option has been set differently on both parties."	Usually FEC. If one end enables a packet filter, the other must agree on the same configuration.
15	SRT_REJ_GROUP	"The group type or some group settings are incompatible between parties."	Connection bonding. Both ends must agree on the group type — broadcast, backup or balancing.
16	SRT_REJ_TIMEOUT	"The connection wasn't rejected, but it timed out."	Nobody said no; nobody said anything. This is the firewall, NAT and routing case — and the one code in this table that usually means the problem is not in either application's settings.
17	SRT_REJ_CRYPTO	"Connection rejected due to a mismatch in crypto modes."	Both sides have encryption but disagree on the mode. Distinct from code 10 — the passphrase may be identical and this still fails.

The four you will actually meet

In practice the internal codes cluster hard. Over a working life of setting these links up, four account for most of them.

The extended codes: 1000–1999

These are a different animal. They are set by the application on top of SRT, not by the protocol, and they exist so a server can explain itself when it rejects a connection based on the StreamID. The numbering is deliberately HTTP-shaped, which makes them easy to read if you already know HTTP status codes.

Code	Name	Official description
1000	SRT_REJX_FALLBACK	"Callback handler has interrupted an incoming connection."
1001	SRT_REJX_KEY_NOTSUP	"Key specified in StreamID string not supported by application."
1002	SRT_REJX_FILEPATH	"Resource type designates file where path has wrong syntax or is not found."
1003	SRT_REJX_HOSTNOTFOUND	"The host specified in the h key cannot be identified."
1400	SRT_REJX_BAD_REQUEST	"General syntax error."
1401	SRT_REJX_UNAUTHORIZED	"Authentication failed; client unauthorized to access the resource."
1402	SRT_REJX_OVERLOAD	"Server load too heavy to process request, or credit limit exceeded."
1403	SRT_REJX_FORBIDDEN	"Access denied to the resource for any reason."
1404	SRT_REJX_NOTFOUND	"Resource specified by r and h keys cannot be found."
1405	SRT_REJX_BAD_MODE	"Mode specified in the m key in StreamID is not supported."
1406	SRT_REJX_UNACCEPTABLE	"Unavailable parameters in StreamID, or m=publish data format unsupported."
1409	SRT_REJX_CONFLICT	"Resource specified by r and h keys is locked for modification."
1415	SRT_REJX_NOTSUP_MEDIA	"Media type not supported by the application."
1423	SRT_REJX_LOCKED	"Resource is locked against any access."
1424	SRT_REJX_FAILED_DEPEND	"Dependent entity for the request is not present."
1500	SRT_REJX_ISE	"Internal server error."
1501	SRT_REJX_UNIMPLEMENTED	"Request not supported by current version of the service."
1502	SRT_REJX_GW	"Target endpoint rejected connection from gateway server."
1503	SRT_REJX_DOWN	"Service is down for maintenance."
1505	SRT_REJX_VERSION	"SRT application version not supported."
1507	SRT_REJX_NOROOM	"Data stream cannot be archived due to lack of storage space."

If you are getting one of these, the fix is almost always in the StreamID string you are sending, or in an account setting at the far end. A 1401 is a credential problem. A 1404 means the resource path is wrong. A 1403 means your credentials worked and you still aren't allowed in — which is a different conversation with your provider than a 1401.

User-defined codes: 2000–2999

This range is left free for applications to define. A vendor might use 2005 to mean "licence expired". There is no central registry, so a code in this range means nothing until you check that specific vendor's documentation. If you see one, the number alone will not help you — the vendor's notes will.

What none of these tell you

A reject code explains why a connection was refused. It says nothing about a connection that succeeded and is performing badly. Packet loss, retransmission, round-trip time and dropped frames are a different diagnostic problem entirely, and no reject code will ever surface them — by the time you have loss statistics, the handshake already worked.

We build SRT tools for broadcast and AV work, and this list is the same reference our apps use internally when they translate a failure into something readable. Pay once, no subscription.

Source: the rejection code tables in the libsrt documentation. Official descriptions are quoted verbatim; the guidance is ours. Corrections welcome — if something here is wrong, we would rather fix it than leave it.