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.<\/p>\n
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.<\/p>\n
For those seeking the specific details of the either version, both standards are available from RTCM (here<\/a>).\u00a0 The formal names of the two documents are given below. It is most cost effective to purchase them as a set.<\/p>\n RTCM 10410.0 (RTCM Paper 200-2004\/SC104-STD, Version 1.0), with Amendment 1, RTCM 10410.1 Standard for Networked Transport of RTCM via Internet Protocol (Ntrip) In this article we are concerned with how the rover device (the NTRIP Client<\/a>) connects to the NTRIP Caster<\/a> device. This information is valid for any Caster, not just the SNIP<\/strong><\/span> NTRIP Caster. Some similar changes were made for Base Station connections (NTRIP Servers<\/a>), between Rev1 and Rev2, but are not covered here.<\/p>\n In an OSI layer context, the NTRIP protocol lives on top<\/em> of the HTTP protocol, which in turn lives on top<\/em> 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<\/a> sentences (used by NEAR streams<\/a> 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.<\/p>\n Note<\/strong><\/span>: In the examples that follow mountPt<\/em> is the name for the Base Station or \u2018stream\u2019 that is being requested.\u00a0 And user<\/em> and password<\/em> are used for the user password pair, which is in turn sent in a Base64 encoded format (i.e. user:password becomes dXNlcjpwYXNzd29yZA==).\u00a0 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.\u00a0 The <cr><lf> delimits the end of each line in the HTTP header.\u00a0 A final line with only <cr><lf> serves to delimit the end of the header (not shown).<\/p>\n Because NTRIP was originally based on HTTP and a protocol called Shoutcast (historic details<\/a>), it uses the common GET verb to request the desired mountPt.<\/p>\n A minimal NTRIP Client Rev1 example with no user log on is:<\/p>\n A minimal NTRIP Client Rev1 example with a user log on is:<\/p>\n When a request is accepted by the NTRIP Caster, the Caster replies with:<\/p>\n And thereafter binary content (typically RTCM 3.x<\/a> messages) follows.\u00a0 In case of any type of error the caster table is returned and the connection is dropped.<\/p>\n After the GET<\/strong> 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.\u00a0 As a rule, HTTP expects a single space (hex 0x20) as the delimiter, any additional white space may cause problems.<\/p>\n The keyword \u201cUser-Agent:<\/strong>\u201d is used to convey two key concepts.\u00a0 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.\u00a0 [Note<\/strong><\/em><\/span>: The term \u201cSource-Agent:\u201d was invented by NTRIP for Base Stations sending in data and is used in Rev1. It was deprecated in Rev2]<\/p>\n The keyword NTRIP is considered as case insensitive for historical reasons, although upper case is most common.<\/p>\n This keyword is followed by the model of NTRIP Client software being used. This most typically in the format of \u201cMaker-Model\/Revision\u201d\u00a0 without white space.\u00a0 A typical list of recent Clients strings on a popular pubic caster can be found here<\/a>\u00a0 with typical NTRIP device strings.<\/p>\n The keyword \u201cAuthorization:<\/strong>\u201d is used to send the user and password encoded in a common Base64 format, when present.<\/p>\n The simplest request consists\u00a0 of only two or three lines in a common HTTP header form.\u00a0 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.\u00a0 See rfc2616<\/a> for details.<\/p>\n Aside #1<\/strong><\/span>: The proper way to request the caster table is to by sending \u201c\/\u201d after the GET verb.\u00a0 And not by sending arbitrary strings such as \u201cCasterTable\u201d – 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.<\/p>\n Aside #2<\/strong><\/span>: When sending data to the Caster from a Base station using Rev1, the keyword \u201cSOURCE\u201d is used, in Rev2 this is replaced with \u201cPOST\u201d along with other changes.<\/p>\n Aside #3<\/strong><\/span>: 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.<\/p>\n In Rev2 of NTRIP a few details were cleaned up in order to better follow HTTP.\u00a0 Most of the Rev2 changes are found in the way an NTRIP Server (the Base Station) connects to the Caster.\u00a0 In the SNIP<\/strong><\/span> Caster this is called a PUSH-In<\/a> connection.<\/p>\n A minimal NTRIP Client Rev2 example with no user log on is:<\/p>\n A minimal NTRIP Client Rev2 example with a user log on is:<\/p>\n When a request is accepted by the NTRIP Caster, the Caster replies with at least:<\/p>\n A more typical reply includes some additional header details like:<\/p>\n And thereafter binary content (typically RTCM 3.x<\/a> messages) follows.\u00a0 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.<\/p>\n 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.\u00a0 This is true for both the request and reply headers.<\/p>\n The two additional (and required) header lines contain the “Host:<\/strong>” and “Ntrip-Version:<\/strong>” meta information.<\/p>\n The meta keyword “Host:<\/strong>” coveys what specific server the host and port the request refers to.\u00a0 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.<\/p>\n The meta keyword “Ntrip-Version:<\/strong>” is invented by the NTRIP Rev2 specification and should follow the exact text above.\u00a0 No other variations of the value text are defined at this time. The presence of this line indicates the use of NTRIP Rev2.<\/p>\n In the reply, note that the “ICY” (ICY = I can hear you) is replaced by an HTTP 200 OK\u00a0 line, which also includes the version of HTTP used.<\/p>\n Several other meta keywords may optionally be present in the reply including a date stamp and details about the NTRIP Caster software.\u00a0 Here “Server:<\/strong>” is used in a traditional web sense for the Caster, not the NTRIP meaning for an NTRIP Server (a Base Station).\u00a0 The above example uses the reply from a SNIP<\/strong><\/span> Caster, other brands are similar.<\/p>\n Many devices do not support Rev2 connections. This is especially true on low cost devices. The popular open source library called RTKLIB<\/strong> (see: here<\/a> here<\/a> or here<\/a>) can only<\/strong> connect with the Rev1 connection style.\u00a0 A number of branched improvements and some commercial software based on it, including Emlid Reach<\/a>, also do not implement Rev2 connections. Higher grade devices (Trimble<\/a>, Leica<\/a>, Hemisphere<\/a>, TopCon<\/a>, etc.) support both Rev2 and Rev1 and typically these devices default to using Rev2. Consult the specific owner\u2019s manual for details.<\/p>\n In Rev2, NTRIP Client connections are intended to allow backwards \u201cdownward\u201d 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.<\/p>\n The Rev2, the protocol requires the use of HTTP 1.1 and therefore requires the use of the host meta line (see rfc2616<\/a> for details).\u00a0 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).<\/p>\n 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<\/strong><\/span> Caster provides a great deal of detail about various causes for incorrect NTRIP Client connections. Some developers simply download a Lite<\/strong><\/em><\/span> (free) copy of SNIP<\/strong><\/span> onto their own local machine for such testing.<\/p>\n Those developing products are strongly advised seek for the specific details of the either version from RTCM.<\/a><\/p>\n SNIP<\/strong><\/span> fully supports both Rev1 and Rev2 NTRIP connection styles for Clients<\/em>, Casters<\/em>, and Servers<\/em>. The Lite<\/strong><\/em><\/span> (free) copy of SNIP<\/strong><\/span> is limited to the Rev 1 format only for some connections.\u00a0 You can examine all the protocol exchange details in the console view by enabling various display options for each connection type.<\/p>\n <\/p>\n
\nStandard for Networked Transport of RTCM via Internet Protocol (Ntrip)<\/p>\n
\nVersion 2.0 with Amendment 1, June 28, 2011<\/p>\nNTRIP Client Rev1 connections<\/h2>\n
GET \/mountPt HTTP\/1.0<cr><lf>\r\nUser-Agent: NTRIP theSoftware\/theRevision<cr><lf><\/pre>\n
GET \/mountPt HTTP\/1.0<cr><lf>\r\nUser-Agent: NTRIP theSoftware\/theRevision<cr><lf>\r\nAuthorization: dXNlcjpwYXNzd29yZA==<cr><lf><\/pre>\n
ICY 200 OK<cr><lf><\/pre>\n
Details<\/h3>\n
NTRIP Client Rev2 connections<\/h2>\n
GET \/mountPt HTTP\/1.1<cr><lf>\r\nHost: theCaster.com:2101<cr><lf>\r\nNtrip-Version: Ntrip\/2.0<cr><lf>\r\nUser-Agent: NTRIP theSoftware\/theRevision<cr><lf><\/pre>\n
GET \/mountPt HTTP\/1.1<cr><lf>\r\nHost: theCaster.com:2101<cr><lf> \r\nNtrip-Version: Ntrip\/2.0<cr><lf>\r\nUser-Agent: NTRIP theSoftware\/theRevision<cr><lf>\r\nAuthorization: dXNlcjpwYXNzd29yZA==<cr><lf><\/pre>\n
HTTP\/1.1 200 OK<cr><lf><\/pre>\n
HTTP\/1.1 200 OK<cr><lf>\r\nDate: Wed, 11 November 2020 20:29:36 UTC<cr><lf>\r\nServer: SubCarrier Systems Corp SNIP simpleNTRIP_Caster_[2.13.00]RwPRO<cr><lf>\r\nNtrip-Version: Ntrip\/2.0<cr><lf>\r\nCache-Control: no-store, no-cache, max-age=0<cr><lf>\r\nPragma: no-cache<cr><lf>\r\nConnection: close<cr><lf>\r\nContent-Type: gnss\/data<cr><lf><\/pre>\n
Details<\/h3>\n
Final Remarks<\/h2>\n
See Also<\/h3>\n