wiki:EL4REchoLinkRequirements
Last modified 12 years ago Last modified on 05/02/07 18:24:12

EchoLink Anforderungen

Auf dieser Seite sollen Informationen zur Funktionsweise des EchoLink-Protokolls und Anforderungen an die EL4R-Software zusammengetragen werden.

EchoLink Kommandos

Von der Funkseite aus kann ein EchoLink-Knoten mit verschiedenen Kommandos gesteuert werden. Die vollständige Liste aller Kommandos kann auf echolink.org eingesehen werden. Die wichtigsten Kommandos werden nachfolgend dargestellt.


DTMF Komando Erklärung
* Play info Kurze Beschreibung der Station
# Disconnect Verbindung (mit letzter Station) beenden
nnnn Connect to nnnn Verbindung zu Knoten nnnn aufbauen


EchoLink Gateway

Empfangsmodus RF

Beim Empfang von RF-Signalen (DTMF oder Sprachsignal) muss ein eindeutiger HF-Pegel vorliegen. Im Falle einer bestehenden Verbindung wird bei "Freisignal" die Sprache übermittelt. DTMF wird ausgewertet.

  1. Software VOX (Minimalpegel, Ansprechverzögerung, Abfallzeit variabel).
  2. Steuersignal (CTS/DSR)von S-Meter auf Seriell-Port (z.B. TS-2000).

Sendemodus RF

Zur Aussendung von Internet-Sprachsignalen auf RF muss der Träger des Funkgerätes getastet werden.

  1. VOX im Funkgerät
  2. Steuerung über Seriell gegen Masse (RTS/DTR).

EchoLink Protokoll

Das EchoLink-Protokoll basiert auf den beiden Protokollen RTP und RTCP, welche auch bei klassischer VoIP-Kommunikation zum Einsatz kommen. Zusätzlich verwendet das EchoLink-Protokoll noch eine TCP-Verbindung zum EchoLink-Server zur Verifizierung der einzelnen Teilnehmer.

  • TCP-Port 5200 - Kommunikation zum EchoLink-Server
  • UDP-Port 5199 - Signalisierungsdaten vom/zum EchoLink-Partner
  • UDP-Port 5198 - Sprach- und Chatdaten vom/zum EchoLink-Partner

Authentifizierung

Um sich mit anderen EchoLink-Stationen verbinden zu koennen, muss man sich beim EchoLink-Server authentifizieren, da die Gegenstelle beim EchoLink-Server beim Aufbau einer Verbindung nachprueft, ob der Verbindungsversuch von einem gueltigen Teilnehmer erfolgt.

Dazu baut jeder EchoLink-Knoten eine temporaere TCP-Verbindung zum EchoLink-Server mit dem Zielport 5200 auf. Diese Verbindung wird dann genutzt, um sich am EchoLink-Server anzumelden, den aktuellen Status zu modifizieren oder die Liste angemeldeter Stationen abzufragen. Nach jeweils einer Aktion wird die Verbindung vom EchoLink-Server beendet, sollen also mehrere Aktionen auf einmal durchgefuehrt werden, so muss die TCP-Verbindung mehrfach aufgebaut werden.

Signalisierung

Moechte sich ein EchoLink-Knoten mit einem anderen EchoLink-Knoten verbinden, so muss dieser zuerst die IP-Adresse des EchoLink-Knoten ermitteln, mit dem die Verbindung aufgebaut werden soll. Dazu wird vorher vom EchoLink-Server zur Knotennummer die aktuelle IP-Adresse ermittelt werden.

Im Anschluss wird ein UDP-Paket mit Zielport 5199 an die angegebene IP-Adresse gesendet. Als Datenformat wird dabei RTCP verwendet, welches leider modifiziert worden ist, so dass hier keine vorhandenen Bibliotheken verwendet werden koennen.

Zum Aufbau einer Sprachverbindung wird ein RTCP-Paket gesendet, welches zwei untergeordnete Dateneinheiten enthaelt. Zuerst ist ein RTCP_RR-Eintrag enthalten, gefolgt vom einem RTCP_SDES-Eintrag.

Beide Eintraege enthalten einen generischen Header (RTP_VERSION << 6, RTCP_PAYLOAD_TYPE, Laenge (16 bit, jedoch ohne diese 4 Byte). Danach folgt der Paketheader abhaengig vom RTCP_PAYLOAD_TYPE.

Der RTCP_RR-Header besteht aus einem 4 Byte Identifier (ssrc) gefolgt vom einem RR-Report, welcher jedoch hier weggelassen wird.

Der RTCP_SDES-Header enthaelt nach dem generischen Header wieder einen 4 Byte Identifier (ssrc), gefolgt von einer Liste von SDES-Eintraegen. Diese besitzen jeweils einen eigenen Header, welcher den jeweiligen Typ (1 Byte, CNAME, NAME, EMAIL, PHONE, END) und die Laenge (1 Byte) des jeweiliges SDES-Eintrages enthaelt

Dabei wird als CNAME der String CALLSIGN, als NAME das eigentliche Rufzeichen, als EMAIL wieder der String CALLSIGN und als PHONE der Wert "08:30" uebertragen. Der Abschluss der SDES-Eintraege wird durch ein SDES_END gekennzeichnet. Danach muss das RTCP-Paket durch Padding auf eine volle Wordgrenze gebracht werden und dies im letzten RTCP-Header (bei uns der SDES-Header) durch das P-Bit gekennzeichnet werden.

Zum Abbau einer Verbindung wird ein RTCP-Packet gesendet. Dieses enthaelt wiederum 2 untergeordnete Dateneinheiten. Zuerst ist ein RTCP_RR-Eintrag vorhanden (Beschreibung siehe oben), gefolgt vom einem RTCP_BYE-Eintrag. Dieser enthaelt nach dem generischen Header wieder die Angabe des 4 Byte Identifier (ssrc), gefolgt von der Laenge der nachfolgenden Zeichenkette. Danach muss das RTCP-Paket wieder auf eine Wortbreite vergroessert werden.

Wird der Verbindungsaufbau von der Gegenstelle abgelehnt, so antwortet dieses mit einem RTCP_BYE-Paket.

Sprach- und Chatdaten

Nach Aufbau einer logischen Verbindung zwischen den beteiligten EchoLink-Knoten werden die Sprach- und Chatdaten mittels RTP ausgetauscht. Dabei werden die RTP-Dateneinheitem unter Verwendung von UDP mit Zielport 5198 ausgetauscht.

Jedes RTP-Paket enthaelt einen Header, der aus Version (1 Byte), Payload (1 Byte), Sequenznummer (2 Byte), Zeitstempel (4 Byte) und Identifier (4 Byte) besteht. Der Payload wird fest auf 0x03 gesetzt (GSM-Codec). Im Anschluss befinden sind die Audiodaten, dabei wird eine feste Groesse von 4*33 Byte verwendet.

Sowohl Sequenznummer (htons) als auch Zeitstempel und SSRC (htonl) muessen in Network-Byteorder uebertragen werden.