Direct Routing Preflight Check

Wenn Sie Direkt Routing einrichten wollen, dann ist es es ratsam schon vorab einmal über eine Checkliste sicher zu stellen, dass Sie nichts vergessen haben. Diese Liste kann natürlich keine seriöse Planung und Konzeption ersetzen aber soll ihnen bei der Planung etwas helfen und die Ansprechpartner identifizieren.

Thema Verantwortliche Personen Status

Office 365 Tenant

Es klingt nach einer Binsenweisheit aber ja, sie benötigen einen Office 365 Tenant im Teams mit Direct Routing einzurichten. Ich rate Firmen oft dazu, neben dem produktiven Tenant weitere Tenants für Test/Entwicklung und ggfls. noch für Qualitätsmanagement zu betreiben.

 

Phone System Lizenz

In dem Tenant muss es für die Anwender mit Telefonie natürlich eine "Phone System" Lizenz vorliegen. Die kann als "Additional License" gekauft werden oder als Bestandteil von E5 bezogen werden. Für einen kurzen Test reicht vielleicht auch eine E5-Testversion, die aber sehr schnell doch wieder abgelaufen ist.

 

Session Border Controller

Der SIP-Trunk zu Teams muss über einen lokalen Session Border Controller geführt werden, der von Microsoft getestet und zertifiziert ist. Der SBC kann dazu virtuell oder physikalisch bereitgestellt werden. Von Audiocodes gibt es z.B. einen kostenfreien virtuellen SBC mit zwei parallelen Sessions. Für erste Gehversuche kann dies eine Option sein. Auf Dauer kommen Sie damit aber nicht weiter

 

SIP-Trunk zum PSTN

Ein klassischer SBC ist ein Back-to-Back-USERagent (B2BUA), der in der Mitte zwischen zwei SIP-Trunks steht. Für die Kopplung zum Telefonnetz muss der SBC natürlich eine Gegenstelle haben. Das kann ihre IP-Telefonanlage oder ein SIP-Trunk eines Providers sein. Diese Komponente ist eventuell mit Kosten verbunden und muss ebenfalls beantrag oder lizenziert werden.

Denkbar ist aber auch eine Anbindung per ISDN, auch wenn es immer weniger Gegenstellen gibt. Sehr oft wird dieser Weg aber noch genutzt, weil die TK-Anlage noch kein VoIP kann oder inkompatibel ist

 

Öffentlicher DNS-Name

Office 365 baut eine SIP-Verbindung zu ihrem SBC auf. Das geht nur über einen im Internet auflösbaren Namen. Überlegen Sie schon mal, wie der Host bekannt werden soll. teams-sbc.<firma.tld> könnte ein Beispiel sein.

 

Öffentliches Zertifikat

Da die Verbindung per TLS gesichert werden muss, benötigt ihr SBC auch ein Zertifikat, welches auf den öffentlichen Namen ausgestellt und auf dem SBC installiert wird. Das Zertifikat muss von einer PKI ausgestellt sein, die in Office 365 als "Trusted" geführt wird, da sich auch ihr SBC mit diesem Zertifikat gegenüber Office 365 authentifiziert.

 

Öffentliche IPv4-Adresse

Zum Namen und dem Zertifikat gehört natürlich eine öffentliche IPv4-Addresse, die auf den SBC direkt gebunden werden muss oder über eine geeignete Firewall per 1:1 NAT auf den SBC weiter geroutet wird. Beim Einsatz von NAT müssen Sie aber dem SBC die öffentlichen IP mitteilen, damit er diese als SDP-Kandidat verwendet. Verwendet werden auf der IP-Adresse nur zwei Portbereiche

  • Signalisierung über SIP mit Port 5061/TLS
    Dies ist der Standard aber kann geändert werden. Eine Beschränkung auf wenige Office 365 Gegenstellen ist möglich
  • 49152-53247/UDP für SRTP (Audio/Video)
    Diese Ports sind aus dem Internet erreichbar, da es auch Clients im Internet geben kann, die direkt mit dem SBC per RTP kommunizieren. Unsicher ist das aber nicht, da die SBC-Firmware die Ports nur während der Verbindung öffnet und die empfangenen Daten korrekt verschlüsselt sein müssen.

 

Management

Denken Sie dran, dass ein SBC natürlich für die Konfiguration erreichbar sein muss. Meist nutzen wir dazu ein eigenes "Management VLAN", um den Zugriff auf die Webconsole oder per TELNET oder SSH nicht aus dem allgemeinen Netzwerk erreichbar zu machen. Denkbar ist natürlich auch eine entsprechende Filterung in Firewalls oder Beschränkungen auf Quell-IPs

Zudem sendet der SBC vielleicht Log-Informationen per SYSLOG, CDR-Records per SYSLOG und ihr Monitoring könnte per SNMP oder andere Schnittstellen die Funktion überwachen. Für diese Funktion müssen Sie die entsprechenden Gegenstellen, z.B. SYSLOGD aufbauen und erreichbar machen

 

Firewall-Freischaltungen

Schon mehrfach habe ich Firewalls erwähnt. Der SBC ist bezüglich der Sicherheit war eine Application Firewall für SIP und RTP aber dennoch haben die meisten Firmen ihr Netzwerk mit zusätzlichen Filtern versehen, die zwischen dem SBC und den Gegenstellen liegen. Mir fallen folgende Verbindungen direkt auf, die ggfls. zu erlauben sind:

  • SBC zu Office 365
    Hier ist die Signalisierung über Port 5061 o.a. zu erlauben und natürlich der RTP-Verkehr
  • Internet-Teams-Client zu SBC
    Wenn Client im Internet telefonieren und die Relays von Office 365 umgehen sollen, dann ist es ratsam die RTP-Ports aus dem Internet erreichbar zu machen. Es kann aber auch eine Option sein genau das nicht zu tun, damit die Clients immer über das Relay gehen und damit teilweise das Microsoft Global Network anstelle lange Wege über das Internet nutzen.
  • Interner Teams-Client
    Wen Anwender im Haus-LAN mit Teams telefonieren, dann wäre es ineffektiv diesen Verkehr über das Internet und die Media-Relays zu senden. Hier ist es wichtig, dass die internen Clients die öffentliche IP-Adresse des SBC für RTP-Verbindungen ohne NAT oder Proxy erreichen kann.
  • SBC zum PSTN-Link
    Auch intern könne eine Firewall zwischen dem SBC und der TK-Anlage oder dem SIPTrunk-Provider stehen.
  • SBC zu Management
    Für die Anforderungen bezüglich SNMP, SYSLOG und Konfigurationswebseite habe ich gerade schon geschrieben

 

Staffing

Machen Sie sich bitte rechtzeitig Gedanken, wann wie welchen Mitarbeiter oder Dienstleister für die erforderlichen Konfigurationsschritte benötigen. Gerade SIP-Trunks bei TK-Anlagen bedürfen einer terminlichen Abstimmung und sind nicht mal eben eingerichtet. Das gilt auch für die Festlegung der Rufnummern und Normalisierungsregeln. Ich bevorzuge natürlich E.164 mit "Plus" aber nicht jeder SIP-Trunk kann das.

Auch für die Einrichtung im Tenant brauchen Wie ggfls. einen Global Admin und auch die Firewall und Netzwerk-Gruppe muss bei der Umsetzung mit eingebunden werden um eine schnelle Fehlersuche zu ermöglichen.

 

Test und Validierung

Wenn die Konfiguration dann schon mal geschafft ist, sollten Sie unbedingt verschiedene Tests durchführen. Es bietet sich dabei an schon sehr früh die verschiedenen Testfälle und erwarteten Ergebnisse aufzuschreiben. Mit einem schnellen Anruf und Rückruf ist es nämlich nicht getan. Ein paar Demo-Benutzer mit Rufnummern sollten es schon sein um die verschiedenen Testfälle durchzuspielen. Hier eine Auswahl

  • Direkter Anruf eingehend und Ausgehend
    Das muss natürlich mit der E.164-Nummer gehen aber auch kurze Rufnummern sollten über den passenden Dialplan entsprechend umgesetzt werden.
  • Vermitteln, Makeln, Umleitung, BlindTransfer, Rückfrage u.a.
    Klingt einfach aber all diese Fälle müssen natürlich mit mehreren Personen getestet werden
  • Boss/Admin und Stellvertreter
  • Mobile Clients und Rufmitnahme auf GSM
  • Call Queues und Konferenzeskalation
    Warteschlangen für Anrufer mit Agenten
  • 3PIP - klassische Telefone
    Die Geräte von Audiocodes, Polycom und Yealink sollen mit einer "Teams Firmware" auch direkt mit Teams telefonieren können
  • Konferenzgeräte
    Auch Surface Hub und Surface Room System sollen bald mit Teams arbeiten können. Zudem gibt es noch eine ganze Menge anderer Geräte, die in Zusammenarbeit mit Teams und Telefonie zu testen sind.
  • Migration/Koexistenz
    Wenn Skype for Business parallel genutzt wird, sind hier weitere Szenarien zu testen
  • Provisioning
    Testen Sie auch ruhig mal, ob ihr Entry/Exit-Prozess für Mitarbeiter funktioniert, z.B. wie werden die Rufnummern, Dialpläne und Voice-Policies konfiguriert. Prüfen Sie auch, welche Berechtigungen für die Aktionen tatsächlich erforderlich sind oder wie diese sinnvoll delegiert werden können. Sie wollen sicher nicht jedem Teams-Admin gleich "Tenant Global Admin"-Rechte geben.
  • Reporting
    Schön, wenn Sie CDR, QoS und Syslog eingestellt haben. Dennoch sollten Sie auch testen, dass all diese Komponenten funktionieren.

Gehen Sie also schon davon aus, dass die Liste der Tests nicht mal auf eine DIN-A-4-Seite passt. Welche Tests für ihre Umgebung relevant sind, müssen Sie natürlich selbst definieren. Ideal ist, wenn die Funktionstests zumindest zum Teil automatisiert werden könnten und damit ein automatisches Monitoring möglich ist oder zumindest nach einer Konfigurationsänderung schnell der Erfolg bestätigt werden kann.

 

Netzwerk Readyness

Audio und Video stellen besondere Herausforderungen an die Netzwerkkonfiguration. Nur nur die empfohlene Verwendung von UDP statt TCP/443 ist ein gewichtiger Unterschied. Auch die Paketanzahl und Anforderung an Laufzeit und Paketverlustraten sind gut dokumentiert.

Sie sollten auf jeden Fall überlegen, wie sie diese Anforderungen nicht nur erfüllen, sondern auch deren Einhaltung überwachen. SNMP und NetFlow sind hier bei weitem nicht ausreichend. Aktive Tests sind anzuraten, die auch erkennen, wenn z.B. eine Firewall doch mal wieder UDP blocken sollte.

Auch alle anderen Anforderungen an Office 365 Netzwerke (z.B. lokale Breakouts mit lokaler DNS-Auflösung, Umgehung von Proxy-Servern für Office 365 etc. sind hier zu beachten.

 

Produktion ist nicht Test

Wenn in ihrem Test-Tenant dann alles funktioniert, wie es gefordert und versprochen wurden, dann beginnt ein Teil der Arbeit wieder von vorne. Die Einrichtung und Konfiguration im produktiven Tenant steht an

 

 

Ich hoffe, diese Checkliste hilft ihnen die Einführung von Direct Routing etwas besser zu planen.

Ansonsten können Sie meine Kollegen oder mich bei Net at Work gerne zur Unterstützung einkaufen

Weitere Links