1781VAW und QoS für VoIP

[ArPa]

Nabend zusammen,

wir werden in den nächsten Tagen komplett auf VoIP bei Placetel wechseln.

Hat hier jemand schon Erfahrungen mit einer klugen Einrichtung von QoS Regeln für VoIP?

Richtet man da für jedes Telefon eigene Regeln ein, also über die IP des Endgerätes oder eher über die Protokolle.

Wie habt ihr das bei euch erfolgreich umgesetzt?

[pat4fly]

Wenn die Telefone in einem bestimmten IP-Bereich liegen, brauchst Du die Regeln für diesen Bereich nur einmal erstellen. Ich habe der SIP-Verbindung 1kbit/s, und den RTP-Verbindungen 80 kbit/s pro Session reserviert. Klappt und klingt wunderbar

Zur Übersichtlichkeit habe ich bei mir erstmal Objekte angelegt: ein Stationsobjekt für die Telefon-IPs, QoS-Elemente für SIP und RTP, Dienstobjekte für SIP und RTP. Damit sind die Regeln dann ziemlich einfach zu erstellen, und wenn sich z.B. die IPs mal ändern, musst Du nur das Objekt ändern und nicht alle Regeln.

[ArPa]

Danke. Klingt schon mal nicht dumm

Von diesem ominösen SIP-ALG hälst Du also nichts?

[pat4fly]

Eigentlich halte ich sehr viel davon - wenn es funktionieren würde. Aber im Moment kenne ich mehrere Leute (mich eingeschlossen), bei denen es entweder schlecht oder gar nicht funktioniert. Darum ist er bei mir ausgeschaltet - die Regeln einzurichten dauert aber nicht mehr als 5 Minuten, wenn man die zu öffnenden (und weiterzuleitenden) Ports kennt.

[ArPa]

Okay, danke... Ich lese nur hin und wieder auch von Leuten bei den SIP-ALG angeblich einwandfrei funktioniert... Andererseits gibts im Netz auch viele Artikel in denen empfohlen wird dieses abzuschalten, wenn man Probleme mit der VoIP Telefonie feststellt... Nicht nur Lancom auch andere Hersteller sollen damit Schwierigkeiten haben...

Wie immer wird es wohl auf einen Versuch ankommen, oder?

Sonst noch jemand der erfolgreich oder weniger erfolgreich VoIP mit diesem oder einem ähnlichen Lancom Gerät implementiert hat?

[ArPa]

Also so richtig läuft das ganze hier noch nicht, obwohl ich es mir erstmal einfach gemacht habe und zum Testen die Allow-All Firewall eingerichtet hab.

Ich teste derzeit mit der Gigaset N510 IP Pro Basis und einem Handset. Habe ich im N510 den STUN Server der Telekom aktiviert, kann nicht raus telefonieren.

Deaktiviere ich den STUN Server sieht es besser aus. Dann werde ich allerdings über einkommende Anrufe informiert, abheben bringt dann aber nur Stille....

Wie gesagt ist die Firewall offen. An Ports kann es eigentlich also nicht liegen!?

[MoinMoin]

Moin ArPa!

Hast du denn jetzt den SIP-ALG an oder nicht?

Ciao, Georg

[ArPa]

Moin ArPa!

Hast du denn jetzt den SIP-ALG an oder nicht?

Ciao, Georg

Damit hab ichs gerade getestet... Wenn ich es einschalte, geht erst mal gar nichts. Sowohl Router als auch Basis muss ich dann rebooten. Danach gehts aber auch sehr instabil... Starte ich zwischendrin mal die Basis neu, geht es mal, mal gehts nicht, mal registriert sich der VOIP Account nicht... Also ziemlich unkontrollierbar irgendwie...

Was mich eigentlich ziemlich wundert, denn mit einer Allow-All Firewall Strategie derzeit, dürfte es doch solche Probleme garnicht geben!?!?!

Sind halt hier im Moment ziemlich im Stress, müsste mir mal Zeit nehmen komplett auf Deny-All zu switchen und dann korrekt freigeben mit deaktiviertem SIP-ALG...

Aber wie gesagt, so recht schlüssig ist das mit dem Router nicht, bei der aktuellen Konfiguration...

[MoinMoin]

Moin ArPa,

ich frag nur wegen:

SIP ALG an => STUN aus
SIP ALG aus => STUN an

Wenn du mit einer Maskierten Internetverbindung arbeitest, reicht es nicht aus, die Firewall auf Durchzug zu schalten. Du mußt trotzdem Maskierungsregeln anlegen, die ankommende SIP-Pakete passend weiterleiten. STUN sorgt dafür, daß die Adressen und Ports korrekt gestezt werden, hält die Ports aber nicht offen.

Die Registrierung sollte mit STUN und ohne SIP ALG einwandfrei funktionieren, abgehende Rufe eigentlich auch, sofern die RTP-Streams von deinen Geräten im lokalen Netz ausgehend aufgebaut werden. Ankommende Rufe und RTP-Streams schluckt die Maskierung, sofern keine passenden Weiterleitungen konfiguriert sind.

Ciao, Georg

[cpuprofi]

Hallo Georg,

...Wenn du mit einer Maskierten Internetverbindung arbeitest, reicht es nicht aus, die Firewall auf Durchzug zu schalten. Du mußt trotzdem Maskierungsregeln anlegen, die ankommende SIP-Pakete passend weiterleiten. STUN sorgt dafür, daß die Adressen und Ports korrekt gestezt werden, hält die Ports aber nicht offen.
Die Registrierung sollte mit STUN und ohne SIP ALG einwandfrei funktionieren, abgehende Rufe eigentlich auch, sofern die RTP-Streams von deinen Geräten im lokalen Netz ausgehend aufgebaut werden. Ankommende Rufe und RTP-Streams schluckt die Maskierung, sofern keine passenden Weiterleitungen konfiguriert sind...

Kannst Du das mit den "Maskierungsregeln anlegen" und den "passenden Weiterleitungen konfiguriert sind" mal an einem Beispiel genauer erklären?

"Port-Forwarding" kann ich mir ja noch erklären, aber wie sollen denn so die "Maskierungsregeln" aussehen?

...STUN sorgt dafür, daß die Adressen und Ports korrekt gestezt werden, hält die Ports aber nicht offen...

Aus der SNOM-Wiki:

NAT Settings(Section): STUN Interval
DESCRIPTION Sets the STUN interval time in seconds. After its expiration a new STUN requests will be send out. If it results in another IP/port the identity will be re-registered.

NAT Settings(Section): Keepalive interval (seconds)
Specifies the number of seconds after which a new keepalive message will be sent out to the Registrar/Proxy port in order to have the port stay open and the phone remain reachable.

Das "Keepalive interval" steht in den Einstellungen genau unter dem "STUN Interval", gehört es somit noch zum STUN oder ist dieses eine separate Funktion?

Kläre mich bitte auf.

Grüße
Cpuprofi

[Jirka]

Moin MoinMoin,

Wenn du mit einer Maskierten Internetverbindung arbeitest, reicht es nicht aus, die Firewall auf Durchzug zu schalten.

wenn man ansonsten alles richtig macht, reicht das mit Sicherheit aus...
Einfach mal im Status/IP-Router/Open-Port-Liste schauen, da stehen dann die IP-Telefone mit Ziel-Port 5060 drin.

Du mußt trotzdem Maskierungsregeln anlegen, die ankommende SIP-Pakete passend weiterleiten. STUN sorgt dafür, daß die Adressen und Ports korrekt gesetzt werden, hält die Ports aber nicht offen.

Nein, das machen mit STUN im IP-Telefon verknüfte Dienste, die dann z. B. "NAT-Refreshzeit" heißen. Mit dem Ergebnis, dass der Port offen bleibt. (Solange die dort eingestellte Zeit kleiner oder gleich groß ist wie die UDP-Aging-Zeit, die im LANCOM hinterlegt ist (Default 20 Sekunden).) Technisch wird einfach ein SIP-Packet ohne Inhalt an den SIP-Server geschickt, wo die Registrierung erfolgte, so bleibt der Port wieder 20 Sekunden offen (bei Default-Wert).

Viele Grüße,
Jirka

[ArPa]

Naja wie gesagt, irgendwie deckt sich nach meiner ersten Erfahrung mit dem SIP-ALG Häkchen doch so die Meinung die hier allgemein herrscht... So ganz kalkulierbar ist das für mich nicht...

Deshalb hab ich mir jetzt erstmal ne Stunde Zeit genommen das mit ner ordentlichen DENY-ALL Strategie und dann Firewall Regel zu gestalten...

Hier der erste Wurf... Könnt ja mal durch schauen ob das so für euch klug erscheint

Lancom Firewall:


N510 IP Pro:


N510 IP Pro:

[ArPa]

Hmmm... Also keine Meinungen? Wahrscheinlich ein gutes Zeichen