Hallo,
um beim Übergang INTRANET <-> WAN (ISP) ein sauberes QoS-Trust-Boundary zu erzeugen, werden bei mir alle Pakete in-/outbound explizit DSCP-umgetaggt.
Übliche DSCP-Flags sind CS3 (AF31 legacy) für SIP-Signalling und EF für RTP. (Cisco-Default, Aspect Uniphi Empfehlung, ) Ansonsten sind empfohlene Werte zwischen DSCP 24..31, d. h. alle mit IP-Precedence 3.
Wenn LCOS 7.22 aus dem internen VCM SIP-Signalling ins WAN verschickt, wird jedoch CS1 verwendet. Das wäre aber eher unüblich, oder täusche ich mich?
Inzwischen sind wohl einige ISP-Provider-Netze bis zum Kundenanschluß QoS-transparent (bei meinem Arcor-Anschluss seit ca. Juli 2007), so dass QoS immer besser auch Ende-zu-Ende funktioniert, für VoIP natürlich sehr gut. In meinem Fall kommen RTP-Ströme von verschiedenen Providern korrekt mit DSCP EF an.
Weil aber viel Cisco in den Provider-Backbones zu vermuten ist, wäre es schöner, wenn LANCOM auch DSCP = CS3 für SIP-Signalling verwenden würde. Damit könnte man die Wahrscheinlichkeit erhöhen auf kompatible Queueing-Mechanismen in den Provider-Backbones aufzubauen?
Kennt jemand in der Runde die üblichen, aktuellen Provider-Defaults für SIP-Signalling?
Gruß,
Rougu
SIP-Signalling besser mit DSCP CS3/AF31 statt CS1 ins WAN
Moderator: Lancom-Systems Moderatoren
-
betatester
- Beiträge: 29
- Registriert: 01 Jun 2006, 12:46
hallo rougu,
also cs1 kommt mir jetzt auch unueblich vor. hierzulande (AT) arbeitet man eher mit CS5 oder EF.
ich denke, das mit der "hoechsten wahrscheinlichkeit" koennte lancom insoferne loesen, als sie einfach im vcm einstellen lassen, wie die pakete markiert werden sollen. dann kann das jeder benutzer fuer sich und seinen provider selber entscheiden-
(so, wie man es von snom-telefonen kennt.)
ob sich der provider dann kuemmert darum ist allerdings eine andere frage.
ganz untechnisch gesehen macht man ja damit nichts anderes, als man seinem datenpaket ein "blaulicht" aufsetzt. wenn das jetzt jeder macht, fahren ploetzlich nur mehr blaulicht-pakete durch die gegend und es wird wieder zum stau kommen.
mir hat unser provider mal erklaert, man kann die pakete markieren wie mal will. er wirft die information mit einem laecheln weg.
ausser: man bezahlt extra dafuer
hoffe, wir haben jetzt nicht vollkommen aneinander vorbeigeredet.
gruesse
betatester
also cs1 kommt mir jetzt auch unueblich vor. hierzulande (AT) arbeitet man eher mit CS5 oder EF.
ich denke, das mit der "hoechsten wahrscheinlichkeit" koennte lancom insoferne loesen, als sie einfach im vcm einstellen lassen, wie die pakete markiert werden sollen. dann kann das jeder benutzer fuer sich und seinen provider selber entscheiden-
(so, wie man es von snom-telefonen kennt.)
ob sich der provider dann kuemmert darum ist allerdings eine andere frage.
ganz untechnisch gesehen macht man ja damit nichts anderes, als man seinem datenpaket ein "blaulicht" aufsetzt. wenn das jetzt jeder macht, fahren ploetzlich nur mehr blaulicht-pakete durch die gegend und es wird wieder zum stau kommen.
mir hat unser provider mal erklaert, man kann die pakete markieren wie mal will. er wirft die information mit einem laecheln weg.
ausser: man bezahlt extra dafuer
hoffe, wir haben jetzt nicht vollkommen aneinander vorbeigeredet.
gruesse
betatester
Hallo betatester,
interessant: in AT CS5/EF für Signalling...
Im Grunde stimme ich Dir zu: eine freie Konfigurationsmöglichkeit für DSCP Flags im VCM ware die schönste Lösung. Und genau, Snom, AVM, .... machen diesen Parameter ja auch schon user-zugänglich, damit es in die jeweilige QoS-Landschaft passt. Und das kann ja auch ein Firmennetz sein, mit wenig Bandbreite für viele User zwischen Standorten, wo CBWFQ mit Cisco ausgereizt wird, um die User akzeptabel zu bedienen.
Aber zum "Blaulicht" gebe ich Deinem Provider nur teilweise recht:
- Wenn der Provider ein Trust-Boundary einrichtet und alles auf "BE" zurücksetzt, weil er uns nicht traut: fein und nachvollziehbar. Andererseits wird er intern QoS und Queueing verwenden, denn:
- Class-Based Queueing ist sowieso nur sinnvoll, wenn ein Engpass herrscht. Und den Kunden/Nutzer eines bestimmten Dienstes wird es freuen, wenn im Congestion-Fall das Queueing gewichtet wird und die DSCP-Flags berücksichtigt werden.
Im Moment habe ich (mangels aktuellen Carrier-Insiderwissens) die Vermutung, dass die ISPs ihre DSL-Zugänge für DSCP transparent machen oder bekannte Dienste aufgrund von ACLs mit eigene DSCP-Flags ausstatten, und eben nicht mehr alles gleichbehandeln.
Und noch allgemeiner, der ganze Schnickschnack mit DSCP ist teilweise eine Scheindiskussion, weil die Provider die generelle Überprovisionierung als die billigste Strategie ansehen, Engpässe zu vermeiden.
Fazit: Bitte, LANCOM, zwei neue Felder im LANconfig..., damit die LC-Router universeller anpassbar sind.
Gruß,
Rougu
interessant: in AT CS5/EF für Signalling...
Im Grunde stimme ich Dir zu: eine freie Konfigurationsmöglichkeit für DSCP Flags im VCM ware die schönste Lösung. Und genau, Snom, AVM, .... machen diesen Parameter ja auch schon user-zugänglich, damit es in die jeweilige QoS-Landschaft passt. Und das kann ja auch ein Firmennetz sein, mit wenig Bandbreite für viele User zwischen Standorten, wo CBWFQ mit Cisco ausgereizt wird, um die User akzeptabel zu bedienen.
Aber zum "Blaulicht" gebe ich Deinem Provider nur teilweise recht:
- Wenn der Provider ein Trust-Boundary einrichtet und alles auf "BE" zurücksetzt, weil er uns nicht traut: fein und nachvollziehbar. Andererseits wird er intern QoS und Queueing verwenden, denn:
- Class-Based Queueing ist sowieso nur sinnvoll, wenn ein Engpass herrscht. Und den Kunden/Nutzer eines bestimmten Dienstes wird es freuen, wenn im Congestion-Fall das Queueing gewichtet wird und die DSCP-Flags berücksichtigt werden.
Im Moment habe ich (mangels aktuellen Carrier-Insiderwissens) die Vermutung, dass die ISPs ihre DSL-Zugänge für DSCP transparent machen oder bekannte Dienste aufgrund von ACLs mit eigene DSCP-Flags ausstatten, und eben nicht mehr alles gleichbehandeln.
Und noch allgemeiner, der ganze Schnickschnack mit DSCP ist teilweise eine Scheindiskussion, weil die Provider die generelle Überprovisionierung als die billigste Strategie ansehen, Engpässe zu vermeiden.
Fazit: Bitte, LANCOM, zwei neue Felder im LANconfig..., damit die LC-Router universeller anpassbar sind.
Gruß,
Rougu
Hallo,
ok, alter Thread, aber der Vollständigkeit halber: Das ist jetzt möglich, siehe hier: http://www.lancom-forum.de/ptopic,50952.html#50952
Viele Grüße,
Jirka
ok, alter Thread, aber der Vollständigkeit halber: Das ist jetzt möglich, siehe hier: http://www.lancom-forum.de/ptopic,50952.html#50952
Viele Grüße,
Jirka