PSTN usage

Der Begriff "PSTN-Usage" findet sich in Lync und OCS gleichermaßen und wer es wörtlich übersetzt kommt auf etwas wie "Telefonverwendung". Das kommt dem schon recht nahe, was Microsoft damit meint. Ein Administrator kann damit steuern, welcher Benutzer wie sein Telefon verwenden kann. Dies bezieht sich z.B. auf die Berechtigungen bestimmte Ziele und bestimmte Gateways zu nutzen.

Die Komponenten

Dazu spielen mehrere Bausteine eine Rolle

  • Dialplan
    Jedem Benutzer wird genau ein Dialplan zugewiesen, welcher in der Regel mehrere Normalisierungsregeln enthält, um die Rufnummer des Anwenders
  • PSTN-Usage
    Global definiert ein Administrator verschiedene "PSTN-Usage". Diese Texte sind aber einfach nur "Texte", an denen erst mal keine Funktion oder Reglementierung angehängt ist.
  • Voice Policy
    Eine Voice Policy steuert verschiedene Telefonie-Funktionen, die der Anwender mit dieser Richtlinie verwenden kann. Und eine Voice Policy enthält auch immer eine Liste mit verbundenen PSTN-Usages.
  • Voice Route
    Erst mit der Voice Route können Sie verstehen, wie PSTN-Usage dann umgesetzt werden. Eine Voice Route funktioniert ähnlich wir ein Exchange Send-Connector, bei dem ein Adressraum (hier eben die Rufnummern) die Ziele filtert. zudem kann eine Voice Route noch Rufnummern normalisieren und gibt die Zielgateways an.

Aber zusätzlich prüft Lync auch noch, ob der Benutzer über seine ihm zugewiesene "Voice Policy" auch die "Phone Usage" mitbringt, damit er den Weg zum Gateway verwenden darf.

PSTN-Usage beim Benutzer

Auch wenn das Bild auf den ersten Blick verwirrend aussieht, so kann ich damit bei Kunden sehr elegant erklären, wie die "PSTN-Usage" den Zugriff auf bestimmte Empfänger steuert.

Ein Benutzer bekommt über die Voice Policy auch eine Gruppe von "PSTN-Usage". Bei jeder Verbindung zum Telefonnetz wird aus der Liste der Routen nicht nur anhand der Zielnummer die Route selektiert, sondern eben auch anhand der erlaubten "PSTN-Usage"

Nicht ganz verschwiegen werden sollte, dass auch der Dialplan einen gewissen Einfluss hat. Wenn Sie eine Rufnummer einfach nicht "normalisieren", so dass es eine passende Route gibt, dann kann der Anwender diese Nummer natürlich nicht anrufen. Dies könnte z.B. ein Weg sein, 110, 112 und andere besondere Nummern auf eine andere Nummer (z.B. Werkschutz) um zu routen oder eben nicht erreichbar zu machen. Aber diese Wahl der Filterung ist nicht wirklich nachvollziehbar und kann vom Anwender leicht umgangen werden: Wer direkt eine E.164-Nummer eintippt, wird nicht weiter normalisiert.

Das Bild zeigt schon ein paar Beispiele, wobei die Einrichtung von "PSTN-Usage" natürlich sehr individuell pro Kunde ist. Die meisten Installationen beginnen einfach damit, dass eine Phone Usage "Alles erlaubt" angelegt und mit den Benutzern und routen verbunden wird. Damit stört zumindest dieses Filterkriterium nicht mehr bei ersten Gehversuchen.

Wenn das Gateway sowieso eine "Unteranlage" hinter einer Telefonanlage ist, dann sollten Sie sowieso abstimmen, welche Regeln und Berechtigungen aktuell auf der TK-Anlage implementiert sind und wie diese auch in Lync umgesetzt werden können.

Interessant werden die PSTN-Usage z.B. wenn es mehrere Gateways in mehreren Ländern gibt. Dann könnte jemand in einen Land quasi ein Verbot für internationale Calls haben aber die Landesgesellschaften im Ausland dennoch anrufen, weil er per Lync zum Gateway im dortigen Land geht und dann dort wieder ein Ortsgespräch oder ein nationales Gespräch führt.

Auch wenn Lync mit Telefonanlagen gekoppelt ist, werden sehr oft entsprechende "PSTN-Usage" eingerichtet, damit über die Voice Policy eine Person zumindest dann alle Teilnehmer der TK-Anlage erreichen kann.

Leider kann man PSTN-Usage oder Voice Policies nicht an Windows Gruppen fest machen, sondern muss PSTN-Usage immer in Voice Polices zusammenfassen und genau eine Voice Policy pro Benutzer zuweisen. Insofern ist eine geschickte Namenskonvention ratsam.

Neben den eigentlichen Anwendern gibt es aber noch durchaus andere Objekte, denen eine "Phone Usage" zugewiesen werden kann, damit Lync die Berechtigungen zur Telefonie und die Bestimmung der Route zuweisen kann.

PSTN-Usages am Trunk

Wer sich mal die Trunk-Konfiguration bei Lync anschaut, sieht auch hier die Option PSTN-Usages zu hinterlegen:

Damit ist aber nicht gemeint, damit zu steuert wer diesen Trunk nutzen darf. Das wird über die Routen geregelt. Umgekehrt wird ein Schuh daraus. Eingehende Anrufe über den Trunk erhalten diese "Berechtigungen" vererbt und Lync kann den Ruf dann über einen Trunk weiter reichen, wenn es keinen passenden Lync Empfänger gibt.

To enable inter-trunk routing, associate and configure PSTN usage records to this trunk configuration. The PSTN usages associated to this trunk configuration
Quelle: Configure a trunk without media bypass in Lync Server 2013 http://technet.microsoft.com/en-us/library/gg425831.aspx 

Wenn Sie irrtümlich hier aber eine PSTN-Usage pflegen und damit eingehende Anrufe von Lync wieder weiter geroutet werden können, dann bauen Sie sich ganz schnell eine SIP-Schleife. Wenn eine TK-Anlage z.B. per SIP-Trunk einen Ruf an Lync übergibt, aber es dort keinen passenden Empfänger gibt, dann routet Lync den INVITE anhand seiner Voice Routen und den PSTN-Usages des eingehenden Trunks weiter. Im schlimmsten Fall wieder genau zu der TK-Anlage zurück, von der dieser Anruf gekommen ist. Wenn die nun anhand der Nummer den Anruf wieder über den Trunk zu Lync sendet, geht das Spiel weiter, bis der Hopcount überschritten ist.

PSTN-Usages und Location Based Routing

Auch bei den Location Policies gibt es die Möglichkeit eine PSTN-Usage zu hinterlegen.

Wer dann in Lync die Subnetze und Standorte pflegt, kann jedem Standort auch eine Location Policy zuweisen.

Damit wird es erstmals mit Lync 2013 möglich, das ein Anwender zusätzlich zu den PSTN-Usages in seiner Voice Policy noch eine weitere Policy zusätzlich bekommt, die bei der Wahl der Route mit berücksichtigt wird. Mit Lync 2013 ist es damit möglich "Location Based" Routing umzusetzen. Sie müssen natürlich dennoch diese zusätzliche PSTN usage in den Routen auch verwenden.

Dazu gibt es interessante Anwendungen für Firmen mit mehreren Standorten und lokalen Gateways zum Telefonnetz.

  • lokale Notrufe
    Normalerweise nutzt ein Anwender z.B.: bei der Wahl des Notrufs das ihm per Voice Policy und Routing zugewiesene Gateway. Das ist aber nur dann "lokal", wenn der Mitarbeiter auch an seinem Heimatstandort ist. Wenn er unterwegs in einer anderen Filiale ist, dann hat Lync 2010 das nicht auswerten können. Mit Lync 2013 kann ein Administrator aber nun z. B. je "Location" eine eigene PSTN-Usage für Notrufe einrichten und eine geeignete Router über das lokale Gateway legen. Stellen Sie aber sicher dass diese Routen und usages immer vor der "Default Route" sind, über die der Mitarbeiter normalerweise telefoniert.
  • Lokale Anrufe
    Das gleiche Verfahren kann natürlich genutzt werden, um "Ortsgespräch" auch für Besucher durch das lokale Gateway zu routen. Wäre doch ungeschickt, wenn ein Mitarbeiter in einer anderen Niederlassung arbeitet einen lokalen Taxibetrieb oder das Hotel rufen will und die Sprache erst per VoIP zu seinem Heimatstandort geht und dort über das Gateway wieder in die Stadt zurück kommt.
  • WAN-Last reduzieren.
    Mit der Option Anrufe über ein "nahestehendes" Gateway statt dem Heimatgateway zu routen, kann eine Firma erreichen, dass die VoIP-Daten nicht über das eigene WAN bis zum Heimatgateway gehen. Die Sprache kann das Netzwerk am nächsten Hop verlassen und dann über die Leitungen der Carrier laufen. Das spart Bandbreite, verbessert oft die Qualität aber sie müssen natürlich die Kosten beachten. Der Anwender sieht nicht, dass er in einer Auslandsniederlassung dann ein teureres "länderübergreifendes" Telefonat führt.

Sie sehen also, dass die PSTN usages an den Location Profiles durchaus einen sinnvollen Einsatzzweck haben. Allerdings können Sie pro Location profile immer nur genau eine PSTN-Usage zuweisen. Das ist aber vollkommen ausreichend um die Besonderheiten einer "Location" zu beschreiben.

Lync Conference 2014 Location Based Routing
https://channel9.msdn.com/Events/Lync-Conference/Lync-Conference-2014/VOICE303

PSTN usages und Reihenfolge / Failover

Jeder Benutzer hat eine "Voice Policy" und diese beinhaltet die PSTSN usages. Beachten Sie, dass hier die Reihenfolge der PSTN-Usages beeinflusst werden kann. Lync geht beim Routing die Liste von Oben nach untern durch und such eine Router die für das Ziel passt und vom Benutzer verwendet werden kann. Sie sollten also immer die PSTN-Usages nach oben schieben, die den "günstigen Weg" beschreiben. Beachten Sie aber auch, das PSTN-Usages auch zur Kontrolle von Failover-Berechtigungen verwendet werden. Wenn der Anrufer für Route zwar berechtigt ist aber der "Next Hop" gerade nicht verfügbar ist, dann läuft Lync weiter, um einen Alternativen Weg zu finden.

Aber auch bei den Routen selbst gibt es PSTN-Usages, die "sortiert" werden können

Und auch die Routen selbst können "sortiert" werden

Damit lässt sich nahezu jede Konstellation umsetzen. Es kann aber auch schnell verwirrend werden.

PSTN usages und Drittprodukte

Es ist recht offensichtlich, dass ein Lync Benutzer über die Voice Policy und Location Profiles ein Gruppe von PSTN-Usages bekommt und damit mit den Routen die mögliche Wege kontrolliert werden. Aber es gibt noch andere Applikationen, die ebenfalls über Lync "telefonieren". In Testfeldern gibt es oft eine globale Voice Policy, die aller erlaubt. In der Produktion ist das eher nicht der Fall mit der Folge, dass Programme nicht mehr wie gewohnt funktionieren.

  • Exchange UM
    Benutzer können ihre Sprachnachrichten in Outlook als MP3/WAV-Datei abspielen oder per Telefon oder Lync bei Exchange anrufen und die Sprachnachrichten vorspielen lassen. Exchange unterstützt aber auch, dass der Anwender einen Rückruf anfordert. Exchange ruft dann per SIP natürlich vom Anwender eingegebene Nummern an.
    Siehe auch Lync und Exchange UM
  • Response Group
    Auch die Response Groups können z.B. per Regel einen Anruf auf externe Rufnummern leiten und benötigen dazu eine passende Voice Policy. Siehe dazu Response Group Service
  • UCMA
    Genau genommen zählt jede Trusted Application, UCMA Application etc. dazu.

Weitere Links