CAC - Funktion

Diese Seite beschreibt die grundlegende Funktion von CAC.

Basisfunktion

Ziel einer CAC-Konfiguration ist es, eine Überlastung von Teilstecken ihres Netzwerks durch VoIP zu verhindern. Zum einen bleibt dann genug Bandbreite für andere Datenverkehre übrig und zum anderen bleibt die Qualität auf hohem Niveau, wenn die Clients nicht mehr Bandbreite verwenden, also sie per QoS bereit gestellt bekommen.

CAC muss entscheiden

Damit CAC die richtige Entscheidung treffen kann, müssen Sie als Administrator in Lync die möglichen Subnetze erfassen, in denen sich Client aufhalten können. Wie Sie vielleicht wissen, ist VoIP im internen Netzwerk immer eine direkte Verbindung zwischen den beiden Endpunkten. Zudem gibt es immer eine ganze Menge von möglichen Endpunkten, weil ein Lync Client natürlich nicht nur über seine direkten IP-Adressen kommuniziert, sondern über einen Edge-Server weitere Kandidaten bekommt. Siehe auch ICE und Kandidaten.

Insofern muss der Client seine IP-Adressen erst mal einsammeln, die er mit dem INVITE über die Lync Server zu den Gegenstellen sendet. Aber noch kann CAC nicht aktiv werden, denn dazu sind auch die Gegenstellen gefragt. Der angerufene Teilnehmer ist also die maßgebliche Station, die alle Kandidaten hat und diese dann vom CAC-Server überprüfen lässt. Das kann komplexer werden, wenn es mehrere Zieleclients gibt oder dieser mehrere IP-Adressen bekommen hat.

Der CAC-Server muss dann überlegen, welche Endpunkte über welche Wege miteinander kommunizieren können und prüfen, welche Teilstrecken schon wie belastet sind. Der CAC-Server kann natürlich nicht wissen, wie belastet die Teilstecken real sind. Er kann nur wissen, wie viele Verbindungsanfragen er bereits bekommen und "bestätigt" hat.

Ein Client reserviert beim CAC-Server die Bandbreite und erneuert die Reservierung auch immer wieder.

Wann CAC nicht funktioniert

Damit ist natürlich auch klar, dass der CAC-Server auf die Mitarbeit des Clients angewiesen ist und es Fälle gibt, in denen CAC nicht funktionieren kann:

  • Client muss "CAC"-tauglich sein muss
    Damit ist klar, dass ein Benutzer mit einem alten OCS-Client nicht der Richtlinie unterworfen wird. Das bedeutet aber auch, dass z.B. ein Gateway nicht einbezogen wird.
  • Dateitransfer, Desktop-Sharing und Whiteboard
    Die Richtlinien können nur für Audio und Video definiert werden
  • Keine Kopplung an Router/Switch-Daten
    Die Bandbreitenkonfiguration legt die maximal durch Lync nutzbare Bandbreite zwischen zwei Standorten fest. Es ist keine Garantie, dass die Bandbreite auch vorhanden ist. Insbesondere bei Backup-Links oder mehreren IP-Leitwegen ist die Konfiguration nicht vollständig.
  • CAC wirkt nicht innerhalb eines Standorts
    Hier wird von "unlimitierter" Bandbreite ausgegangen. Wer also im Haus-LAN die Lync Verwendung begrenzen will, kann dies nicht per CAC machen, sondern maximal per QoS
  • Unabhängigkeit von IP-Routen
    Lync prüft und wertet keine IP-Leitwege aus. Die von ihnen erstellte Konfiguration sollte also schon den echten Verbindungen entsprechen und auch aktuell bleiben. Wenn ihre WAN-Truppe also die Bandbreiten oder Links verändert, sollten Sie in die Informationskette eingebunden werden.

CAC ist also kein Allheilmittel für die Kontrolle der von Lync verwendeten Bandbreite, sondern kann nur Audio/Video im Zaum halten, so dass die von QoS für Audio/Video gesicherte Bandbreite nicht überlastet wird und letztlich die Qualität darunter leidet.

Bypass für Audio und Video

Sollte die erlaubte Bandbreite überschritten sein, dann kann Lync aber einen Umweg nutzen. Je nach Konfiguration gibt es zwei Ausweichrouten:

  • Edge (Audio und Video)
    Wenn eine Firma zwei Standorte hat und jeder Standort mit einem eigenen Lync Pool und Edge-Server ausgestattet ist, dann kann Lync den Anwender über das Internet (Edge zu Edge) routen, wenn die interne WAN-Verbindung (VPN) überlastet ist.
  • PSTN (Nur Audio)
    Funktioniert der Edge-Umweg nicht, dann kann Lync auch einen PSTN-Failover initiieren, d.h. der Anrufer bekommt die Information, dass das Ziel nicht erreichbar ist aber er per Telefonnetz die Verbindung aufbauen sollte. Hier gelten dann wieder die Voice-Routen, PSTN-Usages und Normalisierungen. Der Client nimmt die E164-Nummer des Ziels aus dem Lync Adressbuch und versucht eine Verbindung.

Interessanterweise sind die Wege für verschiedene Dienste nicht immer identisch. Es kann also sein, dass z.B. Video über einen Weg und Audio über einen anderen Weg übertragen wird.

Technisch sendet der Caller einen INVITE an den Callee, welcher dann bei der Ermittlung der Kandidaten per ICE mit dem Edge spricht. Der Edge-Server fragt dann den PDP (Policy Decision Point) auf dem Pool um die Bandbreite anzufragen. Er streicht dann die nicht möglichen Kandidaten und gibt die verbliebenen an die Clients. Diese versuchen dann eine Verbindung zu erreichen und wenn diese möglich und mit "200 OK" hergestellt wird, wird die Bandbreite real reserviert.

Auswirkungen auf den Client

Wenn wir also CAC-taugliche Clients haben und CAC ein paar Vorgaben macht, dann wird der Anwender die ein oder andere Veränderung bemerken:

  • Weniger Bandbreite = Codec-Einschränkung
    Es macht schon einen unterschied ob Audio "Wide-Band" oder "Narrow-Band" übertragen wird. Auch bei Video-Übertragungen kann eine Einschränkung von HD auf VGA oder CIFS viel Bandbreite sparen. Mit CAC kann sogar verhindert werden, dass auf bestimmten Strecken Video genutzt wird.
    Allerdings kann CAC nicht im laufenden Gespräch einer Verbindung die Bandbreite weiter reduzieren.
  • "Gassenbesetzt"
    Wenn die Bandreite aus Sicht von CAC aufgebraucht ist, dann werden die Clients keine gültigen Kandidaten erhalten und die Verbindung kommt nicht zustande. Dabei werden Audio und Video getrennte betrachtet. Es kann also schon sein, dass Audio noch geht aber Video nicht genutzt werden kann.
  • Verzögerung durch Failover
    Wenn die direkten IPs nicht genutzt werden können, so können die Clients vielleicht noch über den Edge-Server über das Internet eine Verbindung für Audio und Video aufbauen. Sofern zugelassen können die Clients auch eine Wählverbindung für Audio als Bypass verwenden. Der Aufbau dieser Wählverbindung dauert natürlich etwas länger.

Der Client bekommt eine mehr oder minder beschreibende Fehlermeldung.

Subnetze, Sites, Regionen und Links

Damit CAC die richtige Entscheidung treffen kann, müssen Sie die Subnetze der Clients und die Verbindungen zwischen den Clients definieren. In CAC werden daher die Netzwerke als "Subnets" definiert, die dann genau einer Site zugewiesen werden. Jede Site wird dann genau einer Region zugeweisen. Es können mehrere Regionen definiert werden.

Bei der Verknüpfung einer Site zur Region kann eine Bandbreitenpolicy angegeben werden. Auch für den Region-Link zwischen Regionen können Bandbreitenrichtlinien zugewiesen werden. Eine Sonderstellung übernimmt der "InterSiteLink, welcher als einziger nicht per Lync Control Panel verwaltet werden kann. Hier muss die Lync PowerShell ran.

Wenn eine Firma also z.B. ein MPLS-Netzwerk hat, in welches jeder Standort einen Link hat, dann ist eine eigene Region mit mehreren Sites und auf die Bandbreite abgestimmte Policies der häufigste Konfigurationsfall.

Eine zweite Region ist z.B. eine mögliche Lösung für den Fall, dass ihr unternehmen international aufgestellt ist und das MPLS-Netzwerk sich nicht weltweit erstreckt, sondern Sie z.B. einen europäischen Carrier haben (z.B. Vodafone, Telekom etc.) aber die amerikanischen Standorte einen anderen Carrier wie z.B. AT&T, Verizon) nutzen. Dann stellt der Region-Link den Übergang zwischen den beiden Regionen dar. Knifflig kann es hier natürlich werden, wenn sie Standorte haben, die an beide Regionen angebunden sind, da dies so in Lync nicht konfiguriert werden kann.

Generell müssen Sie selbst ihre IP-Leitwege beachten. In CAC lassen sich quasi nur die "Hauptwege" definieren. Wenn Sie aber zwischen zwei Standorten mehrere Links mit unterschiedlichen Bandbreiten haben oder Backupleitungen einspringen o.ä., dann kommen Sie mit CAC hier nur bedingt weiter. CAC hat keine Information über ausgefallene oder überlastete Teilstrecken oder redundante Verbindungen.

CAC in der gleichen Site

CAC beschränkt die Überschreitung bestimmter Bandbreitenlimits auf WAN-Verbindungen. CAC beschränkt NICHT die Bandbreite innerhalb eines Standorts. Hier wird davon ausgegangen, dass die Verbindung in den Standorten nicht bezüglich Bandbreiten und Beschränkungen relevant sind. Es ist aber dennoch möglich, auch intern die Bandbreite zu beschränken. Das geht über die Conference Policy, wenn man ein paar Randbedingungen beachtet:

Gleiches gilt natürlich auch für Sites, die zwar einer Region zugeordnet sind aber keine Bandbreitenpolicy zugewiesen bekommen haben. Eine solche Site könnte z.B. ein gehostetes Angebot sein, d.h. wer seine Lync Server in der Cloud betreibt und der Anbieter mit "genug Bandbreite" verbunden ist, muss hier in der Regel keine Beschränkungen konfigurieren.

Vergessene Subnetze

CAC kann nur funktionieren, wenn beide Endpunkte auch in der CAC-Datenbank gepflegt sind. Ist auch nur ein Endpunkt nicht gelistet, dann gilt dieser als "Unrestricted". Wenn die "Netzwerker" diese Information nicht weiter geben, dann kann der Lync Administrator aber auch in sein Eventlog schauen. So sieht er zumindest nach einen Anruf die IP-Adresse.

Log Name:      Lync Server
Source:        LS Bandwidth Policy Service (Core)
Event ID:      36034
Task Category: (1057)
Level:         Warning
Keywords:      Classic User:          N/A
Computer:      LYNC.netatwork.de
Description:
Subnets für the corresponding IP addresses are not configured in the network configuration settings,
or the subnets are not associated with a network site.

The subnets für the following IP addresses are not configured, or the subnets are not associated 
with a network site: 192.168.100.100,80.66.20.21,192.168.103.10,192.168.102.65

Cause: The subnets für the corresponding IP addresses are missing from the network configuration settings,
or the subnets are not associated with a network site.
Resolution:
Add subnets für the corresponding IP addresses to the network configuration settings, and associate 
every subnet to a network site.

Das gleiche Problem haben auch die Active Directory Administratoren. Diese können aber z.B. in der NETLOGON.LOG nachschauen, Dort protokollieren die Windows Domain Controller, wenn ein Client aus einem Subnetz sich anmeldet, welches nicht in den "AD Standorten und Diensten" zu finden ist.

Konfigurationsänderungen

CAC hinterlässt aber noch weitere Spuren im Eventlog. Hier ein Beispiel mit einem Bericht einer neuen Konfiguration:

Log Name:      Lync Server
Source:        LS Data Collection
Date:          7/3/2017 1:24:47 PM
Event ID:      56408
Task Category: (2271)
Level:         Information
Keywords:      Classic User:          N/A
Computer:      fe01.msxfaq.net
Description:
New Network Configuration settings obtained.

<QoENCSSettings>
  <Regions>
    <Region RegionName="MPLS Telekom" />
    <Region RegionName="CACRegion_EMEA" />
    <Region RegionName="CACRegion_PB" />
  </Regions>
  <UserSites>
    <UserSite UserSiteName="PARIS" RegionName="CACRegion_EMEA" />
    <UserSite UserSiteName="LONDONG" RegionName="CACRegion_EMEA" />
    <UserSite UserSiteName="BERLIN" RegionName="CACRegion_EMEA" />
    <UserSite UserSiteName="CACSite_PB" RegionName="CACRegion_PB" />
    <UserSite UserSiteName="CACSite_PBWLAN" RegionName="CACRegion_PB" />
    <UserSite UserSiteName="CACSite_PBRAS" RegionName="CACRegion_PB" />
  </UserSites>
  <Subnets>
    <Subnet SubnetIP="192.168.100.0" MaskBits="24" UserSiteName="CACSite_PB" />
    <Subnet SubnetIP="192.168.101.0" MaskBits="24" UserSiteName="CACSite_PB" />
    <Subnet SubnetIP="192.168.102.0" MaskBits="24" SubnetDescription="WLAN" UserSiteName="CACSite_PBWLAN" />
  </Subnets>
  <MonitoredRegionLinks>
    <MonitoredRegionLink RegionName1="CACRegion_EMEA" RegionName2="CACRegion_PB" />
  </MonitoredRegionLinks>
  <MonitoredUserSiteLinks />
</QoENCSSettings>

Über dieses Event können Sie also einfach Konfigurationsänderungen nachverfolgen.

CAC, AVEdge und Internet

Im großen Internet gibt es natürlich (noch) kein QoS. Dennoch kann es durchaus interessant sein, auch die AV-Edge IP-Adressen einer eigenen Site zuzuordnen. Zwar werden alle Clients im Internet als "unbekanntes Subnetz" von CAC als "unbeschränkt" angesehen, aber ihre Verbindung zum Internet ist es nicht.

Der Failover über Edge Server wird pro Regionen aktiviert. Hier müssen Sie später "Alternate Path" für Audio und Video getrennt aktivieren, damit Client aus dieser Region über den Edge Server die internen Leitungen umgehen dürfen

Mit einer CAC-Site für die Edge-Server können Sie zwar nicht komplett die Bandbreiten zum Internet beschränken, aber Sie können natürlich doch z.B. beim Failover über zwei Edge Server noch steuern eingreifen.

CAC und Media Bypass

Beim Einsatz von Lync mit Telefonie empfehle ich immer den Einsatz von Media Bypass. In Verbindung mit entsprechenden Gateways kann so die Audio-Verbindung den Mediation Server umgehen und direkt vom Client zum Gateway laufen. Das spart Last auf dem Mediation Server und verkürzt die Laufzeit. Allerdings ist nun ein Gateway die Gegenstelle. Auch Lync zertifizierte Gateways sind aus der Sicht von CAC keine Clients, so dass beim Verbindungsaufbau von Client zum Gateway CAC nicht um Einsatz kommt. Bei einem Rufaufbau in die Gegenrichtung von Gateway zum Client jedoch schon.

Zum Glück ist dies aber nicht wirklich relevant, wenn Media Bypass kommt bei korrekter Konfiguration nur innerhalb der gleichen Site zum Einsatz. Der Fall, dass ein Client aus einem entfernten Standort über eine WAN-Leitung direkt mit einem Gateway kommuniziert, findet daher nicht statt. Sobald Audio bei Lync über eine WAN-Strecke läuft, nutzt der Lync Client immer den Mediation Server neben dem Gateway. Nur so kann auf der Strecke Client<->Mediation Server der effiziente RTAudio-Codec genutzt werden, weil der Mediation Server dann das Transcoding auf G.711 zum Gateway durchführt.

Der einfach G.711-Codec mit 64kbit unkomprimierten Daten, was letztlich ca. 97kBit IP-Daten ergibt, sollte auf WAN-Strecken nicht eingesetzt werden. Es ist einfach zu statisch für wechselnde Laufzeiten und Paketverluste.

Weitere Links