UMD-Pro: Erfahrungen mit IP-Telefonie

Tolles Bild, hilft nur leider zu wenig, da die Netzkonfig im Detail fehlt, ...

aber ich habe eine weitere Idee:

Die FBen machen bei SIP Calls eine QoS Datenerfassung.

Du könntest jetzt mal in der FB guggen, welche Werte Du hast.

Die Werte kann man sich via Push regelmäßig zusenden lassen.

Sie müssten auch unter: Telefonie -> Eigene Rufnummern -> Sprachübertragung zu finden sein (siehe Bild).

Die Kunst wäre jetzt immer DIESE GESPRÄCHE zu finden, die Probleme machten. Dann mal die Werte kontrollieren.

Wenn Störungen vorhanden sind, dann sollten diese in den jeweiligen Gesprächsdaten sichtbar sein (z.B. hohe Jitterwerte oder Paketloss ....)

... noch ein paar Fragen:

Welche Bandbreite steht jeweils providerseitig zur Verfügung?

Wieviele Gespräche laufen im Mittel GLEICHZEITIG?

Welche Anwendungen laufen im Netz (die evtl. Dauerlast machen könnten)?
TK-System ist?

Okidoki. Schon mal ne Menge mehr Informationen:

Fax: Sip und Fax ist wie Feuer und Wasser ... das wird nix. Ich kenne keine professionelle Lösung via SIP die bei Fax > 9600 Baud noch funktioniert. Btw.: Wir haben vorletztes Jahr in unserer Firma (ca. 10 TMA) das Thema Fax beerdigt. Betroffen davon waren ca. 50.000 Kunden. Es gab nicht im Ansatz damit ein Problem. Ergo -> Fax für die Tonne.

Telefonie via Cloud: Das klingt jetzt schonmal GANZ anders, wie ich es ursprünglich verstanden habe.

Technologisch bedingt sind beide Provideranbindungen nicht optimal. Für VoIP ist aktuell im Bezug auf Qualität nur MPLS eine brauchbare Alternative.

5 Telefone machen in etwa 1 MBit/s Last (abhängig Codec - gaaaaanz grob geschätzt). D.h. die Bandbreite ist hier kein Problem, sondern tatsächlich QoS und das wirst Du weder über Kabel noch über xDSL gelöst bekommen. QoS macht nur dann Sinn, wenn Du eine lückenlose Ende-zu-Ende Signalisierung hin bekommst. In deinem Fall technologisch nicht in konstanter Qualität lösbar.
Lösungsansatz könnte sein, die Telefonie komplett vom restlichen Netzverkehr zu trennen und über eigene (Provider-) Leitungen zu fahren.

Cloud Telefonie: Ich würde an dieser Stelle mal mit dem Cloudanbieter sprechen. Evtl. können die eine bessere Lösung anbieten (z.B. über Separierung oder andere Codecs). Evtl. könnte der Einsatz eines lokalen Session Border Controllers das Problem etwas minimieren.

Dauerlast: Die von Dir beschriebenen Telefoniestörungen weisen auf Peakprobleme hin. Man könnte versuchen sie über Paket Shaper zu minimieren. Das hieße der restliche LAN Verkehr (ungleich Telefonie) wird runterpriorisiert und in der Bandbreite deutlich begrenzt. Wird sicherlich so keine optimal Lösung, aber besser als nix.

UDM pro kann kein Paket Shaping.

Paket Shaper gibts z.B. v. Blue Coat ... leider nicht ganz billig

Meinung/Gedankenspiel

QoS (Quallity of Service) ist wie vom Vorredner beschrieben nur im Intranet möglich, dies muss lückenlos konfiguriert sein. Angefangen vom Router (wenn er es kann) wie LANCOM z.B bis hin über die Switches.

Dort werden auch ausschließlich nur UDP Pakete priorisiert.

In der Best Praxis ist es so, das in großen Firmen das "Telefon" und "Produktiv" Netz von einander getrennt werden sollte. D.h es werden 2 verschiedene IP Adressbereiche konfiguriert 1x "Produktiv-Netz" 1x Telefon Netz "Physisch getrennt".

Dann kommt es stark auf die verwendeten Telefonanalagen an ob man mit Transport Netzen arbeitet oder auch nicht (getrennt lassen), ein Transport Netz wird benötigt damit die Clients die CTI-Software erreicht bekommen, damit die Calls über den PC bzw. über die WaWi oder sonstiges abgesetzt werden.

Dann ist immer die Frage wird der Call über TAPI abgesetzt oder über eine "CTI" (Mitgelieferte Software des TK-Anlagen Herstellers). Danach richten sich eigentlichen Netz Strukturen.

Wir selber betreiben in Mittelständigen Firmen Telefonanlagen mit bis zu 40 VoIP Telefonen, diese Firmen sind nicht groß genug, um denen die Finanzielle Bürde auf zu erlegen große und komplexe Netzwerke auf zubauen. Mit anderen Worten dort gehen 40-45 PCs, 10-15 Drucker, 1 Physischer und 2-4 Virtuelle Server ALLE durch das gleiche Netz. Dort gibt es keinerlei Störungen mit der Telefonie oder mit schlechten Netzwerk Transfair Zeiten.

Auch in diesen Firmen betreiben wir Faxgeräte via VoIP, diese müssen auf 9600 Baut stehen und Fehlerkorrektur muss aus sein! Da eine Fehlerkorrektur über VoIP nicht möglich ist! Aber es wird zunehmend Problematischer vernünftig über Kabel Leitungen zu faxen. Ich bin froh über jeden DSLer den ich kriegen kann, neben der VoIP Technik ist halt auch Kabel ein Problem Stichwort IPv4/IPv6 DS-Lite die obligatorischen 1-3 Seiten faxe gehen fast immer durch ! Sind es allerdings 15 - 40 Seiten dann wird es Problematisch.

Daher empfehlen wir auch immer Digital Fax zu versenden und zu empfangen. dazu gibt es mehr als genug Möglichkeiten heut zu Tage. Selbst die FritzBox kann faxe via Mail zustellen.

Was ich mit der gerade beschrieben Anekdote sagen möchte ist, hast du in deinem relativ "kleinen" Netz Probleme, ist dies an anderer Stelle zu suchen! Das hat nichts mit VoIP/QoS zu tun. Wenn du intern perfekt telefonieren kannst, ist auch alles in Ordnung! Hast du aber eine Flüchtige Internetleitung da UDP Pakete (User Datagram Protocol) sehr empfindlich sind was Leistungsschwankungen angeht. Was bei VPN Verbindungen auch gut zu beobachten ist. Gibt es Stress mit der VPN und diese ist richtig konfiguriert -> Leitung prüfen.

Der WAN 2 ist eine reine Backupverbindung und KEIN Load Balancer beim USG oder UDM. Mit der zweiten Leitung hätte man zwar einen Ausfallschutz was das Internet ausgehend angeht. Aber es nützt die nichts wenn der Kunde X Eingehende Dienste verwendet. Dann müsstest du ja immer in der Domainverwaltung bei Strato,1+1,GoDaddy,DomainCheck etc. Die Feste IP-Adresse anpassen oder den dyndns Eintrag "CNAME". Betreibt der Kunde einen Mailserver könnte man einen 2ten MX Anlegen aber naja....

Große Rede Lange Sinn, ist das Netzwerk gut durchdacht, bei Unsicherheiten Testumgebungen bauen und selber testen und los geht’s

Viele Grüße Loxor

Das ist ja auch einer der wesentlichen Unterschiede zu den Cloud und den on premise TK-Anlagen. Wir arbeiten viel mit Agfeo und das ASIP Protokoll ist so schmal und nicht spürbar. Ab einer gewissen Firmen Größe trennen wir das auch, bzw. auch bei Mittelständigen Unternehmen beraten wir dahingehend. Aber wie gesagt, manschmal lässt man dem Kunden eine gewisse Wahl und man bereitet Ihn auf Probleme vor. Wenn es keine gibt, um so besser!

Grüße

loxor

... ich lasse mal nicht unerwähnt, dass wir ca. 10.000 Telefone mit einigen älteren und neueren VoIP Anlagen betreiben und ich bei der Netzplanung mitverantwortlich war. (Siemens TK Systeme HiPath 4000 und Open Scape Voice inkl. großem Call Center uvm.)

Ansonsten unterschreibe ich die Statements der Vorredner

Meine Gedanken dazu:

Alarmanlage würde ich über UMTS/LTE/5G völlig separat signalisieren (das ginge dann auch bei Stromausfall)

DynDNS funktioniert beim UDM pro nicht ... zumindest kenne ich keine Positivmeldung dazu und meine Versuche damit sind ebenfalls gescheitert.

IPv6 funktioniert ebenfalls noch nicht brauchbar

Bridgemodem müsste dann sowas wie ein Vigor 165 oder ein Lancom sein

GRE und ESP funktioniert nach meinem Kenntnisstand ebenfalls noch nicht

Ich mache DynDNS Updates über das Synology. Das funzt stabil z.B. bei Selfhost.

Hello zusammen,

zur Alarmanlage möchte ich bemerken. Wir versuchen die Alarmanlagenbauer immer zu motivieren über ein GPRS/GSM Modem und die VoIP Leitung zu senden. Ist die Internetleitung gestört -> kommt eine SMS alles gut! = kein Problem.

Im Normalbetrieb wird Geld gesparrt da Infos über die Internetleitung versendet werden.

Hast du mal versuchst einen Exposed Host auf das USG zu lenken? Und anschließend noch eine Seperate Portfreigabe für das USG zu erstellen. Für das ESP und GRE Protokoll, so einen Fall hatte ich mal mit dem LANCOM advanced VPN Client 4 Windows. Ich habe das Notebook nicht mit dem LANCOM Router verbunden bekommen. Erst als ich dann in der FB neben dem Exposed Host das ESP Protokoll auf den LANCOM gelenkt habe, konnte sich der Client verbinden.

Vielleicht hilft dir diese Erfahrung, andauernt ein doppel NAT zu pflegen ist ja auch blöd.

Beste Grüße Loxor