QoS für VoIP via VPN User

Forum zum Thema Firewall

Moderator: Lancom-Systems Moderatoren

MDCYP
Beiträge: 187
Registriert: 22 Okt 2015, 11:31
Wohnort: Dortmund

QoS für VoIP via VPN User

Beitrag von MDCYP »

Hi zusammen,

ich wollte fragen ob mir jemand einen Tip geben kann, welchen QoS ich erstellen sollte für das Szenario:

- MA macht HO und hat einen SoftClient VoIP laufen
- MA wählt sich via IKEv1/IPSEC auf dem LANCOM 1781VAW ein
- Asterisk VoIP Server ist im Intranet

Wie stell ich es nun ein, dass für eingehende VPN Verbindungen Bandbreite für RTP freigehalten wird? Oder wenigstens für die feste IP des MA die er bei der VPN Verbindung vom LANCOM erhält.

Danke
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: QoS für VoIP via VPN User

Beitrag von Dr.Einstein »

Hiho MDCYP,

wieso viel schreiben, wenn das bereits ein netter User hier im Forum bereits getan hat: https://www.johnlose.de/faq-items/qos-d ... kstarface/

Du musst halt bedenken, dass du bei den beiden genannten Szenarien nur eine Seite halbwegs kontrollieren kannst:

Der Mitarbeiter mit dem VPN Client kann zwar QoS Markierungen zu seinem Internet Router schicken, ob der nun aber Bandbreite für die Telefonie reserviert, unwahrscheinlich, schon gar nicht, wenn der Mitarbeiter eine SIM Karte im Laptop oder ähnliches hat.

Beim 2. Szenario sieht es identisch aus, außer der vorgeschaltete Internetrouter (=IPSec Gateway?) ist von euch und dort kann ebenfalls QoS eingestellt werden. Dann hast du gute Karten, dass die Telefonie unter vielen Bedingungen QoS-Technisch reibungslos laufen wird.

Gruß Dr.Einstein
MDCYP
Beiträge: 187
Registriert: 22 Okt 2015, 11:31
Wohnort: Dortmund

Re: QoS für VoIP via VPN User

Beitrag von MDCYP »

Danke schön :M
AS1306
Beiträge: 333
Registriert: 08 Okt 2006, 11:44
Wohnort: Berlin

Re: QoS für VoIP via VPN User

Beitrag von AS1306 »

@All, vielleicht versuche ich mein Problem an dieser stelle noch einmal zu verifizieren. Ich bin momentan etwas frustriert, da ein Telefonieren über eine VPN-Strecke aktuell nur schwer, wenn sogar gar nicht möglich ist. Im aktuellen Fall betrifft es ein Verbund aus 3 Objekten, wobei im Hauptobjekt ein 1783VAW steht, an dem eine Asterisk-Anlage betrieben wird. Im SO A steht ebenfalls ein 1783VAW und im SO B ein 1781VA-4G ... Hauptobjekt = Zentrale, alles wird darüber geroutet. VPN-Tunnel werden von außerhalb in Richtung Zentrale aufgebaut. Bei allen Anschlüssen handelt es sich um VDSL50 Business Varianten. Firmware ist überall aktuell - 10.12.0234 RU5 ... Telefonie am Hauptstandort klappt uneingeschränkt. Die in den Niederlassungen stehenden Telefone wurden vor Ort provisioniert und lokal dann angeschlossen. Verbindung steht, nur kommt es beim Gespräch nach kurzer Zeit zu "Verschluckern" bzw. zu einem unerträglichen "Stottern" und dies auch sehr unregelmäßig. Es gibt Phasen, in denen das mal 45 Sekunden geht und dann wieder alle 3-4 Sekunden. Über den oben genannten Link hatte ich daher sch0on eine Bandbreite reserviert, was allerdings zu keinerlei Besserung führte. Die genannte Konstellation ist seit 2013 ohne Schwierigkeiten betrieben worden. Seit ca. 4 Monaten stelle ich das Problem mehr und mehr fest, wobei es aktuell ein Horror ist, telefonieren zu müssen. Ich wäre daher für Tipps oder Ideen bzw. Unterstützung in jeglicher Form sehr dankbar!

Thema wäre hier allerdings: QoS für VoIP bei einer VPN Site-to-Site Verbindung ...

Grüße aus Charlottenburg

Andreas
VDSL100MBit ... Lancom 1793VAW, 1783VAW, 1781AW/EW, 1781(V)A-4G - L-1702, L-1302, 452AGN - GS2326, GS2328P ... diverse VPN- und VoIP-Clients sowie Telefonieanbindung: Starface PBX, DX800A, DX900, N510/N870, Maxwell IP Pro, Patton SmartNode FXS ...
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: QoS für VoIP via VPN User

Beitrag von Dr.Einstein »

Hey Andreas,

kannst du mal deine QoS Regeln unzensiert posten? Greifen die QoS Regeln (= siehe Lancom Monitor, WAN -> QoS)? Hast du Aussetzer schon in Verbindung mit Überlast gebracht oder ist das unabhängig davon?

Grüße vom anderen Ende der Stadt
Dr.Einstein
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: QoS für VoIP via VPN User

Beitrag von GrandDixence »

AS1306 hat geschrieben:Verbindung steht, nur kommt es beim Gespräch nach kurzer Zeit zu "Verschluckern" bzw. zu einem unerträglichen "Stottern" und dies auch sehr unregelmäßig.
Wireshark besitzt ein mächtiges Werkzeug zur Untersuchung von VoIP-Telefongespräche (RTP-Datenströme) auf Jitter, verlorene Datenpakete etc.

https://wiki.wireshark.org/RTP_statistics

Einfach das VoIP-Telefongespräch mit der "Packet Capture"-Funktion der LANCOM-Geräte aufzeichnen und die Aufzeichnungsdatei (*.pcap/*.pcapng) mit Wireshark öffnen. Dann im Wireshark-Menü die RTP-Analysefunktionen unter "Telephony" -> "RTP" aktivieren.

Ob QoS wirkt oder nicht, merkt man ziemlich schnell, wenn man die Verbindung künstlich unter Volllast stellt...

Aufzeichnungsdateien zum Üben und Lernvideos für Wireshark sind auf dieser Webseite ganz unten erhältlich:
https://wiki.wireshark.org/VoIP_calls
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: QoS für VoIP via VPN User

Beitrag von GrandDixence »

MDCYP hat geschrieben:Wie stell ich es nun ein, dass für eingehende VPN Verbindungen Bandbreite für RTP freigehalten wird? Oder wenigstens für die feste IP des MA die er bei der VPN Verbindung vom LANCOM erhält
QoS-Mechanismen sind nur wirksam, wenn in der Netzwerkkomponente von einer schnelleren Leitung auf eine langsamere Leitung gewechselt wird UND die auf der langsameren Leitung zu versendenden Datenpakete sich in der Sendewarteschlange stauen. Ansonsten ist QoS ziemlich wirkungslos! In Empfangsrichtung kann QoS sehr wenig ausrichten.

Selbst ein Windows-Rechner unterstützt QoS-Mechanismen:

https://www.msxfaq.de/netzwerk/qos/qoswin.htm

Der Einsatz von QoS bei einem Windows-Rechner könnte sinnvoll sein. Jedoch müsste QoS auf die IPSEC-Datenpakete (ESP oder UDP 4500) vom VPN-Client und nicht auf die RTP-Datenpakete vom VoIP-SoftClient wirken! Deshalb wird häufig der VoIP-Datenverkehr nicht durch den VPN-Tunnel geschleust, sondern eine verschlüsselte Telefonie mit SIPS/SRTP realisiert und diese verschlüsselte VoIP-Telefonie, trotz bestehenden VPN-Tunnel, möglichst QoS-gesteuert durch das Internet gejagt.

Für VoIP über VPN darf keine TCP-basierte VPN-Lösung wie SSL-VPN (LANCOM: "IPSec over HTTPS") eingesetzt werden:
https://de.wikipedia.org/wiki/SSL-VPN
TCP eignet sich nicht für zeitkritische Anwendungen wie die Sprachtelefonie (RTP).
AS1306
Beiträge: 333
Registriert: 08 Okt 2006, 11:44
Wohnort: Berlin

Re: QoS für VoIP via VPN User

Beitrag von AS1306 »

Ich danke Euch erst einmal für das schnelle Feedback! Mein rein subjektiver Eindruck ist tatsächlich, dass das lastabhängig ist. An der Hauptnebenstelle laufen 2 RDP-Sessions + eventuell IR + 1-2 VoIP Gespräche. Allerdings kann ich zeitlich auch einen Zusammenhang mit der Umstellung auf IP-Anschluss in der Zentrale sehen. Anyway, würde es gern wieder zum Laufen bringen. Aufgrund des Nichtfunktionierens habe ich alles wieder komplett entfernt - Reset an allen 3 Routern und komplette Neukonfiguration. (Dachte, dass es eventuell am aktuellen Release hängt!) Hatte aber ein paar SnagIT-Bilder, muss mal schauen, wo die liegen ... oder es noch einmal konfigurieren. Daher auch meine Nachfrage hier, welcher Weg wohl der beste ist. Die ursprüngliche Variante war: FW - QoS Empfehlung für VoIP - keine Verbesserung bzw. Änderung, danach die Variante von John Lose (Link weiter oben im Thread) ... auch keine Besserung. Und ja, im LanMonitor wurden die Werte angezeigt. Hatte sogar 256kBit pro Session testweise reserviert ... Telefonieverhalten unverändert. Daher mein Frust und die beginnende Resignation ...

Bin aktuell (Monatsanfang) komplett mit der Abrechnung beschäftigt, so dass ich die WireShark-Sache erst Mitte nächster Woche angehen könnte. Da das echt nervt und doch recht dringend ist, würde ich das sogar abgeben und bezahlen. Falls also jemand einen echten Vollprofi hier in Berlin (Dr. Einstein .. :wink: ) oder aus der Ferne kennt ... habe ich keine Schwierigkeiten.

VoIP - TCP über VPN und dass man QoS mehr oder weniger nur in Senderichtung beeinflussen kann, war mir tatsächlich so noch nicht bewusst ... Hier liegt allerdings kein SSL-VPN vor, ist eine VPN Site-to-Site Verbindung auf klassischer Art und Weise. "IPSec over HTTPS" ist definitiv deaktiviert!

Grüße aus dem sonnigen Charlottenburg
VDSL100MBit ... Lancom 1793VAW, 1783VAW, 1781AW/EW, 1781(V)A-4G - L-1702, L-1302, 452AGN - GS2326, GS2328P ... diverse VPN- und VoIP-Clients sowie Telefonieanbindung: Starface PBX, DX800A, DX900, N510/N870, Maxwell IP Pro, Patton SmartNode FXS ...
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: QoS für VoIP via VPN User

Beitrag von Jirka »

AS1306 hat geschrieben:VoIP - TCP über VPN und dass man QoS mehr oder weniger nur in Senderichtung beeinflussen kann, war mir tatsächlich so noch nicht bewusst ...
Das stimmt ja auch nicht. Wie die Aussage zustande kommt, dass IPsec over HTTPS (NCP VPN Path Finder) nicht für VoIP geeignet ist, keine Ahnung, da hätte ich gerne eine Begründung. Und QoS in Empfangsrichtung geht sehr wohl, man kann nämlich TCP-Streams wunderbar einbremsen. In den meisten Fällen reicht das. Gegen eine UDP flood attack als DoS-Angriff hilft das natürlich wenig. Aber der Normalfall sieht anders aus...

Viele Grüße,
Jirka
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: QoS für VoIP via VPN User

Beitrag von Dr.Einstein »

Hi Jirka,
Jirka hat geschrieben:Und QoS in Empfangsrichtung geht sehr wohl, man kann nämlich TCP-Streams wunderbar einbremsen. In den meisten Fällen reicht das. Gegen eine UDP flood attack als DoS-Angriff hilft das natürlich wenig. Aber der Normalfall sieht anders aus...
Theoretisch, auf dem Papier eventuell. Aber teste das mal bitte mit dem aktuellen 10.12er oder von mir aus auch alten 9.24 LCOS, also häng Wireshark ran, Paketgenerator/-Empfänger auf beiden Seiten und dann macht mal TCP Dampf auf die Leitung. Wenn du ankommend für TCP eine Prio einrichtest, z.B. 25% Mindestbandbreite für Kassenssysteme, dann haut nichts mehr hin. Die Kassen bekommen mal 10% mal 50%, alles andere geht auch den Bach runter, und vor allem die CPU ackert plötzlich hoch auf über 50%. Bei einem gleichmäßigen UDP VoIP hast du widerrum bessere Karten, da hier das ZickZack-TCP Verhalten nicht negativ zum Tragen kommt. Aber ich bin bei dem Thema immer offen für andere / weitere Informationen.

Trotzdem habe ich das Gefühl, dass das Problem von Andreas gar nichts mit QoS zutun hat. Tue mir mal den Gefallen, wenn du mal wieder Luft hast, Testanrufe ohne aktives QoS durchzuführen. Dabei mehrere Tests, wenn die Leitungen bei nahe 0% Auslastung ist, und mehrere Tests, wenn die Leitung dicht oder zumindest halbwegs belastet ist. Wenn du Probleme ohne aktives QoS + keine Last auf den Leitungen hast, dann hast du andere Probleme, z.B. Paketverlust, oder miserable Software in den TK-Anlagen / IP Endgeräten (wäre zB bei Siemens nicht das erste Mal).

Jirka kann dir aber bestimmt helfen, der nimmt doch fast jeden Auftrag mit Inhalt Telefonie an :roll: mir reicht mein Job auf Arbeit, da brauch ich nicht noch in meiner Freizeit zu Kunden, sorry :wink: .

Gruß Dr.Einstein
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: QoS für VoIP via VPN User

Beitrag von GrandDixence »

Jirka hat geschrieben:
AS1306 hat geschrieben:Das stimmt ja auch nicht. Wie die Aussage zustande kommt, dass IPsec over HTTPS (NCP VPN Path Finder) nicht für VoIP geeignet ist, keine Ahnung, da hätte ich gerne eine Begründung.
Für den Sprachkanal wird bei VoIP-Telefongespräche in der Regel das Netzwerkprotokoll RTP verwendet:
https://de.wikipedia.org/wiki/Real-Time ... t_Protocol

Das Netzwerkprotokoll RTP ist für den Einsatz mit dem "Transportprotokoll" UDP vorgesehen. Geht ein RTP-Datenpaket beim Transport vom Sender zum Empfänger verloren, bügelt dieser Paketverlust der DSP (Digitaler Signalprozessor) im VoIP-Telefon aus:
https://de.wikipedia.org/wiki/Digitaler_Signalprozessor

Der DSP kann Paketverluste bis zu einer Rate von etwa 1 % mit für den Hörer akzeptable Verluste der Sprachqualität ausbügeln:
https://kb.smartvox.co.uk/voip-sip/rtp- ... lity-voip/

Beim Einsatz von UDP kann ein Datenpaket auf dem Transportweg verloren gehen und die Anwendung muss allenfalls für die Transportsicherung aufkommen:
https://de.wikipedia.org/wiki/User_Datagram_Protocol

Im Fall von RTP ist eine Transportsicherung nur schädlich für die Sprachqualität und es wird deshalb bewusst auf eine Transportsicherung gegen Paketverluste und Paketverfälschungen verzichtet!

Geht beim Einsatz von TCP (eben zum Beispiel beim Einsatz von "IPSec over HTTPS) ein Datenpaket verloren, erkennt das Transportprotokoll TCP den Paketverlust und sorgt für die erneute Versendung des verlorengegangenen Datenpaket, bis dieses unversehrt beim Empfänger angekommen ist:
https://de.wikipedia.org/wiki/Transmiss ... l_Protocol

Dieses erneute Versenden von auf dem Transportweg verloren gegangenen Datenpakete oder verfälschte Datenpakete führt im Fall von RTP zu massiven Jitter, Delay etc. was wiederum zu einem massiven Einbruch der Sprachqualität führt. Deshalb ist RTP nur für den Einsatz über UDP vorgesehen!

Und auf die möglichen negativen Einflüsse des "TCP Receive Window" gehe ich gar nicht ein:
http://www.lovemytool.com/blog/2010/07/ ... greer.html

Für die Signalisierung von VoIP-Telefongespräche mit dem Netzwerkprotokoll SIP ist der Einsatz von TCP zu empfehlen. Noch empfehlenswerter ist die TLS-verschlüsselte Signalisierung der VoIP-Telefongespräche mit SIPS (Port TCP 5061):
https://de.wikipedia.org/wiki/Session_I ... n_Protocol

Beim Einsatz von TLS-verschlüsselter Signalisierung des VoIP-Telefongesprächs mit SIPS (Port TCP 5061) wird der verschlüsselte Sprachkanal (SRTP) weiterhin über UDP realisiert:
https://de.wikipedia.org/wiki/Secure_Re ... t_Protocol
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: QoS für VoIP via VPN User

Beitrag von GrandDixence »

Telefongespräche sollten nicht über WLAN erfolgen.

Durch den WLAN Background Scan wird je nach Betriebsystem alle 30 bis 120 Sekunden vom WLAN-Client für einen Sekundenbruchteile bis 2 Sekunden die WLAN-Verbindung getrennt. Diese kurzen WLAN-Verbindungsunterbrüche führen zu kurze Gesprächsunterbrüche oder zu kurzfristige massive Einbrüche der Sprachqualität während einem Telefongespräch über WLAN.

Der WLAN Background Scan ist keine Fehlfunktion des Computers bzw. SmartPhones/Tablet. Während der kurzfristigen WLAN-Trennung sucht der WLAN-Client (z.B. Computer oder SmartPhone/Tablet) nach besser empfangbaren WLAN Access Points.

Wegen dem WLAN Background Scan bietet die Sprachtelefonie mit VoIP (z.B. Skype oder "Skype for Business") über "normale" WLAN-Clients immer eine deutlich schlechtere Dienstgüte als die "echte" drahtlose Telefonie mit DECT und CAT-iq. Siehe auch:

https://www.ghacks.net/2011/12/13/how-t ... und-scans/

http://superuser.com/questions/881880/t ... -windows-8

Weiter fehlen üblicherweise den VoIP-SoftClients auf den "normalen" WLAN-Clients die Unterstützung für die notwendigen QoS-Mechanismen (WMM/IEEE 802.11e) für die Sprachtelefonie über WLAN.

https://de.wikipedia.org/wiki/Wi-Fi_Multimedia

WLAN ist Mobilfunk für die "armen Leute"...
Zuletzt geändert von GrandDixence am 03 Mär 2018, 12:44, insgesamt 2-mal geändert.
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: QoS für VoIP via VPN User

Beitrag von GrandDixence »

Um die QoS-Mechanismen eines Routers zwischen dem Heimnetzwerk (Gigabit-Ethernet/Fast Ethernet => 1000 MBit/s oder 100 MBit/s) und dem Internetanschluss (zum Beispiel VDSL mit 50 MBit/s maximal) zu testen, kann mit IPerf2/IPerf3 sehr leicht die Internetleitung überlastet werden:

http://www.lancom-forum.de/lancom-allge ... 16579.html

Am einfachsten überflutet man den Internetanschluss im Upstream (Upload-Richtung) mit UDP-Datenpakete von einer UDP-Messung mit IPerf2/IPerf3. Dazu wird IPerf2/IPerf3 mit einer UDP-Datenpaketrate ausgeführt, die jederzeit höher als die maximal mögliche Datenübertragungsrate des Internetanschlusses im Upstream ist. Das IPerf3-Beispiel:

Code: Alles auswählen

# iperf3 -u -t 30 -b 60M -l 1200 -c ping-ams1.online.net
sendet mit einer Datenübertragungsrate von 60 MBit/s (Parameter: "-b 60M") UDP-Datenpakete vom heimischen Rechner in Richtung Internet zum IPerf3-Server ping-ams1.online.net.

Wie man mit IPerf2/IPerf3 ein VoIP-Telefongespräch simuliert, ist im Beitrag:
http://www.lancom-forum.de/aktuelle-lan ... tml#p91646
beschrieben.
Zuletzt geändert von GrandDixence am 03 Mär 2018, 13:02, insgesamt 1-mal geändert.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: QoS für VoIP via VPN User

Beitrag von Jirka »

Hallo Dr. Einstein,
Dr.Einstein hat geschrieben:Theoretisch, auf dem Papier eventuell. Aber teste das mal bitte mit dem aktuellen 10.12er
Das kann durchaus sein, dass das mit der 10.12 praktisch nicht funktioniert oder nicht fehlerfrei. Mir ist mit meinen bisherigen Erfahrungen mit der 10.12 auch danach.
Dr.Einstein hat geschrieben:Trotzdem habe ich das Gefühl, dass das Problem von Andreas gar nichts mit QoS zutun hat.
Komisch, ich auch. Das hört sich teilweise so eigenartig an, da muss was grundsätzliches schief laufen.
Dr.Einstein hat geschrieben:Tue mir mal den Gefallen, wenn du mal wieder Luft hast, Testanrufe ohne aktives QoS durchzuführen. Dabei mehrere Tests, wenn die Leitungen bei nahe 0% Auslastung ist, und mehrere Tests, wenn die Leitung dicht oder zumindest halbwegs belastet ist. Wenn du Probleme ohne aktives QoS + keine Last auf den Leitungen hast, dann hast du andere Probleme, z.B. Paketverlust, oder miserable Software in den TK-Anlagen / IP Endgeräten (wäre zB bei Siemens nicht das erste Mal).
Damit meintest Du jetzt Andreas? Ich sehe das auch so. Hier müssen im Rahmen des Troubleshootings erst mal grundsätzliche Sachen geklärt werden.
Dr.Einstein hat geschrieben:Jirka kann dir aber bestimmt helfen, der nimmt doch fast jeden Auftrag mit Inhalt Telefonie an
Ich bin da nicht grundsätzlich abgeneigt, aber das ist ein undankbarer Job. Unter 2 Tagen läuft da vermutlich nichts und wenn man am Ende noch rausbekommt, dass irgendwas im LCOS mit QoS nicht stimmt, dann macht man sich hier mit einer Bugmeldung wieder unbeliebt.

Viele Grüße,
Jirka

@GrandDixence:
GrandDixence hat geschrieben:Dieses erneute Versenden von auf dem Transportweg verloren gegangenen Datenpakete oder verfälschte Datenpakete führt im Fall von RTP zu massiven Jitter, Delay etc. was wiederum zu einem massiven Einbruch der Sprachqualität führt.
Nein, führt es nicht. Dass die Performance leidet und die Bandbreite steigt, keine Frage. Ist die Bandbreite aber vorhanden, stören erneut versendete Pakete wenig. Es ist zwar nutzlos und umsonst, weil diese viel zu spät eintreffen und damit verworfen werden, aber so kommt kein größerer Jitter zu Stande als es ihn auch über UDP geben würde. Die Latenz steigt sicherlich minimal, aber nicht durch TCP, sondern durch den zusätzlichen Header der oben drauf kommt, das kann man aber vernachlässigen.
GrandDixence hat geschrieben:Für die Signalisierung von VoIP-Telefongespräche mit dem Netzwerkprotokoll SIP ist der Einsatz von TCP zu empfehlen.
Wo steht das genau? In dem Link, den Du dazu aufführst, steht nur das Gegenteil:
Da bei SIP eine Übertragung über ein verbindungsloses Netzwerkprotokoll sinnvoller ist, ...
GrandDixence
Beiträge: 1054
Registriert: 19 Aug 2014, 22:41

Re: QoS für VoIP via VPN User

Beitrag von GrandDixence »

Es liegt auf der Hand, dass SIP über ein zuverlässiges Transportprotokoll wie TCP eine robustere und zuverlässigere Signalisierung von Telefongespräche ermöglicht, als SIP über ein nicht-zuverlässiges, nicht-gesichertes Transportprotokoll wie UDP.

Dagegen wehren sich aber alle grösseren Betreiber von VoIP-Hardware wie "Deutsche Telekom", Unitymedia etc. Denn SIP über TCP ist ressourcenhungriger als SIP über UDP. Dieser erhöhte Ressourcenbedarf erhöht die Hardwarekosten und verringert die Wirtschaftlichkeit der durch die grösseren Betreiber zu betreibende VoIP-Hardware. Somit haben die grossen Betreibern von VoIP-Hardware ein grosses wirtschaftspolitisches Interesse an SIP über UDP. Und meiden wie der "Teufel das Weihwasser" SIP über TCP oder gar SIPS (SIP mit TLS-Verschlüsselung). So findet man kaum VoIP-Anbietern im deutschsprachigen Raum, welche ohne Kostenzuschlag SIPS/SRTP über das Internet anbieten (DUS.net, EasyBell).

Dieser Artikel geht in dieses Thema ein, weist aber keine saubere Trennung zwischen Signalisierung (SIP) und Sprachkanal (RTP) auf:
https://www.onsip.com/blog/sip-via-udp-vs-tcp
Im Gegensatz zum Sprachkanal (RTP) bestehen für die Signalisierung (SIP) keine Echtzeitanforderungen, deshalb kann SIP über TCP realisiert werden.

Ich erwarte, dass sich im Bereich VoIP-Telefonie dasselbe wiederholt wie beim E-Mailversand über das Netzwerkprotokoll SMTP:

Es gab ein Zeitalter, wo alle E-Mails vom E-Mailclient unverschlüsselt zum Mailserver versendet wurden (SMTP => TCP Port 25/587). Und heute leben wir im Zeitalter, wo (aus guten Gründen) alle E-Mails verschlüsselt vom E-Mailclient zum Mailserver versendet werden (SMTPS => mit TLS auf TCP Port 465 oder mit STARTTLS auf TCP Port 587).

Eine sehr ähnliche Problematik besteht ja auch im Bereich "DNS". Auch für DNS bestehen keine Echtzeitanforderungen. Für DNS-Server gilt das Sprichwort: "A busy name server is a happy name server". Quelle:
https://securityblog.switch.ch/tag/powerdns/

Deshalb läuft der grösste Teil des DNS-Datenverkehrs über UDP Port 53. Im Bereich "DNS" erwarte ich aus Sicherheitsgründen den weitläufigen Einsatz von DNSSEC. DNSSEC erfordert aber die Unterstützung von DNS über TCP (RFC 7766 => TCP Port 53). Siehe auch:
http://www.lancom-forum.de/lancom-featu ... 16059.html

https://tools.ietf.org/html/rfc7766

Aus Datenschutzgründen ist der Einsatz von DNS mit TLS-Verschlüsselung (RFC 7858 => TCP Port 853) erforderlich:
https://tools.ietf.org/html/rfc7858

https://www.golem.de/news/dns-ueber-tls ... 30827.html

https://www.heise.de/newsticker/meldung ... 18634.html
Antworten