VoIP über VPN schützen (AVM 7270)

also ich könnte mir auch vorstellen das es einfach zu lange dauert wenn man das ganze noch in einem VPN verpackt. Denn man muss die ganzen Pakete dann ja verschlüsseln und versenden. Je nachdem wie das VPN aufgebaut ist wird das aber TCP als Protokoll nehmen - SIP verwendet dagegen idR. UDP (da eine retransmission bei VoIP eh keinen Sinn ergibt).

Hier holt man sich also gleich einige blinde Passagiere an Board. Bei TCP erwarte ich ein ACK-Paket nach $WINDOW_SIZE. Darauf muss ich warten - und solange geht kein neues Paket durch den Tunnel. Bei VoIP schon schlecht. Dazu muss ich noch damit leben das ggf. der VPN-Router versucht seine Pakete vollzubekommen bevor er die auf die Reise schickt - d.h. ca. 1500 Bytes/Paket. Bei VoIP is mir aber egal wie groß das Paket ist - es muss nur schnellstens raus.

Von daher würde ich mal behaupten das eine VPN-Verbindung hier ggf. zu Problemen führt die später sehr schwer zu bestimmen sind. Denn es kann durchaus sein das z.B. eine Person grad spricht und alles ist gut. Geht aber die zweite Person in nen Gespräch dann wird es ggf. schon problematisch...

Bei Verwendung von G711 Codecs beträgt die verwendete Bandbreite 64 kbit/s. Also auch wenn 10 Gespräche gleichzeitig geführt werden ist die Belastung minimal so das auch einfache VPN Consumer DSL Router das problemlos beherrschen.
Firewalls oder VPNs auf leistungsfähiger Hardware dann entsprechend mehr.
Sehr oft nutzen VoIP Anlagen G729 Codecs wenn sie über Internetverbindungen gehen und dann mit 8 kbit eine noch geringere Bandbreite mit entsprechend mehr möglicher Kapazität.
Das sollte also wirklich kein Kriterium sein wenn man nicht gerade über einen Voice Server redet der 3000 Anschlüsse bedienen muss !

Moin,

mir ging es nicht um die Bandbreite -> die ist heute eher selten das Problem... Ich mein - wir haben selbst im Home-User-Bereich schon idR. nen Mbit oder mehr an Upload -> da feuer ich dir notfalls sogar noch nen kleines Bild von der Webcam mit rüber ;).

Mir geht es eher darum das eben das TCP-Protokoll für Realtime nicht wirklich geeignet ist. Nehmen wir an auf der Leitung ist irgendwo ein kleines Problem -> dann würde man ständig auf retransmissions warten. Die sind aber für VoIP völlig unsinnig -> wenn ich meinem Gegenüber "Hallo Mike" sage dann wäre es (ganz platt ausgedrückt) besser wenn der nur "Hall Mike" versteht - statt das er darauf warten muss bis das "o" neu angefordert wurde. Denn man hat eben nur ca. 300 ms Zeit bis das Paket beim Empfänger ankommen muss -> da ist kein Spielraum für nen Timeout bzw. für das neue Anfordern von Paketen...

Weiterhin sehe ich das Problem darin das man eben warten muss bis der VoIP-Router ggf. meint das er das Paket lossenden möchte. Denn der möchte sein Paket ja möglichst vollmachen - 1500 Byte. Nehmen wir den G.711 an -> 64.000 Bit/s -> 8000 Byte/s. Wenn also der Router meint er möchte immer warten bis er nen Paket voll hat bevor er es absendet -> dann dauert das schon ca. 250 ms (ich geh mal davon aus das wir 1000 Byte/s an Overhead zusammenbekommen). Ich warte also 250 von 300 ms nur darauf das der Router das VPN-Paket überhaupt absendet. DAS dürfte einem Gespräch sehr abträglich sein (man würde dann ja im Endeffekt "Ha", 250ms pause "ll" 250ms pause "o " 250 ms pause... bekommen).

Daher sehe ich das eher als problematisch wenn man solche Realtime-Protokolle noch in anderen Protokollen verpackt. Man kann das sicherlich testen - aber ob ich dem im Live-Betrieb dann so trauen würde steht auf nem anderen Blatt...

Technisch richtig, keine Frage aber als Ausweg zum VPN gibts dann nur die Verwendung von SRTP.

ohne frage - ja... Ich sag mal so: Was bringt es eine Lösung zu bauen mit der die Leute nicht wirklich telefonieren können? Wenn ich im Büro sowas aufbaue dann intressiert es keinen Sachbearbeiter ob die Verbindung gesichert ist oder nicht - wichtig ist das der mit dem Kunden telefonieren kann und die Sprachqualität gut ist.

Und beim Telefon haben die Leute immer wenig Verständnis - hier wird eine Verfügbarkeit von 100% einfach vorrausgesetzt. Wenn es also durch sowas zu Gesprächsabbrüchen oder Spracheinbußen kommt - dann würde ich mir eher einen Anbieter suchen der eben SRTP anbietet oder andere Wege überlegen versuchen (eigene Anlage aufstellen etc...). Aber ich würde NIE versuchen das per VPN zu tunneln und mir damit den Ärger ins Haus zu holen. Denn wenn man das einmal gemacht hat und das schief geht - dann ist man nur noch der "EDV-Frickler" der eh keine Ahnung hat... Und das hab ich immer versucht zu vermeiden ...