den Funk ins Internet übertragen

[Haniel]

Auf Server- oder Client-Seite ? -- also Serverseite = Stream-Server, Clientseite = Stream-Client ..

Hallo Shinzon
Wenn ich nur wüßte was du meinst.
Die Auswertung soll aber auf der Client Seite erfolgen in der Hoffnung das es auf der Stream Seite sowieso bleibt.
Gruß
Haniel

[Anorax]

Da ich die Woche über 130 km weit weg von meinem Heimatort und damit meiner Feuerwehr arbeite, aber dennoch gerne mitbekomme was zuhause so los ist, hab ich eine Übertragung so realisiert:

Scanner ist an den PC angeschloßen, auf dem PC läuft ein ShoutCast Server. Aber: Mein Router hat KEIN Portforwarding auf meinen PC, da ich sicherstellen will, dass niemand sonst Zugriff darauf hat. Die einzige möglichkeit den Funk über das Internet mitzuhören ist über einen verschlüsselten SSH Tunnel, welcher von einem anderen PC in meinem Netzwerk hergestellt wird. Über einen 2. Tunnel kann ich per VNC auf meinen Rechner zugreifen und sehen, wer alarmiert wurde. Auswertung über einen Stream auf der Clientseite halte ich für unsinnig, da die Frequenzen der 5-Tonfolgen durch kompression, etc. eh verfälscht würden.

[Newty]

Auswertung über einen Stream auf der Clientseite halte ich für unsinnig, da die Frequenzen der 5-Tonfolgen durch kompression, etc. eh verfälscht würden.

Richtig, das einzige, was vernünftig geht, ist ein PCM-Stream und den wird man nicht so einfach übers WAN werfen können... :-) Gilt auch für FMS und POCSAG, da bleibt auch nich viel zum auswerten über, nachdem das Ding durch nen 64kbit Encoder gelaufen is

[mdi]

Moinmoin,

ich habe eine ähnliche Konfiguration für ein Betriebsfunknetz realisiert. Genutzt habe ich dazu den IceCast2-Server, edcast als Quelle sowie den monitord als ZVEI-/POCSAG-Auswerter. Dieser speichert die ausgewerteten Telegramme direkt in einer MySQL-Datenbank bei meinem Webhoster.

Die einzige möglichkeit den Funk über das Internet mitzuhören ist über einen verschlüsselten SSH Tunnel, welcher von einem anderen PC in meinem Netzwerk hergestellt wird.

Das ist sinnvoll und relativ sicher, aber ganz schön aufwändig. Bei IceCast2 kann man den Stream per HTTP verteilen (kann ShoutCast das auch?), sowie diesen mit Usernamen und Passwort schützen. So man mag und einem das reicht. Speziell wenn man keinen SSH-Tunnel respektive VPN-Endpunkt stellen kann oder will, ist das aber ein guter Ansatz, wie ich finde. Und es erspart einem das Tunneln.

Über einen 2. Tunnel kann ich per VNC auf meinen Rechner zugreifen und sehen, wer alarmiert wurde.

Hier nutze ich einen gesicherten Web-Bereich, in dem die ZVEI-Fünfton-Sendungen des oben genannten Betriebsfunks dargestellt werden. PHP-Skripte greifen auf die Datenbank und die dort gespeicherten Daten des monitord zu und stellen diese entsprechend sinnvoll angepasst dar.

Auswertung über einen Stream auf der Clientseite halte ich für unsinnig, da die Frequenzen der 5-Tonfolgen durch kompression, etc. eh verfälscht würden.

Das stimmt an sich, allerdings sollten die entsprechenden Kompressionsalgorithmen (MP3/Ogg) gar nicht so dermaßen viel kaputt machen. ZVEI-Fünftonfolgen sind erstaunlich robust, habe ich festgestellt. POCSAG und digitale Geschichten sind da anfälliger.

Viele Grüße
Martin

[Haniel]

Bin am 5 wieder im Büro dann werde ich mal verschiedene Sachen Testen.
Euch allen ein frohes neues Jahr 2009.
Gruß
Haniel

[Techniker78]

Moin!

Ich kann die Kombination IceCast,dyndns,FMS32 nur empfehlen.
Habs Jahrelang so genutzt und die Auswertung 5 Tonfolge Alarmierung hat immer geklappt.
Selbst bei einem Stream mit 32kbps.
FMS gab es bei uns im RD damals noch nicht.

Anmerkung:Selbstverständlich hab ich nur testweise per Software generierte 5-Tonfolgen via icecast gesendet und niemals BOS Funk abgehört oder gar weiter transportiert.Ich weiß gar nicht wie das geht !

Gruß

Der Techniker

[ToffiFee]

Hallo zusammen,
ich habe einen Server laufen von dem eine Audiquelle an LineIn einer zweiten Soundkarte mittels Icecast2 und Ices2 auf einem Debian System ins Internet gestreamt wird (die Erste Soundkarte wird zur Auswertung digitaler Signale einer anderen Audioquelle und Darstellung dieser auf einem Webinterface benötigt).
Das funktioniert alles wunderbar, nun möchte ich allerdings nicht das jeder der einen Portscan auf mein Netzwerk startet und den offenen Port 8000 findet diesen Stream hören kann.

Hat Icecast2 eine Möglichkeit Streams mit einem Passwort zu schützen? Optimal ist natürlich immer wenn ein Systembenutzer der Gruppe "Stream" zugewiesen wird und sich dann einloggen kann. Aber unterstützt das Protokoll so etwas überhaupt? Beim googlen finde ich nur Infos über Source- und Adminpasswörter, nicht jedoch zum simplen hören. Oder liegt diese Konfiguration bei Ices2?

Ich würde mich über Hilfe freuen,
Bene

[Shinzon]

Moin.

Der Sinn von Icecast bzw. Shoutcast (als "vorgänger") liegt doch eben darin,
das der "Benutzer" den Stream hören kann. In der Konfigurationsdatei wie auch
in der Anleitung findet man deutlich den Hinweis, das es kein Passwort fürs
Zuhören gibt, sondern nur für den Sender, der die Daten anliefert, und den
Administrator.

Gruss,
Tim