Discussion:
Audiostream unmöglich?
(zu alt für eine Antwort)
Hannes Kuhnert
2020-05-10 17:57:36 UTC
Permalink
Wir wollen einen Audiostream über das Internet übertragen. Nach etwa einer
Stunde erfolgreichem Testbetrieb sind die Verbindungen abgebrochen und es
konnten keine mehr aufgebaut werden. Ich versuche den Grund aufzuklären und
freue mich über Hinweise.

Mittel der Wahl für das Versenden des Audiostreams ist ein Icecast-Server.
Dieser wird über eine DSL der Deutschen Telekom an das Internet
angeschlossen, mit einer Upstream-Datenrate etwas über 2 Mbit/s. Es geht
lediglich um eine niedrige einstellige Zahl von Empfängern, da sollte das
gut reichen.

Zunächst hat es tatsächlich prima funktioniert. Doch während wir mit
Rückmeldungen von übers Internet empfangenden Hörern an der Tontechnik
arbeiteten sind die Internetverbindungen plötzlich abgebrochen. Danach war
das Streaming nur noch innerhalb des lokalen Netzes möglich. Ein Neustart
des Router-Modems hat nichts verändert, auch mit der dann neuen IP-Adresse
war der Icecast-Server nicht mehr von außen erreichbar. Nur im lokalen Netz
funktionierte es noch.

Die Router-Konfiguration sah nach wie vor in Ordnung aus – Port 8000
freigegeben und dem richtigen Rechner zugeordnet.

Kann es sein, dass vom Anschlussbetreiber – nach mehr oder weniger
intelligenter Analyse – die Verbindungen unterbunden werden?

Gern würde ich im Anschlussvertrag nachlesen, ob dieser vielleicht solche
Streams ausschließt. Den Vertrag besorgen zu lassen wäre aber aufwendig.
Daher sei allgemein gefragt: Gibt es bei der Deutschen Telekom
Anschlussverträge, die Audiostreams untersagen, auch zeitlich eng begrenzte
solche mit sehr wenigen Hörern?

Fällt jemandem noch ein möglicher Grund für das Nichtmehrfunktionieren ein?
--
Hannes Kuhnert
Ralph Aichinger
2020-05-10 18:45:54 UTC
Permalink
Post by Hannes Kuhnert
Dieser wird über eine DSL der Deutschen Telekom an das Internet
angeschlossen, mit einer Upstream-Datenrate etwas über 2 Mbit/s. Es geht
lediglich um eine niedrige einstellige Zahl von Empfängern, da sollte das
gut reichen.
Naja, eine Frage dessen was da sonst noch drübergeht.
Post by Hannes Kuhnert
Die Router-Konfiguration sah nach wie vor in Ordnung aus – Port 8000
freigegeben und dem richtigen Rechner zugeordnet.
Also Portforwarding, OK.
Post by Hannes Kuhnert
Kann es sein, dass vom Anschlussbetreiber – nach mehr oder weniger
intelligenter Analyse – die Verbindungen unterbunden werden?
Sein kann alles. Kenne die Deutsche Telekom zu wenig.
Post by Hannes Kuhnert
Fällt jemandem noch ein möglicher Grund für das Nichtmehrfunktionieren ein?
Z.B. ein Bug in der beteiligten Software.

Z.B. irgendwelche wildgewordene "Sicherheitssoftware" (Firewall, Virenscanner,
wasauchimmer).

Was ich auf jeden Fall machen würde: Mal statt dem icecast auf dem Rechner
einen netcat-Server starten, und schauen ob du von außerhalb durchkommst.

/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund
Ralph A. Schmid, dk5ras
2020-05-11 07:41:58 UTC
Permalink
Post by Ralph Aichinger
Z.B. irgendwelche wildgewordene "Sicherheitssoftware" (Firewall, Virenscanner,
wasauchimmer).
Ich hatte nach Umstellung des Freifunk auf ein schnelleres VPN
plötzlich unerklärliche Aussetzer. Es stellte sich heraus, passieren
immer nach exakt x Paketen, und dauern dann genau zehn Sekunden. Des
Rätsels Lösung, außer der natürlich abgeschalteten Firewall hatte der
Router auch noch einen DDoS-Schutz, dem die UDP-Pakete von draußen zu
viel waren :( Drecks-Pseudo-Sicherheits-Gedöns...


-ras
--
Ralph A. Schmid +49-171-3631223 +49-911-21650056
http://www.schmid.xxx/ http://www.db0fue.de/
http://www.bclog.de/ http://www.kabuliyan.de/
Hannes Kuhnert
2020-05-11 10:25:33 UTC
Permalink
Post by Ralph Aichinger
Post by Hannes Kuhnert
Dieser wird über eine DSL der Deutschen Telekom an das Internet
angeschlossen, mit einer Upstream-Datenrate etwas über 2 Mbit/s. Es geht
lediglich um eine niedrige einstellige Zahl von Empfängern, da sollte das
gut reichen.
Naja, eine Frage dessen was da sonst noch drübergeht.
Fünf Hörer, die jeweils die 112 kbit/s beziehen, während desweiteren nur
typischer Bürokram läuft, vielleicht ein bisschen Online-Video-Bezug, aber
definitiv nichts upstream-lastiges – das müsste ein 2-Mbit/s-Anschluss gut
ermöglichen, so war meine überschlägige Rechnung.
Post by Ralph Aichinger
Post by Hannes Kuhnert
Fällt jemandem noch ein möglicher Grund für das Nichtmehrfunktionieren ein?
Z.B. irgendwelche wildgewordene "Sicherheitssoftware" (Firewall,
Virenscanner, wasauchimmer).
Da kommt mir nur der Speedport-Router in den Sinn. Mal sehen, ob an dem was
erkennbar und einstellbar ist!
Post by Ralph Aichinger
Was ich auf jeden Fall machen würde: Mal statt dem icecast auf dem Rechner
einen netcat-Server starten, und schauen ob du von außerhalb durchkommst.
Klingt gut!

Bisher eben gerade stand netcat auf der Liste der Werkzeuge, die ich
sinnvollerweise mal kennenlernen sollte.

Nun würde ich auf dem Rechner, wo sonst Icecast läuft, ausführen:

netcat -l -p 8000

… und auf einem Rechner irgendwo draußen:

netcat $SERVERADRESSE 8000

Wenn es funktioniert, wie es sollte, wird daraufhin eine Verbindung aufgebaut
und anschließend eingegebenes übertragen.

Ist das gemeint?
--
Hannes Kuhnert
Ralph Aichinger
2020-05-11 10:34:48 UTC
Permalink
Post by Hannes Kuhnert
Da kommt mir nur der Speedport-Router in den Sinn. Mal sehen, ob an dem was
erkennbar und einstellbar ist!
man weiß nie, was es da sonst noch alles gibt.
Post by Hannes Kuhnert
netcat -l -p 8000
netcat $SERVERADRESSE 8000
Wenn es funktioniert, wie es sollte, wird daraufhin eine Verbindung aufgebaut
und anschließend eingegebenes übertragen.
Genau. Den zweiten Teil mach ich bei TCP meistens einfach mit
telnet, wenn das vorhanden ist.

Du kannst über netcat quasi von einem Fenster ins andere tippen,
da sieht man auch gleich ob was durchgeht, ob Verzögerungen sich
seltsam anfühlen etc. Zuerst im LAN ausprobieren.

Achtung: Ich weiß jetzt nicht auswendig ob icecast TCP oder UDP
verwendet, netcat kann auch beides, bitte das richtige testen.

Netcat heißt auch bei manchen Installationen nur "nc", ich glaube
es gibt auch geringe Unterschiede bei der Syntax IIRC, aber das Prinzip
ist immer das gleiche.

Ein durch und durch nützliches Tool bei der Fragestellung "wer
blockt mich da wo genau".

/ralph
--
-----------------------------------------------------------------------------
https://aisg.at
ausserirdische sind gesund
Hannes Kuhnert
2020-05-11 20:59:35 UTC
Permalink
Post by Ralph Aichinger
Post by Hannes Kuhnert
Da kommt mir nur der Speedport-Router in den Sinn. Mal sehen, ob an dem
was erkennbar und einstellbar ist!
man weiß nie, was es da sonst noch alles gibt.
Klar!

Wenn der Server-Rechner aber direkt mit dem Router verbunden ist, dann ist
gezielt verbindungsunterbindende lokale Aktivität jedoch nur auf dem
Server-Rechner oder dem Router möglich, oder?
Post by Ralph Aichinger
Post by Hannes Kuhnert
netcat -l -p 8000
netcat $SERVERADRESSE 8000
Wenn es funktioniert, wie es sollte, wird daraufhin eine Verbindung
aufgebaut und anschließend eingegebenes übertragen.
Genau. Den zweiten Teil mach ich bei TCP meistens einfach mit
telnet, wenn das vorhanden ist.
Diese Erwähnung war hilfreich, denn netcat hat sich bei Internet-Tests anders
als bei lokalen Versuchen verhalten – zu meiner Überraschung: netcat hat
sich immer gezeigt, wie wenn ein Port offen ist und jemand dort wartet.
Selbst mit der Option -z hat es sich an keinem Port beendet, sondern ist
immer stehen geblieben, sodass es auf der Textkonsole genauso wie eine
Eingabemöglichkeit aussah.

Spekulativ: Gibt es das, dass ein Router ohne Portweiterleitung Ports offen
hat und ankommendes ins Leere laufen lässt?

Zu meiner Verwunderung hatte telnet da einen konkreten Mehrwert.
Post by Ralph Aichinger
Achtung: Ich weiß jetzt nicht auswendig ob icecast TCP oder UDP
verwendet, netcat kann auch beides, bitte das richtige testen.
Für’s Protokoll: Icecast verwendet TCP.
Post by Ralph Aichinger
Netcat heißt auch bei manchen Installationen nur "nc", ich glaube
es gibt auch geringe Unterschiede bei der Syntax IIRC, aber das Prinzip
ist immer das gleiche.
Wir hatten es hier ausschließlich mit OpenBSD-Netcat zu tun, das jeweils als
nc und als netcat zur Verfügung stand. Stimmt, die Aufruf-Syntaxen der
Varianten von netcat sind nicht völlig identisch! Die Hilfeausgabe des
OpenBSD-Netcat erwähnt sogar, dass es in der Betriebssystem-Distribution
auch noch ein „traditionelles“ netcat gibt.

Da der Port sich mit netcat nutzen ließ, lief dann auch noch ein
Audiostream-Versuch, mit bis zu zehn Hörern. Das ging über mehrere Stunden
ordentlich, bis zum freiwilligen Ende.

Der Hintergrund des diskussionsursächlichen Generalaussetzens ist damit
unklar geblieben.
--
Hannes Kuhnert
Hannes Kuhnert
2020-05-11 10:24:56 UTC
Permalink
Post by Hannes Kuhnert
Wir wollen einen Audiostream über das Internet übertragen. Nach etwa einer
Stunde erfolgreichem Testbetrieb sind die Verbindungen abgebrochen und es
konnten keine mehr aufgebaut werden.
Kann es sein, dass vom Anschlussbetreiber – nach mehr oder weniger
intelligenter Analyse – die Verbindungen unterbunden werden?
Auf meinem Computer habe ich zufälligerweise /Allgemeine Geschäftsbedingungen
Festnetz- und Mobilfunk-Anschlüsse/ der Deutschen Telekom vom 1. Januar 2018
gefunden.

Dort steht unter 4.1:
| Die überlassenen Leistungen dürfen nicht genutzt werden für den Einsatz in
| Vermittlungs- und Übertragungssystemen, die Verbindungen eines Dritten
| (Sprachverbindungen oder Datenübertragungen) an einen anderen Dritten ein-
| oder weiterleiten (z.B. Sim-Boxing).

Dies schließt nach meinem Verständnis zumindest aus, an solch einem Anschluss
einen Icecast-Server zu betreiben, der einen von anderswo stammenden Stream
nach außen zum Hören anbietet.

Als eine mögliche Alternative zum ursprünglich betrachteten, unklar nicht
funktionierenden örtlichen Server hatte ich angedacht, einen Icecast-Server
anderswo als die Quelle zu betreiben. Das aber ist jedenfalls an Anschlüssen
der Deutschen Telekom durch die Geschäftsbedingungen ausgeschlossen – wenn
ich vorstehendes richtig interpretiere.
--
Hannes Kuhnert
Gerald E:scher
2020-05-11 15:07:10 UTC
Permalink
Post by Hannes Kuhnert
Auf meinem Computer habe ich zufälligerweise /Allgemeine Geschäftsbedingungen
Festnetz- und Mobilfunk-Anschlüsse/ der Deutschen Telekom vom 1. Januar 2018
gefunden.
| Die überlassenen Leistungen dürfen nicht genutzt werden für den Einsatz in
| Vermittlungs- und Übertragungssystemen, die Verbindungen eines Dritten
| (Sprachverbindungen oder Datenübertragungen) an einen anderen Dritten ein-
| oder weiterleiten (z.B. Sim-Boxing).
Diese Punkt verbietet GSM-Gateways.
https://de.wikipedia.org/wiki/SIM-Box
Post by Hannes Kuhnert
Dies schließt nach meinem Verständnis zumindest aus, an solch einem Anschluss
einen Icecast-Server zu betreiben, der einen von anderswo stammenden Stream
nach außen zum Hören anbietet.
Glaube ich nicht. Jedenfalls hat dein Problem nichts mit Audio zu tun.
--
Gerald
Hannes Kuhnert
2020-05-11 20:47:42 UTC
Permalink
Post by Gerald E:scher
Post by Hannes Kuhnert
Auf meinem Computer habe ich zufälligerweise /Allgemeine
Geschäftsbedingungen Festnetz- und Mobilfunk-Anschlüsse/ der Deutschen
Telekom vom 1. Januar 2018 gefunden.
| Die überlassenen Leistungen dürfen nicht genutzt werden für den Einsatz
| in Vermittlungs- und Übertragungssystemen, die Verbindungen eines
| Dritten (Sprachverbindungen oder Datenübertragungen) an einen anderen
| Dritten ein- oder weiterleiten (z.B. Sim-Boxing).
Diese Punkt verbietet GSM-Gateways.
https://de.wikipedia.org/wiki/SIM-Box
Mir leuchtet ein, dass dies dahintersteht. Ich kann mir auch gut vorstellen,
dass das Unternehmen die formulierte Regelung einzig dagegen durchsetzt.
Post by Gerald E:scher
[…] Jedenfalls hat dein Problem nichts mit Audio zu tun.
Ohne das Problem für audiofern zu halten, befand ich schon nach dem Versenden
meines ersten Beitrags, dass die Zielgruppenempfehlung für Antworten wohl
nicht optimal war. Jetzt noch umzuschwenken erschiene mir aber nicht
geschickter.
--
Hannes Kuhnert
Loading...