NTRIP connection flow explained

NTRIP (Networked Transport of RTCM via Internet Protocol) streams GNSS data, such as RTCM corrections, over the internet. A rover or app connects to a caster and requests a stream identified by a mountpoint. This guide walks through the NTRIP connection flow at the protocol level: the requests and responses, how NTRIP v1 and v2 differ, what the sourcetable fields mean, and when the client must send its position.

NTRIP was purpose-built for land surveying - connecting a rover in the field to a network of permanent reference stations over cellular, without radio range limits.

Introduction to NTRIP protocol

The NTRIP documentation from BKG describes four components. The BKG document writes their names as single words, shown in parentheses:

• Source (NtripSource): the GNSS data source, usually a reference station.
• Server (NtripServer): software that sends the source's data to a caster.
• Caster (NtripCaster): the server that lists the available streams and forwards them to clients.
• Client (NtripClient): the rover, field app or software that requests a stream.

Each stream on a caster has a name, called a mountpoint. To connect, the client needs the caster's host and port, a mountpoint, compatible protocol settings and any required credentials. The same flow applies whether the client is a rover for land surveying, a drone mapping workflow or a precision agriculture guidance system. For a beginner's overview of how corrections reach a receiver, see our guide to what NTRIP is.

Connection flow in NTRIP: client, caster, mountpoint

1. Open a TCP connection to the caster's host and port. Port 2101 is registered with IANA for RTCM SC-104 and is the usual NTRIP port.
2. Optionally fetch the sourcetable by requesting /. The caster returns the list of streams and their properties.
3. Request a mountpoint with a GET for /MOUNTPOINT, including an Authorization header if the stream needs credentials. Check the reply before treating the data as corrections: a caster may answer with its sourcetable instead of a stream.
4. Send an NMEA GGA sentence if the mountpoint requires the client's position. Repeat it at the interval specified by the service.
5. Read the RTCM stream and pass it to the receiver.
6. Watch the link. If a configured data-gap timeout expires, close the connection and reconnect with backoff.

# Fetch the sourcetable (v1)
GET / HTTP/1.0
User-Agent: NTRIP my-rover/1.0

# Response
SOURCETABLE 200 OK
Content-Type: text/plain
...
STR;...
ENDSOURCETABLE

# Request a mountpoint (v1)
GET /MY_MOUNT HTTP/1.0
User-Agent: NTRIP my-rover/1.0
Authorization: Basic <base64 of user:password>

# Response, followed by the binary RTCM stream
ICY 200 OK

In NTRIP v1 the User-Agent header must begin with the string NTRIP, as the BKG documentation specifies.

NTRIP v1 vs v2: handshake & headers

NTRIP v1 uses non-standard response lines associated with internet streaming. A successful sourcetable request returns SOURCETABLE 200 OK, and a successful stream request returns ICY 200 OK. Neither is a standard HTTP status line, which is why strict HTTP libraries reject them.

RTCM completed NTRIP version 2.0 in 2009. According to BKG's summary, it fixed the HTTP protocol violations, added chunked transfer encoding, improved the header records, added sourcetable filtering and allowed RTSP communication. BKG describes v2 as downward compatible with v1; check which version the caster actually returns. A v2 client identifies itself with the Ntrip-Version header:

GET /MY_MOUNT HTTP/1.1
Host: caster.example.com
Ntrip-Version: Ntrip/2.0
User-Agent: NTRIP my-rover/2.0
Authorization: Basic <base64 of user:password>
Connection: close

# Response, followed by the RTCM stream
HTTP/1.1 200 OK
Content-Type: gnss/data

A v2 caster marks a stream with Content-Type: gnss/data and a sourcetable with gnss/sourcetable, as BKG's own NTRIP client library checks. RTKdata's caster, for example, answers a v2 sourcetable request with HTTP/1.1 200 OK and Content-Type: gnss/sourcetable, and echoes Ntrip-Version: Ntrip/2.0 in its reply. NTRIP v2 supports chunked transfer encoding. When a response uses it, the HTTP chunk framing must be removed before passing RTCM bytes to the receiver. Your HTTP library may already do this: libcurl decodes chunked responses by default.

libcurl and ICY 200 OK: using CURLOPT_HTTP200ALIASES

Since curl 7.66.0, libcurl rejects HTTP/0.9 responses by default. A reply line that does not start with HTTP/ is treated as HTTP/0.9, so an NTRIP v1 ICY 200 OK reply fails with the error Received HTTP/0.9 when not allowed. The CURLOPT_HTTP200ALIASES option fixes this by registering ICY 200 OK as an alias for a valid 200 status line. Allowing HTTP/0.9 instead is not a fix, because libcurl would then treat the whole reply as data. The curl documentation uses exactly this string in its own example:

struct curl_slist *aliases = NULL;
aliases = curl_slist_append(aliases, "ICY 200 OK");
curl_easy_setopt(curl, CURLOPT_HTTP200ALIASES, aliases);
/* ... perform the request ... */
curl_slist_free_all(aliases);

The option has been available since curl 7.10.3. The alternative is an NTRIP v2 request with Ntrip-Version: Ntrip/2.0, if the caster supports v2. Keep the aliases list allocated until the transfer completes. The alias only fixes the status line: your client still has to send GGA where required, and some casters send RTCM bytes straight after the ICY 200 OK line, which a header-parsing library may not accept. Test the full exchange with your client and caster.

Sourcetable fields explained (STR/CAS/NET)

The sourcetable is a plain-text list. Lines starting with CAS describe casters, NET describes networks, and STR describes streams. For choosing a mountpoint, the STR records matter. BKG lists the following fields. Positions below count STR as field 1. The example has 19 fields, but the format permits additional fields before the final miscellaneous field:

1. STR
2. mountpoint
3. identifier, such as the nearest city
4. format, such as RTCM 3.2
5. format details: message types with update periods in seconds
6. carrier: 0 no carrier phase, 1 L1, 2 L1 and L2
7. navigation systems, such as GPS+GLO+GAL
8. network
9. country code
10. latitude
11. longitude
12. NMEA: 1 means the client must send GGA
13. solution: 0 single base, 1 network
14. generator
15. compression or encryption
16. authentication: N none, B Basic, D Digest
17. fee: Y or N
18. bitrate in bits per second
19. miscellaneous (last field; position 19 in this example)

STR;MY_MOUNT;Berlin;RTCM 3.2;1005(10),1077(1),1087(1),1097(1);2;GPS+GLO+GAL;MY-NET;DEU;52.52;13.41;1;0;MyCaster;none;B;N;9600;

This illustrative record advertises GPS, GLONASS and Galileo observations. The legacy carrier field uses the L1/L2 terminology defined in the BKG table; it does not identify each constellation's actual signal bands. Galileo uses names such as E1 and E5. The advertised stream requires GGA (NMEA=1), is generated from a single base (solution=0) and uses Basic authentication (B). The message periods and bitrate are demonstration values. RTKdata's own AUTO entry uses the same layout, with NMEA 1, solution 0 and Basic authentication.

A client can request a known mountpoint directly without first downloading the sourcetable. With RTKdata you type the mountpoint directly: AUTO in capitals, or AUTO_WGS84, AUTO_ITRF2020 or AUTO_ITRF2014 if your project needs that reference frame, as our connection guide explains.

NMEA-GGA for VRS/NEAR mountpoints

Some streams need to know where the client is. BKG's documentation explains that the caster can use the client's approximate position to generate a virtual reference station (VRS) stream or to choose the best stream, such as the nearest base. A mountpoint's name does not tell you how the service generates its corrections. RTKdata documents AUTO as nearest-base selection. When a mountpoint's NMEA field is 1, the caster must receive at least one NMEA GGA sentence before it can prepare and start the stream. Follow the service's requirements for subsequent position updates.

An NMEA GGA sentence includes a checksum: the XOR of the character bytes between $ and *, written as two hexadecimal digits. Latitude and longitude use degrees and decimal minutes. A wrong checksum can make a caster ignore the position. This example uses the same Berlin position as the sourcetable example above, 52.52° N and 13.41° E, and has a valid checksum. Its time, fix quality, satellite count, HDOP, height and geoid separation are invented demonstration values, not surveyed Berlin measurements. In practice, send your receiver's current GGA, ending with CRLF:

$GPGGA,123519,5231.2000,N,01324.6000,E,1,12,0.8,45.4,M,0.0,M,,*44

RTKdata's documented AUTO service requires GGA. Its AUTO mountpoint uses the position to select the nearest base station, and without GGA the caster sends no corrections. Our troubleshooting guide recommends a GGA interval of 1 second where the device allows it.

Authentication & security (Basic Auth & TLS/ports)

• Basic authentication is supported by NTRIP. The client sends Authorization: Basic followed by the Base64 encoding of user:password. Base64 is an encoding, not encryption. RFC 7617 explains that Basic authentication needs external protection such as TLS to protect credentials in transit.
• Digest authentication is also defined. It uses a challenge-response exchange instead of transmitting the password in clear text; it does not encrypt the correction stream.
• TLS: use HTTPS where the caster offers a TLS endpoint and the client supports it. BKG's NTRIP client library accepts HTTPS URLs. Verify the server certificate when using TLS.
• Ports: 2101 is the registered and usual NTRIP port, but providers can configure a different listening port. If outbound TCP to that endpoint is blocked, the client cannot establish the connection.

RTKdata's connection reference lists port 2101 and regional IP fallback addresses for devices with hostname-resolution problems.

Timeouts & reconnection best practices

The following are implementation suggestions. Choose timeout and retry settings for the caster, client and network you use:

• Connect timeout: choose a limit that allows for the connection delays on your network, and test it under weak mobile coverage.
• Idle timeout: choose a data-gap limit based on the expected stream cadence and network delays. Monitor required RTCM messages separately; incoming bytes alone do not establish that every required message is current.
• Reconnect with backoff: increase the wait between attempts, for example 5, 10, 20 and 40 seconds, and add random jitter so many rovers do not reconnect at once.
• Monitor correction latency: RTKdata's accuracy guidance recommends low latency and describes increasing degradation as delays grow. Its time ranges are service guidance, not universal receiver cutoffs or an accuracy guarantee. Also check the receiver's correction-age and solution-status indicators.
• Log every reconnect with its reason, so you can tune the values from real data.

Troubleshooting and recommended setup

If you're still hitting connection failures after reviewing the flow above, our step-by-step RTK troubleshooting guide covers every common NTRIP failure mode.

Use these checks to locate a failure in the NTRIP connection flow or receiver setup:

• Login fails: check the credentials. RTKdata's NTRIP username starts with rtk and differs from your website login.
• Stream not found: BKG's v1 documentation describes returning a sourcetable for an unavailable mountpoint, and RTKdata's caster also returns it when a request has no valid credentials. A sourcetable where you expected corrections usually means a wrong mountpoint name or missing credentials. Mountpoint names are case-sensitive. auto or Auto will not work where AUTO is expected.
• Connected, but no corrections: make sure GGA is enabled and the device has a satellite fix. Use a clear sky view and confirm a valid receiver position. A high satellite count alone does not guarantee an RTK fix.
• Library error on the response: an error such as Received HTTP/0.9 when not allowed means the library rejected ICY 200 OK. Allow it as a status line or switch to v2, as described above.
• Hostname cannot be resolved: for RTKdata, use the current IP fallback listed in its connection reference for your region.
• Connection times out: check that outbound TCP on port 2101 is not blocked by a firewall or VPN.
• Corrections arrive but no FIX: check that the stream's messages and signals suit your receiver. Allow the receiver time to converge according to its documentation. If the receiver stays in FLOAT, investigate rather than waiting longer.

Recommended setup

Use a stream appropriate to your receiver, location and reference frame, check the NMEA and authentication fields before connecting, send valid GGA when required, reconnect with backoff and log every reconnect.

Developer cheat sheet

• v1: GET /MOUNT HTTP/1.0, User-Agent starting with NTRIP, on success, expect ICY 200 OK; check the remaining framing before extracting RTCM.
• v2: add Ntrip-Version: Ntrip/2.0, on a successful v2 response, expect HTTP/1.1 200 OK with Content-Type: gnss/data (gnss/sourcetable for the list), and handle chunked transfer encoding.
• libcurl and v1: set CURLOPT_HTTP200ALIASES to include ICY 200 OK.
• Sourcetable: NMEA is field 12 and solution is field 13 of an STR record.
• GGA: send it when NMEA is 1, with a valid checksum. Follow the service's required update interval.
• Reconnect: exponential backoff with jitter, and log the reason each time.

Reliable RTK link with RTKdata

RTKdata's quick-start guide lists the settings:

• Host: eu.rtkdata.com for Europe, rtk.rtkdata.com for North America or aus.rtkdata.com for Australia.
• Port: 2101.
• Mountpoint: AUTO, in capitals.
• Credentials: the NTRIP username and password from your dashboard.
• GGA: turned on.