This article briefly explains the difference between the NTRIP Client connection format style used in NTRIP Rev1 (version 1.0) and Rev2 (version 2.0) and provides examples.

Background

The creation of NTRIP Rev2 was largely motivated by the need to correct a few minor oversights in the original Rev1 standard. This included correcting the protocol details to adhere to emerging HTTP standards, and also adding greater log-on security for Base Stations. A number of new features were also added, but their adoption and deployment at this point remains very low. In fact the initial Rev1 version remains so popular today that among NTRIP Client devices, Rev1 users outnumber Rev2 users by about 25:1.

For those seeking the specific details of the either version, both standards are available from RTCM (here).  The formal names of the two documents are given below. It is most cost effective to purchase them as a set.

RTCM 10410.0 (RTCM Paper 200-2004/SC104-STD, Version 1.0), with Amendment 1,
Standard for Networked Transport of RTCM via Internet Protocol (Ntrip)

RTCM 10410.1 Standard for Networked Transport of RTCM via Internet Protocol (Ntrip)
Version 2.0 with Amendment 1, June 28, 2011

In this article we are concerned with how the rover device (the NTRIP Client) connects to the NTRIP Caster device. This information is valid for any Caster, not just the SNIP NTRIP Caster. Some similar changes were made for Base Station connections (NTRIP Servers), between Rev1 and Rev2, but are not covered here.

In an OSI layer context, the NTRIP protocol lives on top of the HTTP protocol, which in turn lives on top of the TCP/IP protocol. The purpose of the protocol is the allow the connecting client device to authenticate itself with the data provider (the Caster) and then to select a data stream. Once this initial process has occurred, the selected data stream is sent back to the device over the open socket. With the exception of additional periodic NMEA-183 $GGA sentences (used by NEAR streams to select the correct Base Station for each user), the NTRIP Client device sends nothing further. In this context, NTRIP is a simple and elegant publish/subscribe mechanism.

Note: In the examples that follow mountPt is the name for the Base Station or ‘stream’ that is being requested.  And user and password are used for the user password pair, which is in turn sent in a Base64 encoded format (i.e. user:password becomes dXNlcjpwYXNzd29yZA==).  All of these strings are case sensitive and generally limited to ASCII content without the use of white space. Consult the standard for further details regarding valid strings and allowed characters.  The <cr><lf> delimits the end of each line in the HTTP header.  A final line with only <cr><lf> serves to delimit the end of the header (not shown).

NTRIP Client Rev1 connections

Because NTRIP was originally based on HTTP and a protocol called Shoutcast (historic details), it uses the common GET verb to request the desired mountPt.

A minimal NTRIP Client Rev1 example with no user log on is:

GET /mountPt HTTP/1.0<cr><lf>
User-Agent: NTRIP theSoftware/theRevision<cr><lf>

A minimal NTRIP Client Rev1 example with a user log on is:

GET /mountPt HTTP/1.0<cr><lf>
User-Agent: NTRIP theSoftware/theRevision<cr><lf>
Authorization: dXNlcjpwYXNzd29yZA==<cr><lf>

When a request is accepted by the NTRIP Caster, the Caster replies with:

ICY 200 OK<cr><lf>

And thereafter binary content (typically RTCM 3.x messages) follows.  In case of any type of error the caster table is returned and the connection is dropped.

Details

After the GET keyword a single space is expected to be found, followed by “/” then the name of the requested data stream, another space, and then the HTTP revision.  As a rule, HTTP expects a single space (hex 0x20) as the delimiter, any additional white space may cause problems.

The keyword “User-Agent:” is used to convey two key concepts.  First that this is an NTRIP Caster (and not a browser or some other agent) and second what make/model of software is being used.  [Note: The term “Source-Agent:” was invented by NTRIP for Base Stations sending in data and is used in Rev1. It was deprecated in Rev2]

The keyword NTRIP is considered as case insensitive for historical reasons, although upper case is most common.

This keyword is followed by the model of NTRIP Client software being used. This most typically in the format of “Maker-Model/Revision”  without white space.  A typical list of recent Clients strings on a popular pubic caster can be found here  with typical NTRIP device strings.

The keyword “Authorization:” is used to send the user and password encoded in a common Base64 format, when present.

The simplest request consists  of only two or three lines in a common HTTP header form.  But the HTTP header can often contain additional meta information. In addition, if the HTTP 1.1 form is used some additional information is then required.  See rfc2616 for details.

Aside #1: The proper way to request the caster table is to by sending “/” after the GET verb.  And not by sending arbitrary strings such as “CasterTable” – which only works because the default behavior of the NTRIP Caster when an error is detected is to return the caster table and then disconnect.

Aside #2: When sending data to the Caster from a Base station using Rev1, the keyword “SOURCE” is used, in Rev2 this is replaced with “POST” along with other changes.

Aside #3: When sending NMEA-183 $GGA data to the Caster, the NTRIP Client should wait until the “ICY” reply has been received indicating that the connection is accepted.

NTRIP Client Rev2 connections

In Rev2 of NTRIP a few details were cleaned up in order to better follow HTTP.  Most of the Rev2 changes are found in the way an NTRIP Server (the Base Station) connects to the Caster.  In the SNIP Caster this is called a PUSH-In connection.

A minimal NTRIP Client Rev2 example with no user log on is:

GET /mountPt HTTP/1.1<cr><lf>
Host: theCaster.com:2101<cr><lf>
Ntrip-Version: Ntrip/2.0<cr><lf>
User-Agent: NTRIP theSoftware/theRevision<cr><lf>

A minimal NTRIP Client Rev2 example with a user log on is:

GET /mountPt HTTP/1.1<cr><lf>
Host: theCaster.com:2101<cr><lf> 
Ntrip-Version: Ntrip/2.0<cr><lf>
User-Agent: NTRIP theSoftware/theRevision<cr><lf>
Authorization: dXNlcjpwYXNzd29yZA==<cr><lf>

When a request is accepted by the NTRIP Caster, the Caster replies with at least:

HTTP/1.1 200 OK<cr><lf>

A more typical reply includes some additional header details like:

HTTP/1.1 200 OK<cr><lf>
Date: Wed, 11 November 2020 20:29:36 UTC<cr><lf>
Server: SubCarrier Systems Corp SNIP simpleNTRIP_Caster_[2.13.00]RwPRO<cr><lf>
Ntrip-Version: Ntrip/2.0<cr><lf>
Cache-Control: no-store, no-cache, max-age=0<cr><lf>
Pragma: no-cache<cr><lf>
Connection: close<cr><lf>
Content-Type: gnss/data<cr><lf>

And thereafter binary content (typically RTCM 3.x messages) follows.  In case of any type of error, a variety of other error replies are supported (aka HTTP 4xx messages) as well as returning the caster table to the requestor.

Details

The Rev2 format builds on the Rev 1 format as well as new meta information defined and found in HTTP 1.1. As before, the HTTP header can often contain additional meta information.  This is true for both the request and reply headers.

The two additional (and required) header lines contain the “Host:” and “Ntrip-Version:” meta information.

The meta keyword “Host:” coveys what specific server the host and port the request refers to.  In a machine where there is an IP address which is associated with one (and only one) NTRIP host this information is not required, but it is mandated by HTTP. In a shared host environment, or where a firewall or proxy is used, this information is essential to route the request to the correct host device.

The meta keyword “Ntrip-Version:” is invented by the NTRIP Rev2 specification and should follow the exact text above.  No other variations of the value text are defined at this time. The presence of this line indicates the use of NTRIP Rev2.

In the reply, note that the “ICY” (ICY = I can hear you) is replaced by an HTTP 200 OK  line, which also includes the version of HTTP used.

Several other meta keywords may optionally be present in the reply including a date stamp and details about the NTRIP Caster software.  Here “Server:” is used in a traditional web sense for the Caster, not the NTRIP meaning for an NTRIP Server (a Base Station).  The above example uses the reply from a SNIP Caster, other brands are similar.

Many devices do not support Rev2 connections. This is especially true on low cost devices. The popular open source library called RTKLIB (see: here here or here) can only connect with the Rev1 connection style.  A number of branched improvements and some commercial software based on it, including Emlid Reach, also do not implement Rev2 connections. Higher grade devices (Trimble, Leica, Hemisphere, TopCon, etc.) support both Rev2 and Rev1 and typically these devices default to using Rev2. Consult the specific owner’s manual for details.

In Rev2, NTRIP Client connections are intended to allow backwards “downward” compatibly with Rev1 connections. Therefore any NTRIP Client sending in a Rev2 request should also be designed to accept and cope with a Rev1 reply. This is not true for NTRIP Server connections.

The Rev2, the protocol requires the use of HTTP 1.1 and therefore requires the use of the host meta line (see rfc2616 for details).  An IP or URL name may be used here, and the port should be used as well (although the current RTCM standard is less clear about this detail, RFC2616 is not).

Final Remarks

Please do not use live Casters to test new NTRIP Client software. It is highly likely the Caster operator will block your IP for such use/abuse. The console log of the SNIP Caster provides a great deal of detail about various causes for incorrect NTRIP Client connections. Some developers simply download a Lite (free) copy of SNIP onto their own local machine for such testing.

Those developing products are strongly advised seek for the specific details of the either version from RTCM.

SNIP fully supports both Rev1 and Rev2 NTRIP connection styles for Clients, Casters, and Servers. The Lite (free) copy of SNIP is limited to the Rev 1 format only for some connections.  You can examine all the protocol exchange details in the console view by enabling various display options for each connection type.

 

See Also

The article on NTRIP Rev2 uses in SNIP which has further NTRIP Server connection details.