istike2
Goto Top

Sind 4 gleichzeitige VoIP-Gespräche über 2 Mbits Upload realistisch?

Hallo,

wir habe hier einen KabelBW-Zugang mit 2,1Mbits Upload, das Schnellste was wir mit einem normalen Vertrag haben können.

Ist es realtisch hier einen VoIP-Server zu bertreiben?

Ein Büro aus Frankreich würde sich durch openVPN anschließen (Nur VoIP). Dies bedeutet, dass all bürointerne Gespräche (max. 2 gleichzeitig: 64Kbits x4 = ca. 300Kbits) stets von diesem Server managed wären. Es gibt ein Büro in Ungarn - angeschloßen genauso über OpenVPN der pfSense oder VPN der Fritzbox - mit seltenen Gesprächen (2x64Kbits = ca. 130Kbits). Es würde ggfs. auch etwas auslasten. Dann gibt es noch Kollegen die unterwegs auch mit Notebook und entsprechend mit OpenVPN das Bandbreite auslasten würden. Neben den VoIP-Gesprächen, die so Alles in Allem max. 4x2x64Kbits = 512Kbits verbtrauchen würden würden natürlich auch Surfen. E-mails und SMB die Bandbreite benutzen müssen.

Die Schwierigkeit liegt darin VOIP bei allen Verbindungen zu bevorzugen, keiner Verbindung zulassen die volle Bandbreite allein auszulasten.

Meine Fragen:

wie handhabt man es am intelligentesten, dass:

- die Anzahl der OpenVPN-Zugänge nicht eingeschränkt wird?
- in einem OpenVPN-Kanal VoIP immer Vorrang hat?
- wenn nur ein OpenVPN-Zugang aktiv ist, diese die gesamte Bandbreite automatisch bekommt.
- die Büroarbeiter des deutschen Büros die freie Bandbreite automatisch benutzen können.

Jetzt am Anfang steht nur Serverseitig ein pfSense-FW zur Verfügung. Später werden alle Büros einen haben.

Hat jemand praktische Tipps für die Umsetzung?

Danke sehr.

Gr. I.

Content-Key: 180003

Url: https://administrator.de/contentid/180003

Printed on: April 19, 2024 at 08:04 o'clock

Member: MrNetman
MrNetman Feb 03, 2012 at 12:35:54 (UTC)
Goto Top
Hallo Istike,

lass uns mal rechnen. Ein Gespräch braucht 64 kBit/s + IP-Frames +RTCP = etwa 80kBit/s. Danach kommt noch der VPN
4 Gespräche 320 kBit/s + etwas Reserve. Danach kommt noch der VPN Overhead, der ja nochmal wenigstens 15kBit/s ausmacht >=95kBit/s pro Gespräch und Richtung. Skype braucht etwas mehr Bandbreite (100 bis 120kBit/s), da es einen breitbandigeren Codec fahren kann.
Das Problem könnte aber am VPN liegen. Die Laufzeiten werden durch das Packen und Entpacken weiter gesteigert. Ab einem gewissen Delay ist man oft nicht mehr bereit sicher zu telefonieren.

Das schöne an VoIP ist, dass man das schon mal ausprobieren kann. Dann kann man die RTCP Protokolle und die Sprachverständlichkeit über bewerten. Es muss natürlich mitgeschnitten werden.

Meine Erfahrungen mit vielen Codec- und Medienumsetzern sind zweispältig. Frankreich Voip G711 - VPN - Internet - VPN-G711 - Asterisks-G711 - VoiP Provider - PSTN - Kunde mit Voip Analogtelefon ISDN und interner Telefonanlage.
Dazu kommen noch eventuelle Abweichungen bei den Übertragungscodecs wie G729 und Mobilfunkbetrieb.


Gruß
Netman
Member: istike2
istike2 Feb 03, 2012 at 16:03:50 (UTC)
Goto Top
Danke!

Ok. Ich rechne mal mit 100Kbits --> 800Kbits was noch drin wäre, wenn ich vernünftiges QoS bei allen Verbindungen gewährleisten könnte.

Wir haben ein ziemlich komplexe Struktur schon jetzt, wir hosten aber die Anlage bei PBXes... Ohne VPN mit 100Mbits haben wir natürlich keine Probleme.

Gr. I.
Member: aqui
aqui Feb 04, 2012 at 13:35:09 (UTC)
Goto Top
Die generelle Frage die sich stellt ist warum du nicht die Telefon Anlage so einrichtest das sie für die VoIP über das WAN bzw. das VPN den G.729 Codec benutzt. Das kann jede VoIP Anlage heutzutage mit 3 Mausklicks.
Damit reduzierst du die Bandbreite auf ca. 8 kBit/s pro Gespräch und hast GSM (Mobilfunk) Qualität. Der 729er Codec wird auch in GSM Netzwen verwendet.
Damit reduzierst du die bandbreite und QoS Anforderungen erheblich bei minimalem Sparchqualitäts Verlust.
Bist aber alle deine Bandbreitensorgen los.
Nur mal zum Vergleich: Eine klassische S2m ISDN Anlage hat ein 2 Mbit Anbindung und behandelt damit 30 ! gleichzeitige Verbindungen mit 64 kBit. Da kannst du dir also leicht selber ausrechnen wo du landest bei 4 popeligen Verbindungen. Mit ein klein wenig QoS Priorisierung im Router ist das also leicht handhabbar.
Wo ist also wirklich dein Problem ?