Changes

[[Category:Software]]

[[Category:Software]]

{{Infobox PTTLink

{{Infobox PTTLink

| image = Thruhole 0010.JPG

| image = ASL RTCM VOTER-Front.jpeg

| caption = Voice Observing Time Extension for Radio (VOTER) Protocol<br/>By: Jim Dixon, WB6NIL (SK)<br/>Revision: Version 1.0 – August 11, 2013

| caption = Voice Observing Time Extension for Radio (VOTER) Protocol<ref name="VOTER">VOTER Protocol by Jim Dixon, WB6NIL (SK), [[Media:VOTER_protocol.pdf|VOTER Protocol Whitepaper]]</ref>

| category = Hardware

| category = Hardware

}}

}}

== Introduction ==

Voice Observing Time Extension for Radio (VOTER) Protocol<ref name="VOTER" /><br/>

VOTER is a completely connection-less UDP-based protocol (using IANA-assigned well-known port 667, originally assigned to me for a project I was doing for the United States Federal Election Commission, which, of course, deals mainly with an entirely different kind of voting). It provides for transmission of audio signals from remote radio receivers, along with ultra-precise (GPS-based) timing information and signal quality, allowing synchronization of multiple signals at the "head" end (hereinafter referred to as the "host") of the system and selection of which signal to use based upon the signal quality information and the consistency thereof. Audio and timing information may also optionally be sent back the remote location (hereinafter referred to as the "client") by the host to facilitate a multiple-site simulcast transmission system. In addition, it may serve as a simple, low overhead audio stream protocol for general-purpose (non-GPS-based timed) purposes.

 

= Introduction =

[[VOTER]] is a completely connection-less UDP-based protocol (using IANA-assigned well-known port 667, originally assigned to me for a project I was doing for the United States Federal Election Commission, which, of course, deals mainly with an entirely different kind of voting). It provides for transmission of audio signals from remote radio receivers, along with ultra-precise (GPS-based) timing information and signal quality, allowing synchronization of multiple signals at the "head" end (hereinafter referred to as the "host") of the system and selection of which signal to use based upon the signal quality information and the consistency thereof. Audio and timing information may also optionally be sent back the remote location (hereinafter referred to as the "client") by the host to facilitate a multiple-site simulcast transmission system. In addition, it may serve as a simple, low overhead audio stream protocol for general-purpose (non-GPS-based timed) purposes.

Security is provided by a Challenge/Response authentication technique using CRC-32 based digest information. Although it is by no means a terribly secure method (it is not even close to cryptographically-strong), it at least it provides somewhat of a deterrent for those attempting to circumvent the security.

Security is provided by a Challenge/Response authentication technique using CRC-32 based digest information. Although it is by no means a terribly secure method (it is not even close to cryptographically-strong), it at least it provides somewhat of a deterrent for those attempting to circumvent the security.

Both the client and the host use the same exact messages as shown below.

Both the client and the host use the same exact messages as shown below.

== Packet Structure ==

= Packet Structure =

The VOTER protocol packet consists of a 24 octet header and optionally a payload, which currently can either be 160 samples (20ms) of Mu-law encoded audio, 320 samples (40ms) of ADPCM encoded audio, or GPS location and elevation information (typically sent once per second).

The VOTER protocol packet consists of a 24 octet header and optionally a payload, which currently can either be 160 samples (20ms) of Mu-law encoded audio, 320 samples (40ms) of ADPCM encoded audio, or GPS location and elevation information (typically sent once per second).

=== Header Structure ===

== Header Structure ==

The VOTER protocol packet header consists of 24 octets as follows:

The VOTER protocol packet header consists of 24 octets as follows:

* Octets 22-23: Payload type, 16 bits (network order).

* Octets 22-23: Payload type, 16 bits (network order).

=== Payload Types ===

== Payload Types ==

Payload types are as follows (header Octets 22-23):

Payload types are as follows (header Octets 22-23):

==== Payload type 0 - Authentication plus flags ====  

=== Payload type 0 - Authentication plus flags ====

:Flags '''must''' be sent by host. Flags '''may''' be sent by Client.

:Flags '''must''' be sent by host. Flags '''may''' be sent by Client.

:* 64-128 – Reserved for Future Use

:* 64-128 – Reserved for Future Use

==== Payload type 1 – RSSI information + Mu-law audio ====  

=== Payload type 1 – RSSI information + Mu-law audio ===

:Octet 24 is RSSI value 0-255

:Octet 24 is RSSI value 0-255

:Packets of this payload type are sent only when the receiver is receiving a valid signal (or the host is indicating that a signal is to be transmitted).

:Packets of this payload type are sent only when the receiver is receiving a valid signal (or the host is indicating that a signal is to be transmitted).

==== Payload type 2 – GPS Information (optional) as follows: ====

=== Payload type 2 – GPS Information (optional) as follows: ===

:Octets 24-32: Longitude value, in the format XXXX.DDY (eg 4807.038N), ASCII string, null-terminated.

:Octets 24-32: Longitude value, in the format XXXX.DDY (eg 4807.038N), ASCII string, null-terminated.

:If Octets 24-49 are omitted, it is considered to be a “keep alive” packet (for maintaining NAT traversals and similar) and is done only by a “general-purpose” mode client without GPS information to send (since a GPS-based client or a “general-purpose” client with GPS would have GPS information to send which accomplishes the “keep alive” functionality as a side-affect).

:If Octets 24-49 are omitted, it is considered to be a “keep alive” packet (for maintaining NAT traversals and similar) and is done only by a “general-purpose” mode client without GPS information to send (since a GPS-based client or a “general-purpose” client with GPS would have GPS information to send which accomplishes the “keep alive” functionality as a side-affect).

==== Payload type 3 – RSSI information + IMA ADPCM audio in Intel/DVI block format ====

=== Payload type 3 – RSSI information + IMA ADPCM audio in Intel/DVI block format ===

:Octet 24 is RSSI value 0-255

:Octet 24 is RSSI value 0-255

:Packets of this payload type are sent only when the receiver is receiving a valid signal (or the host is indicating that a signal is to be transmitted).

:Packets of this payload type are sent only when the receiver is receiving a valid signal (or the host is indicating that a signal is to be transmitted).

==== Payload type 4 - Reserved for Future Use ====

=== Payload type 4 - Reserved for Future Use ===

==== Payload type 5 - "PING" (connectivity test) ====

=== Payload type 5 - "PING" (connectivity test) ===

:Octets 24 and up contain 200 bytes of payload for evaluation of connectivity quality. When a client receives this packet, it is intended to be transmitted (with the payload information intact) immediately back to the host from which it came. The actual contents of the payload are not specifically defined for the purposes of this protocol, and is entirely determined by the implementation of the applicable function in the host.

:Octets 24 and up contain 200 bytes of payload for evaluation of connectivity quality. When a client receives this packet, it is intended to be transmitted (with the payload information intact) immediately back to the host from which it came. The actual contents of the payload are not specifically defined for the purposes of this protocol, and is entirely determined by the implementation of the applicable function in the host.

== Protocol Explanation ==

= Protocol Description =

By definition, a digest value of 0 is an indication that the entity generating it has not received a validly recognizable digest from its peer. Therefore, a challenge must not be generated that would result in a digest value of 0.

By definition, a digest value of 0 is an indication that the entity generating it has not received a validly recognizable digest from its peer. Therefore, a challenge must not be generated that would result in a digest value of 0.

It is important to keep in mind that in “general-purpose” mode, the 20 millisecond time interval is by definition approximate (although kept as accurate and consistent as possible). Unlike GPS-based mode, the timing is based entirely upon local processor clock sources, etc., and can (and probably will)

It is important to keep in mind that in “general-purpose” mode, the 20 millisecond time interval is by definition approximate (although kept as accurate and consistent as possible). Unlike GPS-based mode, the timing is based entirely upon local processor clock sources, etc., and can (and probably will)

vary. Therefore, accommodation must be made to allow tolerance of this.

vary. Therefore, accommodation must be made to allow tolerance of this.