LC 1722 VOIP, ... geht QOS überhaupt?
Moderator: Lancom-Systems Moderatoren
LC 1722 VOIP, ... geht QOS überhaupt?
Hallo,
ich habe gerade einen DSL Ausfall und die ISDN Backup Line ist aktiv. Laut Lanmonitor stehen 62 kBit zur Verfügung und reserviert ist aktuell nichts davon. OK, es wird noch gesurft etc., aber ein VOIP Telefonat sollte ja möglich sein, oder nicht?
Unter Firewall/QOS habe ich eingestellt, daß für einen SIP Call 32 kBit garantiert werden sollen. Versuche ich ein Gespräch über SIP zu führen sagt mir Lanmonitor, daß zuwenig Bandbreite verfügbar ist. Was könnte denn da noch schief gelaufen sein?
Viele Grüße,
Paul
ich habe gerade einen DSL Ausfall und die ISDN Backup Line ist aktiv. Laut Lanmonitor stehen 62 kBit zur Verfügung und reserviert ist aktuell nichts davon. OK, es wird noch gesurft etc., aber ein VOIP Telefonat sollte ja möglich sein, oder nicht?
Unter Firewall/QOS habe ich eingestellt, daß für einen SIP Call 32 kBit garantiert werden sollen. Versuche ich ein Gespräch über SIP zu führen sagt mir Lanmonitor, daß zuwenig Bandbreite verfügbar ist. Was könnte denn da noch schief gelaufen sein?
Viele Grüße,
Paul
Wer Schreibfehler findet darf sie behalten
Hallo,
wenn du einen 1722 oder ien Geröt mit VoIP CallManager hast, dann brauchst du keine seperate QoS Regel mehr in der Firewall erstellen!
Hier reicht es auch auf der SIP-Leitung unter Qualitöt/Bandbreite die gewünschte Stufe einzustellen. Beachte 64kbit/sec Sprachdaten sind 80kbit IP-Daten. Weiter kannst du unter VCM--> Erweitert Unterpunkt QoS die sonstigen Paremter konfigurieren
Dein ISDN-Backup hat nur eben diese 64KBit physikalischer Bandbreite, daher wird es mit einem Gesoräch mit entsprechenden Codec beim ISDN-Backup eng. Die Reservierung würde dann nich tlaufen (dann wird mehr Bandbreite für dne Call reserviert, als die Leitung bietet) oder die zweite möglichkeit besteht darin, dass die fpr die anwendung zu resiervierende Bandbreite auch beim ISDN-Backup ausreicht aber weitere Reservierungen nicht mehr (additiv) vorgenommen werden können.
Daselbe gilt für den Fall, wenn du DSL-1000 hast dafür deine Banbreite eingeteilt hast und nun auf ISDN-Backup zurückfällst, dann wird die gesamte ISDN Bandbreite für die erste Reservierung nicht aktiv, sobald sie die die Gesamtbandbreite der Leitung überschreitet.
Welche RX Reservierung steht denn bei DSL bei einem VoIP-Gesräch im LANMonitor?
Hast du ggf. eine doppelte Reservierung pro Verbindung aktiv?
Besser ist es nur die QoS Funktion des VCM zu nutzen und nicht noch zusätzliche eigene Regeln. Das kann solche Probleme vermeiden.
wenn du einen 1722 oder ien Geröt mit VoIP CallManager hast, dann brauchst du keine seperate QoS Regel mehr in der Firewall erstellen!
Hier reicht es auch auf der SIP-Leitung unter Qualitöt/Bandbreite die gewünschte Stufe einzustellen. Beachte 64kbit/sec Sprachdaten sind 80kbit IP-Daten. Weiter kannst du unter VCM--> Erweitert Unterpunkt QoS die sonstigen Paremter konfigurieren
Dein ISDN-Backup hat nur eben diese 64KBit physikalischer Bandbreite, daher wird es mit einem Gesoräch mit entsprechenden Codec beim ISDN-Backup eng. Die Reservierung würde dann nich tlaufen (dann wird mehr Bandbreite für dne Call reserviert, als die Leitung bietet) oder die zweite möglichkeit besteht darin, dass die fpr die anwendung zu resiervierende Bandbreite auch beim ISDN-Backup ausreicht aber weitere Reservierungen nicht mehr (additiv) vorgenommen werden können.
Daselbe gilt für den Fall, wenn du DSL-1000 hast dafür deine Banbreite eingeteilt hast und nun auf ISDN-Backup zurückfällst, dann wird die gesamte ISDN Bandbreite für die erste Reservierung nicht aktiv, sobald sie die die Gesamtbandbreite der Leitung überschreitet.
Welche RX Reservierung steht denn bei DSL bei einem VoIP-Gesräch im LANMonitor?
Hast du ggf. eine doppelte Reservierung pro Verbindung aktiv?
Besser ist es nur die QoS Funktion des VCM zu nutzen und nicht noch zusätzliche eigene Regeln. Das kann solche Probleme vermeiden.
12x 1621 Anx. B-21x 1711 VPN-3x 1722 Anx. B-7x 1723 VoIP-1x 1811 DSL, 1x 7011 VPN-1 x 7111 VPN-1x 8011 VPN-10er Pack Adv. VPN Client (2x V1.3-3x 2.0)-Hotspot Option-Adv. VoIP Client/P250 Handset-Adv.VoIP Option-4x VPN-Option-2x L-54 dual-2x L54ag-2x O-18a
Hallo,
Danke für die schnelle Antwort. Also ich habe bei allen SIP Accounts im VCM auf Optimierung der Bandbreite gestellt. Die eigene Regel in Firewall/Qos habe ich deaktiviert. Im VCM habe ich für abgehende und ankommende Pakete "Reduktion der PMTU" eingestellt. Reduzierte Paket-Größe steht noch per default auf 512 Byte. Trotzdem kann ich keinen SIP-Call starten. Und da ich ihn mit der Meldung "Bandbreite nicht verfügbar" nicht starten kann, kann ich auch die Frage beantworten, wieviel im Lanmonitor reserviert würde, wenn es ginge...
Ich hoffe zwar, dass der DSL Ausfall nicht ewig dauert, aber andererseits möchte ich ihn jetzt nutzen dieses Problem zu lösen.
...editiert... gerade ist DSL wieder verfügbar. Reserviert werden bei einer SIP Verbindung 10 kBit/s in beide Richtungen. Mir ist jetzt noch weniger erklärbar, warum ich dann über ISDN Backup nicht telefonieren konnte. Der Router läuft mit der Firmware 6.24.0012. Irgendwelche Ideen?
Grüße,
Paul
Danke für die schnelle Antwort. Also ich habe bei allen SIP Accounts im VCM auf Optimierung der Bandbreite gestellt. Die eigene Regel in Firewall/Qos habe ich deaktiviert. Im VCM habe ich für abgehende und ankommende Pakete "Reduktion der PMTU" eingestellt. Reduzierte Paket-Größe steht noch per default auf 512 Byte. Trotzdem kann ich keinen SIP-Call starten. Und da ich ihn mit der Meldung "Bandbreite nicht verfügbar" nicht starten kann, kann ich auch die Frage beantworten, wieviel im Lanmonitor reserviert würde, wenn es ginge...
Ich hoffe zwar, dass der DSL Ausfall nicht ewig dauert, aber andererseits möchte ich ihn jetzt nutzen dieses Problem zu lösen.
...editiert... gerade ist DSL wieder verfügbar. Reserviert werden bei einer SIP Verbindung 10 kBit/s in beide Richtungen. Mir ist jetzt noch weniger erklärbar, warum ich dann über ISDN Backup nicht telefonieren konnte. Der Router läuft mit der Firmware 6.24.0012. Irgendwelche Ideen?
Grüße,
Paul
Wer Schreibfehler findet darf sie behalten
Da gibt es kein Problem zu loesen. Die Erklaerung hat ittk Dir schon gegeben. Die Bandbreite reicht nicht fuer einen Call aus. Also wird keine Verbindung aufgebaut. Vermutlich wird als Codec G.711 verwendet, der selber fuer RTP 64 kBit/s benoetigt, da reicht eine ISDN Internet Verbindung nicht aus.Ich hoffe zwar, dass der DSL Ausfall nicht ewig dauert, aber andererseits möchte ich ihn jetzt nutzen dieses Problem zu lösen.
Mach einfach im Telnet mal einen Trace "tr # call sip", da wirst Du dann sehen was reserviert wird. Das LANCOM muss immer zuerst versuchen die Bandbreite fuer den groessten erlaubten Codec zu reservieren (wenn Du G.711 noch erlaubt hast, wird es dieser sein).
Wenn Dein Provider G.729 zulaesst, deaktiviere alle Codecs ind der Konfiguration, ausser G.729 und teste noch mal.
Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
Hallo Louis,
dein Beitrag klingt als Erklärung zwar logisch, aber nicht sinnvoll. Wenn für die Leitungen eingestellt wurden daß SIP Verbindungen mit minimaler Bandbreite hergestellt werden sollen, dann macht es keinen Sinn, wenn der Router zuerst versucht die Bandbreite für den größten erlaubten Codec zu reservieren. Das würde ich bei einem VOIP Router mit ISDN Backup Funktion als Fehler im Softwaredesign bezeichnen.
Trotzdem vielen Dank, wenn DSL mal wieder ausfällt, versuche ich es mal, alle Codecs die mehr als 16kBit brauchen zu deaktivieren.
Viele Grüße,
Paul
dein Beitrag klingt als Erklärung zwar logisch, aber nicht sinnvoll. Wenn für die Leitungen eingestellt wurden daß SIP Verbindungen mit minimaler Bandbreite hergestellt werden sollen, dann macht es keinen Sinn, wenn der Router zuerst versucht die Bandbreite für den größten erlaubten Codec zu reservieren. Das würde ich bei einem VOIP Router mit ISDN Backup Funktion als Fehler im Softwaredesign bezeichnen.
Trotzdem vielen Dank, wenn DSL mal wieder ausfällt, versuche ich es mal, alle Codecs die mehr als 16kBit brauchen zu deaktivieren.
Viele Grüße,
Paul
Wer Schreibfehler findet darf sie behalten
Das werde ich nicht so bezeichnen, das ist aeusserst sinnvoll, wenn man verstanden hat wie SIP/RTP funktioniert!dein Beitrag klingt als Erklärung zwar logisch, aber nicht sinnvoll. Wenn für die Leitungen eingestellt wurden daß SIP Verbindungen mit minimaler Bandbreite hergestellt werden sollen, dann macht es keinen Sinn, wenn der Router zuerst versucht die Bandbreite für den größten erlaubten Codec zu reservieren. Das würde ich bei einem VOIP Router mit ISDN Backup Funktion als Fehler im Softwaredesign bezeichnen.

Du hast ja nur "minimale Bandbreite" ausgewaehlt! Damit teilst Du einfach mit, das sofern moeglich" aus allen angebotenen Codecs fuer ein Gespraech der kleinste Codec verwendet werden soll. Wenn nun z.B. G.711 der einzige Codec ist, dann IST dies der Codec mit der niedrigsten Bandbreite! In Deinem Fall werden bestimmt mehrere Codecs fuer das SIP Gespraech angeboten und G.711 wird dabei sein. Zu dieser Zeit weiss das LANCOM aber noch nicht welcher Codec tatsaechlich fuer das Gespraech gewaehlt wird, es muss aber schon eine Reservierung gemacht werden, also wird hier die Bandbreite fuer den groessten Codec ausgewaehlt! Wenn dann der tatsaechliche Codec im SIP ausgehandelt worden ist, wird die Reservierung ggf. nach unten korrigiert.
Haettest Du, wie ich Oben geschrieben habe, alles ausser G.729 abgeschaltet und noch einmal probiert, so haettest Du auch auf der ISDN Leitung telefonieren koennen.
Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
Das würde ja bedeuten, dass ein Designfehler im SIP/RTP Protokoll vorliegt. Ich kenne die Protokolle nicht im Detail, aber dieselben Probleme hat man schon vor annähernd 20 Jahren beim Handshake zum Aufbau von Modem-Verbindungen gelöst. Wenn die Bandbreite ein begrenzender Faktor ist, der über Erfolg oder nicht eines Verbindungsaufbas entscheidend ist, dann muß der Verbindungsaufbau vom worst case ausgehend sich zum gewünschten Optimum hin "verhandeln" können. Man kann so ein Problem auch andersrum lösen, aber nur dann, wenn Protokollverhandlungen retries erlauben, also wenn bei gescheitertem Verbindungsaufbau erneut versucht werden kann, bis es klappt. Also mir kann keiner sagen, daß das Problem nicht lösbar ist.
Ciao, Paul
Ciao, Paul
Wer Schreibfehler findet darf sie behalten
Versteh doch mal, dass Du keine Bandbreite eingeschraenkt hast, indem Du "minimale Bandbreite" ausgewaehlt hast. Du hast damit nur gesagt, dass aus allen angebotenen Codecs derjenige mit der kleinsten Bandbreite bevorzugt genommen werden soll. Es werden aber nach wie vor alle moeglichen Codecs angeboten, auch der mit der groessten Bandbreite. Wenn Du dies nicht moechtest, dann musst Du eben die unerwuenschten Codecs mit grosser Bandbreite ausfiltern, indem Du diese in der Konfiguration des LANCOM (oder beim SIP-Client) abschaltest.
Ciao
LoUiS
Ciao
LoUiS
Dr.House hat geschrieben:Dr. House: Du bist geheilt. Steh auf und wandle.
Patient: Sind Sie geisteskrank?
Dr. House: In der Bibel sagen die Leute schlicht "Ja, Herr" und verfallen dann ins Lobpreisen.
Ich habe nie behauptet, daß ich Bandbreite eingeschränkt habe. Physikalische Umstände schränken Bandbreite ein. Das ist nun mal so. Jeder möchte natürlich immer die komfortabelste Bandbreite, da es aber sich verändernde physikalische Bedingungen gibt (ISDN Fallback ist nur eine von vielen Ursachen), brauchen wir ein Bandbreitenmanagement. Und das lässt sich nur sinnvoll technisch realisieren, indem man anhand der Wünsche und der sich verändernden technischen Gegebenheiten (verfügbare Bandbreite) den möglichen gewünschten Zustand erreicht. Das könnte sogar bedeuten, wenn ich gewählt hätte, ich möchte maximale Sprachqualität, daß der Router im worst case eine Verbindung mit dem sparsamsten Codec herstellt und das auch kann. Nur diese Betrachtungsweise macht Sinn. Ein Gerät, das nicht in der Lage ist, eine technisch mögliche Verbindung herzustellen, weil es von der optimalen Seite her anfängt zu testen und dann abbricht ist eine Fehlentwicklung. Ob nun die Protokolle eine Fehlentwicklung sind oder der Router mal dahingestellt, Deinen Ausführungen nach sind es ja die Protokolle.
Ciao, Paul
Ciao, Paul
Wer Schreibfehler findet darf sie behalten
Hallo,paulinus hat geschrieben:Hallo Louis,
Trotzdem vielen Dank, wenn DSL mal wieder ausfällt, versuche ich es mal, alle Codecs die mehr als 16kBit brauchen zu deaktivieren.
das kannst du einfacher haben, da die DSL-Verfügbarkeit schon recht hoch ist.
Zeieh einfach den Stecker vom Splitter aus dem DSL-Modem und scoon kannst du deine Konfiguration, wie LoUiS schon völlig richtig beschrieben hat, abändern und zwar so, dass auf deiner SIP-Leitung nur die Codecs erlaubt sind, die die minimalste Bandbreite erfordern. Im Idealfall lässt du außschließlich den Codec G729a zu.
12x 1621 Anx. B-21x 1711 VPN-3x 1722 Anx. B-7x 1723 VoIP-1x 1811 DSL, 1x 7011 VPN-1 x 7111 VPN-1x 8011 VPN-10er Pack Adv. VPN Client (2x V1.3-3x 2.0)-Hotspot Option-Adv. VoIP Client/P250 Handset-Adv.VoIP Option-4x VPN-Option-2x L-54 dual-2x L54ag-2x O-18a